Re: Standard Euphoria Library project
Christian Cuvier wrote:
>
> > 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 <<a
> > href="http://oedoc.free.fr/">http://oedoc.free.fr/</a>>, 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.
Isn't the STL mostly or all container classes? Many of those wouldn't apply to
Euphoria because of the existence of sequences. The ones that do could easily be
done in libraries.
> 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.
Use the Makedoc from win32lib and document the library properly...
> Regards
> CChris
> > Regards,
> > Juergen
>
>
=====================================
Too many freaks, not enough circuses.
j.
|
Not Categorized, Please Help
|
|
