Some new ways to discuss BeeWare
Today, the BeeWare project is making 2 changes to the way we organize our community.
Firstly, we're going to move our real-time chat community from Gitter to Discord.
When we originally set up Gitter, it was a strong option for a chat community - especially one that was focussed on a software project, due to its tight integration with Github. However, over the years, Gitter has undergone multiple changes of ownership, but has remained essentially unchanged - in some cases, it's gotten appreciably worse (their native iOS and Android clients are effectively deprecated). In the meantime, Discord has emerged as a dominant player for community chat. It has a robust mobile client, and really good tools for community moderation, as well as the option of hosting video and voice chats - something we hope to be able to use for coordinating virtual sprints.
To join the new BeeWare Discord server, visit this link.
Secondly, we're going to start using Github Discussions.
For many years, we've tried to use Github Issues as a pseudo-forum. There's a lot of similarity between how a forum works and how Github displays and manages issues. Each "issue" is effectively a forum thread, and each comment is a message in that thread. However, there are also some important differences. Issues get closed when they're resolved; forum threads, however, don't necessarily have a resolution. Most importantly, "closing" an issue can look like someone is trying to kill discussion - when all they're really trying to do is keep the list of issues manageable.
The good news is that Github has noticed the similarity too, and has launched Github Discussions. Discussions offers a familiar "forum" interface, but with the familiar Github message interface, and tight integration with Github Issues and pull requests.
We've enabled Discussions on all the key BeeWare projects - Toga, Briefcase, Rubicon ObjC, Rubicon Java, Colosseum, Travertino and Podium.
Naturally, all of these new community spaces - along with all existing BeeWare spaces - are subject to the BeeWare Community Code of Conduct.
We hope these two changes will make it easier to participate in the BeeWare community. See you there!
Release the Android Bees!
9 months ago, we announced that the BeeWare Project was the recipient of a PSF Education Grant. In late 2019, we choose Asheesh Laroia to do the work. Today, we're proud to announce that BeeWare's Android support has reached a point where it is ready for mass consumption.
The BeeWare tutorial has been updated to include an Android track. The tutorial walks you through the process of writing your first app, and deploying it - first as a desktop app, and then on your phone. All you need is a Python install; everything else you need is downloaded automatically by the BeeWare tools as part of the development process.
And, to prove that it's real - we have uploaded Travel Tips to the Google Play Store. This is a Python app, in the Google Play Store, deployed from the same source code as the version in the iOS App Store.
Huge thanks go to Asheesh for all the work he's put into this project. Delivering Android support in BeeWare has required considerable technical skill, attention to detail, and creative hacks; and Asheesh has consistently delivered. Huge thanks also go to the Education Grants Committee of the Python Software Foundation for the faith they placed in BeeWare when they funded this project. In 6 months (while simultaneously negotiating a world pandemic), we've gone from a nothing to a full Android implementation. Without their financial support, this project would still be a dream.
There's still plenty of work to be done, though. There are still a lot of widgets that need Android implementations, and new widgets that we want to add. We'd like to add support for device features like cameras, GPS and accelerometers. We'd like to make it easier to use binary Python packages like NumPy, Keras, and more. And we'd like to merge the work that we've done into CPython itself.
All of those are significant projects in themselves, and will require effort comparable to that required to add Android as a supported platform. And so, we're looking for the financial support to make that happen. We're applying for new grants as opportunities arise, but the most helpful source of funds are the ongoing funds that come from memberships. Ongoing funding means we can focus on improving BeeWare, rather than chasing grants. It means being able to hire permanent staff, rather than offering short term contracts. And it means being able to make long term plans and promises to the community.
If this project proves anything, it's that money makes things happen. If you're excited by the prospects of Python on mobile platforms, please consider joining the BeeWare Project as a financial member. Or, if you've got experience with commercialisation of Open Source projects, or any other ideas for how we could please get in touch.
Python on Android: Its alive!
For the last couple of months, we've had a contractor (Asheesh Laroia) working on fixing Android support in the BeeWare suite of tools.
I've incredibly happy to announce that we've just hit our first major milestone: a working pure-Python application, running on an Android device!
This isn't the end of the project - it's just the beginning. There's still lots of fine tuning to be done (especially on the size of the support libraries), and we need to integrate this support into Briefcase and Toga.
However, in the meantime, if you're adventurous, you can take Asheesh's work-in-progress for a spin. His Python Android Support repository contains the current state of the work, and includes fairly comprehensive instructions for getting started. You'll need to know at least a little bit about native Android programming to make full use of this repository at the moment; but if you want to replicate the results from the video, that repository (and the other repositories it links to) should have everything you need.
Huge thanks go once again to the Python Software Foundation. Without their financial support, this work would still be on the drawing board. This project is just one of many ways that the PSF uses donations to improve the Python community and ecosystem. If your company uses Python in any capacity, I strongly encourage you to contribute financially to the PSF so that they can continue to fund worthwhile projects like this.
Huge thanks also go to Asheesh. Without his remarkable talents, attention to detail, and delight for obscure compiler errors, we wouldn't have made the incredibly fast progress that we've seen.
Stay tuned for more announcements soon!
We have a contractor for our Android contract!
A couple of months ago, we announced that the BeeWare project had received a grant from the PSF to improve our support for Android. At that time, we issued a call for contractors to help us complete this work.
We're very happy to announce that we've now selected a contractor: Asheesh Laroia.
Asheesh is a regular speaker at Python events, where he has delved into a range of detailed and complex topics. He also impressed us with the list of unconventional engineering integration projects he's been involved with in a professional and casual capacity.
When asked why he applied to work with BeeWare on this contract, Asheesh said: "I use an Android phone every day, and I'm honored to be able to help implement the BeeWare vision of using Python to build first-class, native applications."
Asheesh will be starting work in mid December, and if all goes well, we should start seeing significant results by mid to late February. If you'd like to keep track of progress, you can follow BeeWare on Twitter; we'll also post larger updates on this blog.
BeeWare Project Awarded a PSF Education Grant
The BeeWare Project wants to make it possible for all Python developers to write native apps for desktop and mobile platforms. We have solid support for most desktop operating systems and iOS, but we know our Android support is lacking. The BeeWare core team knows what needs to be done to address the problem - what we’ve been missing are time and resources.
Thanks to the PSF Education Grants group, that’s no longer an issue. We’ve been awarded a US$50,000 grant to bring BeeWare’s Android support to a level comparable with our iOS support. We currently don’t have the time to do the work ourselves, so we’re calling for contractors to help us deliver this support.
This is a paid contract, which we anticipate lasting 3-6 months (depending on the experience of the winning contractor). You don’t have to be based in the US or Europe, either; the opportunity is open to anyone who can meet the requirements of the contract.
Unfortunately, the task calls for some sophisticated skills, and we’re not in a position to provide extensive mentoring. A successful bid is likely to require some prior experience, and a history with the technologies involved.
A full role description and scope of work for the contract is available. To register your interest, please forward your resume and cover email to contracts@beeware.org.
We look forward to being able to announce full Android support in the near future!
2018 Google Summer of Code - VOC Optimization
Google Summer of Code is coming to an end. I've spent the summer working on optimizing the VOC compiler, and I’m super excited to share the results.
Results
There are a couple of ways to evaluate the performance improvement from my project.
Microbenchmarks
Firstly, we introduced a microbenchmarking suite. Each microbenchmark is a small piece of Python code that tests a single and specific Python construct, or datatype, or control flow. The benchmarking infrastructure itself is crude (essentially it just tells you the total amount of processor time it took to run, with no fancy statistics) but it has been extremely useful to me while working on performance features to verify performance gain.
The idea is that the benchmarking suite is not to be run as part of the full test suite, but rather as needed and manually whenever an optimization is implemented. It also provides a way to check and prevent performance regression, especially on the "optimized" parts of VOC. While it doesn't really make sense to record specific numbers, as they will always vary from machine to machine, it should be reasonably easy to compare two versions of VOC. Benchmark numbers are included on each optimization-related PR I've worked on this summer (see PR log below), and I hope that more benchmarks will be added as more performance efforts are carried out in the future.
Pystone
Pystone is a Python Dhrystone, a standard benchmark for testing the performance of Python on a machine. Here are the before and after results on my machine:
May 10th, 2018:
$ python setup.py test -s tests.test_pystone test_pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 101.833 This machine benchmarks at 490.998 pystones/second
$ python setup.py test -s tests.test_pystone test_pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 101.298 This machine benchmarks at 493.595 pystones/second
$ python setup.py test -s tests.test_pystone test_pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 102.247 This machine benchmarks at 489.014 pystones/second
On current master (Aug 14th, 2018):
$ python setup.py test -s tests.test_pystone test_pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 11.2300 This machine benchmarks at 4452.37 pystones/second
$ python setup.py test -s tests.test_pystone test_pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 10.9833 This machine benchmarks at 4552.36 pystones/second
$ python setup.py test -s tests.test_pystone pystone (tests.test_pystone.PystoneTest) ... Pystone(1.2) time for 50000 passes = 10.9498 This machine benchmarks at 4566.29 pystones/second
Conclusions
Some things that I learned about VOC while working on this project:
1. Object creation in the JVM is expensive. This definitely does not mean that the VOC user writing Python should think about minimizing the number of objects that she creates, but rather that any time we can non-trivially reduce the number of objects created during bytecode transpilation or in VOC-defined function calls, we can expect to see a huge performance boost. Integer and boolean preallocation, which is about reusing objects that have already been created, was one of the most significant improvements we made this summer.
2. Method calls in VOC are expensive. This is essentially due to the process of invoking a callable: you have to check that the method is defined on the object, then construct it (read: object creation!), and check the arguments, before it can actually be called. (This is done using reflection, which is super interesting and confusing in itself.) And this is the reason why refactoring the Python comparison functions made such a big performance impact, because we were able to circumvent this process.
3. Exception-heavy code is expensive. Again, this is not to say that the programmer is on the hook for being frugal when throwing exceptions, but that VOC benefits greatly by avoiding the use of exceptions internally except when strictly necessary. For instance, Python uses StopIteration exceptions to signal the end of a for loop, and they quickly rack up when you have nested loops (everything is ultimately related to object creation!). That was the motivation for the nested loops optimization.
If I may be a bit more reflective here, one of the a-ha! moments I had this summer was realizing that to really optimize something, you have to understand where its biggest problems are first. I remember pitching to Russ at the start of the summer things like loop unrolling, constant folding, even converting to SSA-form (you know, stuff I heard about optimzation in my compilers class) and he was saying to me, think simpler. While working on my project, I used a profiler to understand exactly which parts of VOC were slow, and that information drove the changes we implemented. I think it worked out pretty well!
Future Work
- Minimize boxing of primitive types like String and Int. As VOC is written half in Python, half in Java, a single integer can be found in various representations on its way through the compiler -- as a Python object, unboxed to a primitive Java int, then packaged back up to a Python object. This problem was (somewhat incoherently) addressed in my proposal, but ultimately we couldn't come up with a good abstraction to support it.
- Build a peephole optimizer. CPython's peephole optimizer scans generated bytecode to identify sequences of bytecode that can be optimized, VOC could benefit from this too.
- Hook up more benchmarks, which serve as both proof of the kinds of programs VOC can currently compile and areas ripe for performance improvement.
Thank you
I will wrap this up by giving big thanks to Russ, my mentor. The time you spent helping me form my ideas, patiently answering my questions and reviewing my work was invaluable to me. It couldn't have been easy keeping up with what I was doing especially since I started improvising halfway through the summer. I am so grateful for your help, thank you.
PR Log (in chronological order)
Bug Fixes and Miscellaneous
- Fix Method repr
- Fix custom substitutions
- Fix List Bug
- Remove Unnecessary Instruction
- Fix __setitem__ error messages
- Fix contains/not contains bugs and refactor
- Add tests for problematic exception raising
- Add test for with + exception combo
- Add test for wrong iter error message
- Add tests for globals bug
- Remove unnecessary type casts and clean up
- Add test for problematic builtin function call
- Introduce org/python/Object type tests
2018 Google Summer of Code - Implement asyncio support in VOC
In the blink of an eye, Google Summer of Code (GSoC) 2018 has come to an end. During the three months long coding period, I have contributed several patches in VOC repository of BeeWare, all working towards the ultimate end goal of running asyncio module in VOC. In this blog post (which is my first actual blog post by the way 😄), I will document what I have done so far, why I couldn't make it to the end goal (yea, unfortunately I couldn't get asyncio to work at the end of GSoC 2018), and what's left that needs to be done in order to achieve the end goal (or at least make part of asyncio work).
Building Foundation
The first error that the transpiler throws when attempting to compile asyncio module was "No handler for YieldFrom", so it makes sense to start from this issue first.
Another feature related to generator was Yield expression. Before GSoC 2018, Yield statement in VOC was just a statement, meaning yield could not be used as expression. Generator methods such as generator.send, generator.throw and generator.close were not supported as well. Those features are what make asynchronous programming with generator possible, so I spent a few weeks to extend generator functionality in VOC, laying down the path to asyncio module.
PRs related to generator are listed below:
Nonlocal Statement
Nonlocal statement was another syntax not supported by VOC. After completion of generator's features, implementing this is the next step towards compiling asyncio module.
Implementing this feature took about 3 ~ 4 weeks as this is not as trivial as it seems. I took several approaches on this, while some of them do work, the code is not pretty and hacky, which could come back to bite me/other contributors in the long run. After many discussions with Russell, I refactored the closure mechanism in VOC and took a much cleaner approach in nonlocal implementations. I must admit that I took some short-cuts for the sake of "making nonlocal works" in the process of implementing nonlocal statement, resulting in poor design and messy codes. Many thanks to Russell, who helped me to improve my coding style and told me not to be discouraged when I'm stuck. 😄
Related PRs:
The Collections Module
Next item on my hit list was pure Java implementations of the collections module. asyncio module depends on 3 data structures from collections, namely defauldict, Deque and OrderedDict. Two of them (defaultdict and Deque) are implemented in C in CPython, plus they have good analog in Java, so it makes senses to implement the module in Java. Porting defauldict, Deque and OrderedDict to Java in VOC is relatively straight-forward, taking about 1.5 weeks to complete.
Related PRs:
Other PRs submitted during GSoC 2018
- PR #817 : Added coroutine related exception class [WIP] (closed due to not needed)
- PR #836 : Changed Bool construction to use getBool instead (merged)
- PR #847 : Add custom exceptions test cases (closed due to more comprehensive handling in PR #844)
- PR #849 : Fixed Unknown constant type <class 'frozenset'> in function definition (merged)
- PR #858 : Added test case for Issue #857 (merged)
- PR #860 : Added test case for Issue #859 (merged)
- PR #862 : Added test case for Issue #861 (merged)
- PR #867 : Fixed Issue #866 RunTimeError when generator is nested in more than 1 level of function definition (merged)
- PR #868 : Fixed Issue #861 Redefining nested function from other function overrides original nested function (merged)
- PR #879 : Fixed Incompatible Stack Height caused by expression statement (merged)
- PR #901 : Added test case for Issue #900 (merged)
- PR #788 : Implements asyncio.coroutines [WIP] (open, the dream 😎)
Issues submitted during GSoC 2018
- Issue #861 : Redefining nested function from other function overrides original nested function (fixed in PR #868)
- Issue #866 : RunTimeError when generator is nested in more than 1 level of function definition (fixed in PR #867)
- Issue #828 : Finally block of generator is not executed during garbage collection (open)
- Issue #857 : Complex datatype in set cause java.lang.StackOverflowError (open)
- Issue #859 : Duplicated values of equivalent but different data types in set (open)
- Issue #900 : Exception in nested try-catch suite is 'leaked' to another enclosing try-catch suite (open)
- Issue #827 : Maps reserved Java keywords to Python built-in function/method call (closed)
Towards The Ultimate End Goal
Unfortunately, three months of GSoC coding period was not enough for me to bring asyncio module to VOC. The nonlocal statement implementation was the biggest blocker for me mainly because I didn't think thoroughly before writing code. If I were to plan carefully and lay out a general coding direction, I would've completed it in much shorter time and have time for other implementations. An advice for the aspiring and upcoming GSoC-er, don't rush your code, make sure you know 100% about what you're doing before diving into the codes.
With that said, following are the list of modules to be implemented/ported to Java before asyncio will work in VOC:
- socket module (a bit tricky since Java doesn't support Unix domain socket natively)
- selectors module (high level I/O operations)
- threading module (might be easier to implement this first since threading in Python is an emulation of Java's Thread)
- time module (partially implemented in VOC)
Final Thoughts
Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor. Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄
Proyecto destacado: Colosseum
Este artículo fue publicado originalmente en la lista de correo de Entusiastas BeeWare. Si deseas recibir actualizaciones periódicas sobre el proyecto BeeWare, ¿Por qué no suscribirse?
Cuando diseñas una aplicación de interfaz gráfica, ya sea para escritorio, dispositivos móviles o navegador, una de las tareas más fundamentales es describir cómo colocar widgets en la pantalla. La mayoría de los kits de herramientas de widgets usarán un modelo de empaquetamiento de cuadrícula o caja de algún tipo para resolver este problema. Estos modelos tienden a ser relativamente fáciles al comienzo, pero se desmoronan rápidamente cuando tienes necesidades complejas de diseño o cuando tienes diseños que necesitan adaptarse a diferentes tamaños de pantalla.
En lugar de inventar un nuevo modelo de cuadrícula o de caja, el kit de herramientas del widget Toga widget toolkit adopta un enfoque diferente, utilizando un esquema conocido para diseñar contenido: Cascading Style Sheets, o CSS. Aunque CSS es más conocido por especificar el diseño en las páginas web, no hay nada intrínsecamente específico de la web al respecto. Al final del día, es un sistema para describir el diseño de una colección jerárquica de nodos de contenido. Sin embargo, hasta la fecha, cada implementación de CSS está vinculada a un navegador, por lo que la percepción es que CSS es un estándar específico del navegador.
Ahí es donde entra Colosseum. Colosseum es una implementación independiente del navegador de un motor de renderizado CSS. Toma un árbol de "nodos" de contenido, como un DOM de un documento HTML y aplica instrucciones de diseño CSS para diseñar esos nodos como cuadros en la pantalla. En el caso de Toga, en lugar de diseñar los elementos <div> y <span>, diseñas objetos Box y Button. Esto le permite especificar diseños adaptativos increíblemente complejos para aplicaciones Toga.
Pero Colosseum como proyecto tiene muchos otros posibles usos. Se puede usar en cualquier lugar donde exista la necesidad de describir el diseño fuera del contexto de un navegador. Por ejemplo, Colosseum podría ser la piedra angular de un renderizador de HTML a PDF que no requiere el uso de un navegador. También podría usarse como una librería de pruebas e implementación de referencia para la especificación CSS en sí misma, proporcionando una forma ligera de codificar y probar los cambios propuestos a la especificación.
La implementación actual se basa en el proyecto de Facebook yoga: originalmente era un código portado de JavaScript a Python línea a línea. Sin embargo, yoga solo implementa la sección de Flexbox de la especificación CSS3.
Esta semana, comenzamos un gran proyecto: reescribir Colosseum para que sea un motor de CSS totalmente compatible. El trabajo hasta ahora se puede encontrar en la rama globo del repositorio Colosseum en Github. El primer objetivo es el cumplimiento de CSS2.1, con una implementación del modelo de caja de CSS tradicional y el diseño de flujo. Una vez que tengamos una implementación razonable de eso, buscaremos agregar diseños Grid y FlexBox desde el conjunto de especificaciones CSS3.
Esto es obviamente un trabajo grande. CSS es una gran especificación, por lo que hay mucho trabajo por hacer, ¡pero eso también significa que hay muchos lugares para contribuir! Elije un párrafo de la especificación CSS, construye algunos casos de prueba que demuestren los casos descritos en ese párrafo y envía un parche que implemente ese comportamiento!
Esto resalta por que tu apoyo financiero es muy importante. Si bien podríamos hacer esto completamente con un esfuerzo voluntario, vamos a progresar mucho más rápido si un pequeño grupo de personas pudiera enfocarse en este proyecto de tiempo completo. El apoyo financiero permitiría aumentar significativamente la velocidad de desarrollo de Colosseum y el resto de la suite BeeWare.
Si deseas que Colosseum y el resto de BeeWare se desarrollen hasta el punto en que puedan utilizarse para aplicaciones comerciales, considera apoyar a BeeWare financieramente. Y si tienes alguna idea para fuentes de financiación potenciales más grandes, por favor ponte en contacto.
2017 Google Summer of Code - Portar Cricket a Toga, en lugar de Tkinter
Después de casi 4 meses de trabajo en Google Summer of Code 2017, finalmente estoy completando mi propuesta. Cada migración de widget y cada commit / PR / Issues / discusión con mis mentores sobre Cricket, Toga y rubicon-objc fueron detallados en el Issue 58.
"Comer su propia comida para perros"
La mejor manera de demostrar que un producto es confiable para los clientes es usarlo. Por lo tanto, la forma de demostrar que Toga es una herramienta eficaz para construir una interfaz gráfica de usuario es construir una aplicación completa que la utilice.
Cricket es una herramienta gráfica que le ayuda a ejecutar sus suites de prueba. Su versión actual se implementa utilizando Tkinter como el marco de la interfaz gráfica principal. Entonces, ¿por qué no probar Toga dentro de otro producto de BeeWare? Eso es lo que he logrado durante mi trabajo de GSoC.
Resultados
La propuesta se centra no sólo en el puerto de Tkinter a Toga, sino en la asignación de los widgets necesarios para una aplicación real utilizando Toga. Para ayudarme a mapear esto he estudiado más sobre Tkinter, Toga, Colosseum, rubicon-objc, Objective-C, Cocoa y CSS.
El trabajo que hice durante GSoC se envió a través del PR 65, el informe en el Issue 58 y la demostración final se puede ver en este link. Había widgets utilizados en Cricket que no estaban listos todavía en Toga, por lo que era necesario hacer algunas mejoras en Toga para que pudiera usarlas en Cricket. En resumen, aquí hay algunos PR que contribuí para hacer mi trabajo en Cricket:
PR abierto enviado a Toga:
- PR 201 : [Core][Cocoa] Refactoring of the Tree widget
PRs emergidos enviados Toga:
- PR 112 : [Core][Cocoa] Enable/disable state for buttons, solved Issue 91
- PR 170 : [Cocoa] Content and retry status for stack trace dialog
- PR 172 : [Cocoa] Window resize
- PR 173 : [Core][Cocoa] Button color
- PR 174 : [Doc] Examples folder and button features example
- PR 178 : [Doc] Fix tutorial 2 setup
- PR 180 : [Doc] Update Toga widgets roadmap
- PR 182 : [Cocoa] Update the label of the Stack trace button for critical dialog
- PR 184 : [Core][Cocoa] Hide/show boxes widget
- PR 188 : [Cocoa] Fix error on MultilineTextInput widget, solved Issue 187
- PR 204 : [Core][Cocoa] Clear method to MultilineTextInput widget, solved Issue 203
- PR 206 : [Core][Cocoa] Readonly and placeholder for MultilineTextInput widget
- PR 208 : [Cocoa] Fix apply style to a SplitContainer widget, solved Issue 207
PRs emergidos enviados Cricket:
PRs emergidos enviados rubicon-objc:
- PR 34 : [Doc] Add reference to NSObject
Tiquetes abiertos enviados a Toga:
- Issue 175 : [Core] Add more properties for Label and Font widgets
- Issue 176 : [Core] Add "rehint()" on the background of the widget after changing font size
- Issue 186 : [Core] Set initial position of the divisor of a SplitContainer
- Issue 197 : [Core] Get the id of the selected Tab View on the OptionContainer
Tiquetes cerrados en Toga:
- Issue 167 : [Cocoa] Addition of a SplitContainer on a Box doesn't show the SplitContainer, was fixed by Russell Keith-Magee
- Issue 168 : [Cocoa] Addition of 2 boxes on an OptionContainer emits Rubicon's error, was fixed by Russell Keith-Magee
- Issue 169 : [Cocoa] Addition of 2 empty boxes on an OptionContainer emits error from Toga Cocoa platform, was fixed by Russell Keith-Magee
- Issue 181 : [Core][Cocoa] "Hide" option for widgets, was solved by me
- Issue 187 : [Cocoa] Errors on MultilineTextInput, was fixed by me
- Issue 189 : [Cocoa] ProgressBar doesn't appears in a Box, was fixed by Jonas Schell
- Issue 194 : [Cocoa] The frame of the MultilineTextInput doesn't appear, was fixed by Russell Keith-Magee
- Issue 195 : [Cocoa] ProgressBar doesn't appear inside of a Box oriented by row, was fixed by Russell Keith-Magee
- Issue 196 : [Cocoa] Set max value and value on a ProgressBar doesn't make any effect on the layout, was fixed by Russell Keith-Magee
- Issue 203 : [Core][Cocoa] Clear text on MultilineTextInput widget, was solved by me
- Issue 207 : [Cocoa] Set SplitContainer height doesn't update its size, was solved by me
Tiquetes cerrados que no reporté pero que resolví en Toga:
Tiquete cerrado que reporté a Cricket:
- Issue 59 : Run selected doesn't count/ runs every test selected in a test module, was fixed by me
Tiquete abierto que reporté a rubicon-objc Jonas Obrist repository:
- Issue 1 : Seg Fault when iterate through a NSIndexSet using block notation
Planes futuros
Hay algunas características en Cricket que quiero ayudar a desarrollar en un futuro próximo, por ejemplo:
- Un botón para actualizar todo el árbol de pruebas
- Configuración de Cricket
Además, hay algunos problemas que quedaron después de la migración a Toga. Estos problemas se arreglarán en Toga en un futuro próximo, por ejemplo:
- Una brecha entre la salida y los cuadros de error cuando no hay mensaje de salida
- Ejecutar una prueba si el usuario haga clic en ella
Realmente creo que Toga será el framework oficial en Python para construir GUI para aplicaciones multi-plataforma, así que seguiré contribuyendo a este proyecto porque quiero usar en todas las aplicaciones que necesitaría una GUI.
Consideraciones finales
Me gustaría agradecer a mis mentores Russell Keith-Magee y Elias Dorneles por guíarme y ayudarme tanto durante este período. La oportunidad de ser parte de esta comunidad fue un gran honor para mí, muchas gracias por aceptarme en este programa Russell Keith-Magee. Además, quiero agradecer a Philip James que hizo algunas reseñas en mis PRs y Jonas Schell quienes arreglaron un tema que envié a Toga.
2017 Google Summer of Code - Mejoras en Batavia
Con el programa Google Summer of Code 2017 llegando a su fin, es hora de resumir lo que hice durante el verano trabajando en Batavia.
Batavia es una parte de la colección de proyectos de BeeWare. Como todavía está en su primera etapa de desarrollo, por mi parte me ofreció implementar una serie de características que faltaban en Batavia, que van desde tipos de datos elementales, a través de la manipulación JSON y construcciones de lenguaje como generadores. Publiqué mi propuesta en este hilo de GitHub y lo mantuve actualizado con mi progreso semanalmente.
Ten en cuenta que al final de GSoC, hemos decidido divergir de la propuesta inicial y renunciar a la aplicación de contextlib en favor de la compatibilidad con Python 3.6, que usa op-codes de 2 bytes.
En general, fue una gran experiencia de aprendizaje y diversión. Muchas gracias a mis mentores Russell Keith-Magee y Katie McLaughlin, y a toda la comunidad de BeeWare.