[Ecls-list] Getting things going
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at gmail.com
Mon Oct 21 12:51:35 UTC 2013
I am sorry for the prolonged silence. I wanted to give some time for my
message to settle in the community, but since I have seen a lot of
interesting discussion we should make use of this momentum to get something
According to different private emails that I have received, a possible
reconfiguration of the project would look as follows:
- Dmitri Hrapof, maintainer
- Jon Boone, supporting developer (Common Lisp)
- Matthew Mondor, supporting developer (NetBSD / Linux)
- Juanjo García Ripoll, supporting developer
Plus whoever wants to contribute more actively. In particular it would be
appreciated some help on the fronts of regular automated testing and
release. Note that the degree of involvement can be very minimal: it
suffices that you build or work with ECL in some platform and provide
feedback or patches or simply point out problems -- i.e. Android, iOS
developers out there could become more involved by simply speaking up more
I just need your ok (and your account names) to redesign the project
composition in SF.
Once the issue of the team is settled, to get things up and running one
should make a list of what has to be done. Some ideas though:
- Priority should be to ensure that ECL is working again in all platforms
and that it is release candidate. I am partially working on this, as I do
not want the new life of the project to start with a broken software.
- Things that work should not be touched until momentum is gained. The
compiler is quite ok as it is, and should only be fixed when regressions
are found in the libraries. This said, I am willing to speak to anybody
about the internals, either in this forum or by private email or skype.
- Ideas for future changes or known problems could be organized in the form
of tickets, with us discussing the details below in the "forum-type"
discussion that pops up. Longer issues could be arranged by email.
Common-knowledge or things that you do not know about internals would be
better explained in the wiki, opening a page for the topic and me and you
filling in information.
- Each of us has their own interests. I have seen very interesting
suggestions from Matthew Mondor here. Those things should not be neglected
-- I will help you as much as I can on getting you moving on on each of
those fronts. Some things that have been mentioned by different people
* Improved embeddability and name convention
* Improving on streams & input methods (utf, etc)
* Neglected platforms that depend on separate ports (Android, iOS)
* New interpreter forms (Here the work of Dr. Schfmeister will probably
win whatever we think about :-)
* New FFI's, including C++
* POSIX libraries
I believe people overestimate the time / knowledge that is needed to get
things going in many of these fronts -- the UTF thing, for instance,
amounts to about 50 lines of code :-)
- I am here to help you with any of the internals or questions. One very
efficient way of doing that would be to assign tickets to myself on
specific questions that you are not able to resolve. For that one would
have to go through SF and create new categories and organize the tickets
more cleanly. Alternatively we can also create email discussions.
- There are technical issues that we should work together. Multithreading
is one. Right now the implementation of locks / mutexes / semaphores, etc,
is based on an idea (a wait queue that implements a per-thread semaphore
using signals) which I believe is solid, but is giving rise to a lot of
problems in various platforms. Issues like these depend on long email
conversations and technical discussions; help is welcome even from non
- Regular testing has been set up in the past using Anton's library. I can
pass you the scripts. Benchmarking has also been organized using automated
scripts that I can also pass you. As I said, this is one of the things
where a non-developer can really help a lot by providing the infrastructure
and uploading the information to some public space.
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel