Re: Standard Euphoria Library project
> Date: Thu, 07 Jul 2005 17:16:07 +0200
> From: "Juergen Luethje" <j.lue at gmx.de>
> Subject: Re: Standard Euphoria Library project
>
>
> Christian Cuvier wrote:
>
>
>>> From: "Juergen Luethje"
>>>
>>
>>>>> Christian Cuvier wrote: <snip>
>>>>>
>>>
>>>>>>>>> The Standard Euphoria Library project on Sourceforge is dead.
>>>>>>>>> The OpenEuphoria group, which is the one you're referring to, is dead
>>>>>>>>> as
>>>>>>>>> well.
>>>>>>>>> Its homepage is at oedoc.free.fr actually.
>>>>>>>>>
>>>>
>>>>>>>>>>>>> Now I wouldn't want to organize such a thing because I am not an
>>>>>>>>>>>>> experienced
>>>>>>>>>>>>> developer. But I would want to contribute ideas, documentation,
>>>>>>>>>>>>> or code..
>>>>
>>>>>>>
>>>>>>>>> I was originally the doc manager for OpnEU. I wound up docig sequences
>>>>>>>>> in C++ when the group imploded. Now I'm admin of a souceforge defunct
>>>>>>>>> project. Wanna get in?
>>>
>>>>>
>>>>> I'd like to join the Standard Euphoria Library project. 
>>>>>
>>
>>> I just checked out on sf: that project doesn't even show up in the
>>> search results for "Euphoria". It appears to have produced no file at
>>> all last time I had checked (possibly 1 year ago). I'd pronounce it dead
>>> and buried.
>>>
>>> Otherwise, sourceforge.net/projects/peu hosts the same specs as you'd
>>> find on my website.
>
>
> I visited your site <http://oedoc.free.fr/>, looked at the "Original
> mission statement for OpenEuphoria" which is linked there, and
> downloaded "OEdoc_v1_4.zip". I'm impressd, you guys did a considerable
> amount of work!
>
> But I think most of this can't be used for the Standard Euphoria Library
> project, because it's a different beast. We need a new "Mission
> statement", maybe that's the first thing we should create.
>
Agreed. The aim of OpenEuphoria was to incorporate features that are not
feasible using external libraries, or feasible only at a hefty
performance penalty.
> Then maybe we should write down some internal standards, i.e. an
> internal naming convention, and a standdard for the way we create the
> modules of our library. We could use the text that Derek posted here
> recently as guideline.
>
> Just some more thoughts:
> - Build one module after the other.
> - When one module is finished, release a new version.
> - For a new module, first someone writes the specs.
> - The specs are discussed in the project group.
> - Then one (ore more) person(s) write(s) the code for the module.
> - Then at least 2 persons -- and only persons who didn't write the
> code -- check whether the code meets the specification independently
> of each other. One of these "peer reviewers" should be an IT
> professional.
> ( Well, how much of them participate in the project? )
> - The documentation should be written (or at least be "polished") by
> native English speakers.
>
On the principle, I agree again with all points. However, we can make
things much simpler as follows:
C++ provides a Standard Temlate Library which is remarkably
well-thought, and whose design was polished by hundreds of qualified
persons. Why reinvent the wheel?
Let's start from the public specifications for this "library", and the
only job left, apart from coding, will be to define which areas won't be
implemented (mostly because of the limitations Eu has). Docs already
exist, they'll have to be translated into the framework of Euphoria (for
instance, Eu has no pointers...). Again, the idea is not to start from
scratch.
Another thought: specs are good, but the end user generally can't use
them. There will be a need for an User Guide to supplement the specs.
That User Guide should be written by people not involved n writing the
specs. It will be organised around the users' needs (tasks to perform),
showing how the tools in the library can be used for completing these
tasks. The fine technical points will be covered either in the specs or
in specific release notes, according to their being more or less structural.
Regards
CChris
> Regards,
> Juergen
|
Not Categorized, Please Help
|
|
