1. RE: Digest for EUforum at topica.com, issue 5548
- Posted by Cuvier Christian <christian.cuvier at insee.fr> Jan 16, 2006
- 499 views
Subject: Re: ESL, will it ever get anywhere? Cuvier Christian wrote: > > > Subject: Re: ESL, will it ever get anywhere? > > > > > > posted by: D. Newhall <derek_newhall at yahoo.com> > > > > (In reply to Chris Burch) > > > > Chris, feel free to do this if you want, all I ask is not to > > use ESL or the name Euphoria Standard Library. > > > > The point behind the ESL (and it's biggest fault so far) is > > that anyone can propose stuff and we'd agree on everything as > > a group. I'm sure if Chris Cuvier (the other person who's > > really into this) or I did it with our word as law we'd be > > done by now but we wanted to allow the community to > > contribute with everything. Sadly, this has caused much delay > > along with Real Life getting in the way occasionally. > > > > You have the freedom to do this if you want. However, > > honestly, I'd prefer you didn't since we hope to get > > everything started full throttle soon (we mean it this time!) > > and we were hoping to have everything unified, standardized, > > and full documented. I think lack of uniformity would be the > > biggest issue. Our naming conventions were made to fit with > > Euphoria's current scheme whereas with your method you could > > get stuff like "esl_iGetKey" and then have > > "esl_process_keystroke" in the same file which could throw > > off many users. > > > > > > The Euphoria Standard Library project : > > <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a> > > The Euphoria Standard Library mailing list : > > <a href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://l ists.sourceforge.net/lists/listinfo/esl-discussion</a> > > > > In addition, never forget that testing and properly documenting any project > take more time > than actual coding. Hence the temptation to cut on the former, which > invariably proves > horribly costly a few months later when trying to debug or upgrade. > > The less people work on the library, the longer it will take to be released, > and the lower the maximal expectations about quality (extensivity of > testing, quality of internal and external documentation, presence and > quality of end user documentation, not mentioning the actual contents of the > package). Because people involved may not be professionals and may not have > full days to spend on the project. > > Any joiners? > > CChris > > Hi Sure, I'll put my money where my mouth is - email me with some tasks. Chris --------------- Ok, fairly simple. It's about 10am UTC. Tonight (12-14h from now), I'll have uploaded updated versions of some modules here: oedoc.free.fr/Fichiers/ESL (path is case sensitive). Each module is in a XXX.zip file, containing: XXX.e (code), spec_XXX.txt (specs), and test_XXX.e (test program). Only look at the ones dated Jan 2006, as the update process on my side will take this whole week. Then you can review the code and documentation, add to the test program, and share all this with the ESL mailing list. Also, voicing your opinions on the coding, doc and module creation guidelines could help hammering them out. Some elements in my code depend on aspects that are not settled yet (error handling, printing/getting custom types, etc). CChris