|
From: | Raphael Mack |
Subject: | Ideas for LibertyEiffel |
Date: | Thu, 18 Feb 2016 22:03:32 +0100 |
Hello, LibertyEiffel - the GNU compiler for the Eiffel programming language - would like to participate in the GSoC, and we already filled the organization application at Google, as we did not know about GNU as participating as umbrella organization at the beginning. For us it looks, as it would make more sense to participate as part of GNU, so we think of keeping our direct application and state there, that we can also participate under the GNU umbrella. Mainly because we already filled the application form and I think with this we show that we are really interested and that we even would be willing and able to handle the organizational work ourselves. Even though I do not really expect that Google would choose us as separate organization as we could be under the GNU umbrella. So I believe that it makes sense to have our project ideas also in the GNU idea list. Is this reasonable or what do you think? Concerning the site: https://www.gnu.org/software/soc-projects/guidelines.html It contains a link to http://google-melange.com/ which should probably be replaced by 2016s link: https://developers.google.com/open-source/gsoc/ I attach the Ideas for the LibertyEiffel project for the inclusion on the GNU idea list. Cheers, Rapha
LibertyEiffel is the GNU compiler for the Eiffel programming language. We have several ideas for the Summer of Code for different levels of Eiffel experience. Find the full list, contact data, mentors and additional infromation on the external website in our wiki. Here we have a short overview of the proposals.
Summary: Integrate LibertyEiffel into Eclipse with Syntax highlighting, compilation (and parsing the output) and the sedb debugger
Difficulty: Easy
Skills: Java knowledge, basic Eiffel knowledge or interest, experience with Eclipse (plugin development) would be good
Notes: Target is to have a Liberty integration similar to the CDT for C. A few years ago the the project Eclipse Eiffel Development Tools (EDT) was started, which could be used as starting point, but this project targeted the commercial ISE compiler.
Summary: Make the LibertyEiffel compiler emit C11 compatible C code without warnings even on the higher warning levels of gcc
Difficulty: Advanced
Skills: Deep experience in C programming, basic Eiffel knowledge
Notes: The target is not to make the code requiring a C11 compatible compiler (e.g. by using new features) but to remove warnings in strict std modes. Can be extended to apply additional static checkers like pclint, MISRA rules, etc.
Summary: LibertyEiffel in theory is running several platforms, but recent development was limited to a GNU/Linux environment and for Microsoft Windows no compiler is known to work. Target is to integrate a free C compiler (e. g. PellesC), including necessary fixes to generate accepted C code, add missing implementations for plugins (exec, net), run test suite on MS Windows.
Difficulty: Easy
Skills: Experience with C programming on Windows, basic Eiffel knowledge or at least interest to learn it
Notes: Would be great if a installer package would be one of the outcomes.
Summary: many ECMA features are already supported, implement the missing ones (beside No-variant agent conformance, which is not planned to be included in LibertyEiffel)
Difficulty: Advanced
Skills: Deep Eiffel knowledge, willingness to dig into the ECMA standard document
Notes: obviously test cases shall also be derived (integrated into the test suite and passed) for the new features
Summary: Implement a new version of the tool eiffeltest, to execute the test suite
Difficulty: Advanced
Skills: Good Eiffel knowledge, interest in Software testing
Notes: the features should include: parallel test execution, time/progress monitoring and estimation, improved test status (ET integration), Coverage measurement (different criteria like Branch, MC/DC)
Summary: Improve the applicability of LibertyEiffel programs to small embedded systems, by introduction of a mechanism to prevent dynamic memory allocation.
Difficulty: Hard
Skills: Deep understanding of Memory Managment, Eiffel experience
Summary: In lieu of the project above (Embedded System Readyness) implement an ARM (cross-)compiler backend. As LibertyEiffel generates Std-C code, this project redefines into evaluating and selecting a suitable open source ARM compiler and integrate it in the LibertyEiffel system back-end.
Sifficulty: Easy/Medium
Skills: Understanding of C Compiler and a deep understanding of scripting languages to implement integration of the compiler.
Summary: Back in the SmartEiffel times there was a JVM backend, which compiled Eiffel to Java bytecode. This should be made working again with an example to build an Android App in Eiffel.
Difficulty: Hard
Skills: Good Eiffel experience, Knowledge of Java Bytecode and Compiler technology.
Notes: The option with difficulty "Unmanageable" would be to merge this with Eclipse integration and write the eclipse code plugin in Eiffel ;-)
Summary: generate proof obligations from contracts for formal verification, e. g. by generationg of ACSL specifications from the Eiffel contracts to use Frama-C as "verification backend"
Difficulty: Hard
Skills: background in formal verification, Eiffel experience
Summary: Add C++ support to wrappers-generator
Difficulty: Advanced
Skills: Good C++ knowledge, Good Eiffel experience.
Notes: C++ support could be a boon yet it would pose quite a few tricky problems as C++ object model differs from Eiffel's in some ways.
Summary: Add wrappers for scientific purposes: complexes, intervals, arbitrary precision integers and floats. Interesting libraries could be:
Summary: Implement an Eiffel to _javascript_ transcompiler
Difficulty: Easy/Advanced
Skills: Medium Eiffel knowledge, good knowledge of _javascript_
Notes: _javascript_ is the new "write once run everywhere" as it is quickly becoming the new lingua franca of the web. Having an Eiffel to _javascript_ compiler would widen the usage fields available to Eiffel. A naive compiler would be easy; something that doesn't require writing tons of glue Eiffel libraries would be quite a harder task. Think about what's to provide "usable" wrappers for libraries such as RaphaelJS or Angular. Their design is all but strongly-typed.
[Prev in Thread] | Current Thread | [Next in Thread] |