Another student, Santosh Vattam worked on improving the Object Coverage of our test suites for a core part of RTEMS. Our initial coverage reports were generated for the SPARC/ERC32 using the closed source simulator TSIM. Santosh and I, his mentor, addressed cases which appeared to be test suite deficiencies while apparent simulator anomalies were passed on to Xi. During this, an obscure bug in RTEMS was uncovered and Xi and I worked together via chat to solve it. At the end of the summer, 3 SPARC and 2 ARM configurations were either at 100% or very close.
Santosh's project was a tie-in to the work of Roxana Leontie. Roxana operated under the same rules as Google Summer of Code but worked outside of the program. Her project was updating the Nano-X RTEMS port and providing a new RTEMS framebuffer device interface, and her first succesful demonstration was running the Nano-X Minesweeper program on RTEMS. As Roxanna progressed, Xi updated his LCD framebuffer driver to match her new interface.
Aanjhan Ranganathan's project was to provide a generic interface for RTEMS applications to use the Memory Management Hardware Unit available in most recent embedded processors for memory protection. His major tasks included studying the PowerPC MMU hardware architecture implementation and behavior, to propose a multi-level API design within the scope of RTEMS infrastructure. Most of the above tasks have been accomplished successfully and tested, but a lot of scope for further work exists.
Josh Switnick had a project which suffered from those unexpected "challenges" that make software development interesting. His project was to port RTEMS to the 8-bit AVR, as RTEMS had previously only been ported to 16- and 32-bit architectures. Mentors worked with Josh to produce a cross-toolset built with AVR specific libc support ported from AVR-LIBC to newlib, and to build the free AVR simulator simulavrxx. Josh produced a working port and is continuing to work to tidy up the loose ends.
Lucian Cocan's project was to continue the 2008 Google Summer of Code project of Real-Time trace. Lucian's initial work was to package the work into something that is suitable for a user. The tool was modelled on the command line tool, libtool, as it provided a simple yet consistent interface for the user. Lucian successfully produced traces for a number of the sample programs plus the example priority inheritance capture engine example.
JiSheng Zhang's project was to implement run-time dynamically loading relocatable object files or libraries into RTEMS, which is based on the IEEE Std 1003.1-2004 API (dlfcn.h) interface. Jisheng completed the basic functions of elf loader after the midterm, then he worked on figuring out how to get the dependencies included in the RTEMS kernel. Currently two tools are supported, i386 and sparc, and Jisheng is continuing to work on add other architecture support such as m68k, power pc, mips, and arm etc.
You can read my full report about our 2009 Google Summer of Code experience on the RTEMS wiki.
Student: Andriy Kushnarov, Mentor: Ingo Renner
The first project was centered around providing a better infrastructure for translators. TYPO3's backend interface is available in 49 languages but the existing translation server had some limitations which this project aimed to resolve. First up, the most severe limitation was that people wanting to contribute to the translation of the user interface strings would need to obtain a backend login to the translation server, and information on how to do that and the fact that a translation server exists was quite hidden. Other limitations affected the translation process itself by not allowing multiple suggestions for translations or targeting different versions of the CMS where labels might have changed.
Andriy was given the task of revamping the translation server to be open to everyone without needing any additional user account besides the existing typo3.org account. The new translation server should allow everyone to make suggestions for translations and vote for existing suggestions so that chief translators would simply have to accept a well voted suggestion. Technically the translation server was supposed to be based on Extbase to be future proof. This however also resulted in being a challenge because Extbase itself was constantly changing because it was still in development itself. In the end the new translation server is not ready yet but the TYPO3 community learned a lot in terms of what we need to look for when finishing this project. It's a great start but there's still some way to go before the existing translation server can be replaced. Andriy and other TYPO3 community members have already signaled that they're going to keep contributing towards that goal.
Student: Ingmar Schlecht, Mentor: Jochen Rau
The second TYPO3 4.x project was about creating a new kickstarter. As with the translation server, a predecessor already existed but something new was needed. In this case it was not because the existing solution was bad, but because the new kickstarter needed to complement the new Extbase MVC framework instead of the aging plugin base classes.
As with the old kickstarter, the aim was to create an extension that itself would allow to create new extensions by selecting and configuring extension components through a graphical user interface in TYPO3 itself. In the end the kickstarter will allow generation of Extbase extensions with frontend plugins, backend modules, database tables with their according models, and services.
The user interface is based on the Yahoo UI WireIt library, which enables domain modeling in a nice interface with boxes representing models and their properties and wires representing the relations between those model objects. The code generating part is completely based on Extbase itself, which means that the code generated actually comes out of Fluid templates, which can easily be adopted for future Extbase versions for example.
Generally, the project is about 70% done towards a first fully working version (yet with a reduced feature set compared to the old kickstarter). In the mean time, a number of people have shown interest in helping to further develop the Extbase kickstarter, and have already joined the project, with some of them even having done first commits already.
Student: Andreas Förthner, Mentor: Robert Lemke
This is the first of two TYPO3 5.0 / FLOW3 projects. Andreas had already worked on FLOW3's security framework before as the main developer which was why he was chosen to carry on this task during the summer. Meanwhile he also got elected as co-leader of the TYPO3 security team.
To make the security framework usable in real life applications various functionalities are required. For example many authentication mechanisms need to be provided to integrate FLOW3 applications flawlessly with existing infrastructures. A general goal is to provide a transparent security framework, which supports the developer as much as possible in writing secure web applications without needing to be security specialist.
At the beginning of the project it was not possible to have information that would survive a page request, so that the first task was to create a mechanism to allow information being persisted for the time of a session, which is essential for user authentication.
>After the session persistence scope for information was in place the next task was to create an user account infrastructure so that actual users could be created and use the previously created authentication mechanism to log in to some kind of management backend.
Other than that general improvements to the authentication framework have been made and a lot of unit tests have been created for all new code. All the code created is already merged into the FLOW3 framework.
Student: Tamas Ilsinszki, Mentor: Karsten Dambekalns
The second FLOW3 project also had the second TYPO3 newcomer assigned as student. The project had a challenging and complex goal in that Tom needed to dig into the JSR-283 specification first, then walk through the existing code to produce a plan. The optimistic goal of having versioning working by the end of the summer was not hit, but given the circumstances (e.g. the fact the content repository as a whole is still in rather heavy development) the result was fine.
When the work started in a separate SVN branch there were some small quality issues, but Tom was quick at picking up our coding guidelines and test requirements. He produced code that enables some features crucial to implementing versioning in the content repository, and while they have not yet been merged into the main branch that will be done this spring.