1. RE: Eu OpenSource Vision
tone.skoda at siol.net wrote:
>
> ----- Original Message -----
> From: Martin Stachon
> To: EUforum
> Sent: Wednesday, September 26, 2001 6:29 PM
> Subject: Eu OpenSource Vision
>
>
> 2) Unite programing style and naming and formatting conventions.
> I would suggest the standart RDS style, expcept that tabs would
> be used for formatting instead of spaces. Optionally create a tool,
> similiar to C "indent" to automatically reformat sources.
> I was reading a lot about programming style last days, and I can explain
> to you why having spaces instead of tabs for indentation is better:
>
>
> if (one_v_do = 0) then -- No to_do pixel anymore.
> -- We've looped all pixels of object.
> ..
> end if
> In this example, you of course tabbed second comment so it will be
> aligned with first comment. But when you view this file in other editor
> which has different tab size, or if you change tab size in your editor,
> it will be messed up. Second comment line will either be very to the
> right or very to the left.
>
Yes, for this indenting are spaces better, but for
indenting after "if .. then" or "for .. do" are better
tabs
Martin
2. RE: Eu OpenSource Vision
David Cuny wrote:
> Martin Stachon wrote:
>
> > 1) Get larger user base. The most difficult and
> > most important point.
>
> This might get you more libraries, but why think that they will be any
> different than the undocumented, buggy, and abandoned libraries that we
> have
> now?
I think it is a difference if a library is written by
a simple guy in his spare time or if there are several people
improving the product every day.
> I think that there are enough people in the current set of users to
> write
> libraries. The simplest way to do this is to offer a cash incentive.
> Want a
> DirectX library? Offer someone cash to write one. Otherwise, you're
> asking
> people to do something for you for free. If it's not an itch they
> currently
> feel (for example, I don't have any compulsion to use DirectX), they
> don't
> really have any reason to write it.
I'm now under impression of the Linux world. So many useful
programs and libraries are for free. Nobody is offering the people
a cash. They are doing it just for their good feeling they're
doing something for everyone, and maybev a bit of fame
> I suspect that things will change when Robert starts releasing the
> Euphoria
> source code. It will suddenly be a *lot* easier to link Euphoria to
> C/C++
> libraries such as DirectX.
>
>
> > 2) Unite programing style and naming and formatting conventions.
> > I would suggest the standart RDS style, expcept that tabs would
> > be used for formatting instead of spaces. Optionally create a tool,
> > similiar to C "indent" to automatically reformat sources.
>
> How would you enforce this? Not accept code that doesn't follow the
> conventions?
>
> Writing a program to format code could be difficult, given that a single
>
> statement can wrap over several lines.
>
> Finally, some people prefer to prefix variables by their type (iCount
> for
> integer counter, for example). Some used mixed case (likeThis instead of
>
> like_this) for identifiers. Some use initial caps (This instead of THIS)
> for
> constants. Even where to put commas in a constant statement: was argued
> a
> while back:
>
> -- this
> constant
> this = 1,
> that = 2
>
> -- or this
> constant this = 1, that = 2
>
> -- or even this
> constant this = 1
> , that = 2
>
> I think it will be difficult to unite people behind a single coding
> style.
For example, Linux kernel has a united coding style.
I think the most important ascpect of coding style is naming
variables - it would be confusing to have a library with
fooBar(), foo_bar() and FooBar()
> > 3) Unite way to submit patches. If more people were working on single
> > project, the current practise of sending whole changed libraries or
> > describing "change this there and that over there" would be
> > uneffective.
>
> I haven't heard patch submission as being a major issue.
But it would be good, especially with larger projects.
> > 4) Make Euphoria interpreter aviable for free, or at least remove the
> > 300
> > statement limit.
>
> Euphoria is a commercial product. Why would Robert give it away?
A few of commercial products have been given to public.
Binding would remain in the 'commercial' release, but removing
the 300 statements limit would attract more OpSo developers,
hopefully, from other languages. (Why would a Perl, Python, C
etc. programmer try some 'shareware') Some GNU people
accept no commercial software.
> > 5) Set up a page for Eu OpenSource projects with mailing lists,
> > info, news, progress status, what can be done, latest patches etc. etc.
>
> I don't see how making it Open Source would fix your issues. Removing
> all
> commercial incentives could even kill Euphoria. I have no doubt that the
> code
> is fairly complex, and would require a lot of work to understand and
> change.
> How would you control forking? What problem does this solve? We'd change
> from
> the current model of having Robert working on Euphoria full time to no
> guarantee of anyone working on Euphoria at all.
>
> -- David Cuny
Rob would remain as the main programmer, while the others would make
some optimizations, bug fixes, testing etc. Lot of people could work on
the E2C Translator (I think it can be more optimized), while Rob
would have more time.
Just a poor's boy opinion, but I think OpenSource is the future.
Martin
3. RE: Eu OpenSource Vision
David Cuny wrote:
> in the past. I'll just point again to Pete's Euphoria, which has
> virtually
> fallen off the face of the earth.
>
I have looked at the code but had so many problems trying to
understand it that I gave up because it is not fully commented.
Bernie
4. RE: Eu OpenSource Vision
On 1 Oct 2001, at 23:44, Bernie Ryan wrote:
>
>
> David Cuny wrote:
> > in the past. I'll just point again to Pete's Euphoria, which has
> > virtually
> > fallen off the face of the earth.
> >
>
> I have looked at the code but had so many problems trying to
> understand it that I gave up because it is not fully commented.
If it is an interpreter, wouldn't you just run it like the RDS real interpreter?
I have been busy with other things, but i put that interpreter at the bottom of
my list because you (David) said it ran so slowly. I still have the code here,
circa late last year. How is it still being supported?
Kat
5. RE: Eu OpenSource Vision
David Cuny wrote:
> Did that answer the question? Perhaps Pete or Menno would like to chime
> in
> here.
Okay.
I got an email from Menno the other day basically asking what am I doing
and why he doesn't hear from me...
> Pete sort of disappeared - he graduated,
Class of 2000, Bachelors in CS
> got a job,
Rational Software - working with Apex (Ada/C++ IDE)
> and hopefully a life.
Still hoping. :)
> Menno picked up on Pete's work and has been occasionally releasing
> updates to
> it, but it's sort of stagnated.
Menno was using DJGPP or Borland and it stopping compiling on Linux or
CygWin, so I gave up on maintaining it.
> It's been mentioned that Pete's code is under-commented,
Yeah, I regret not commenting it because now I can't even remember how
it's supposed to work.
> In fairness, Euphoria does a lot of stuff for the user behind the
> scenes:
> reference counting, garbage collecting, resizing sequences, making
> unique
> copies, slicing... Pete's was a bit more complex, because (if I recall
> correctly) he also implemented strings as a seperate datatype. Getting
> it to
> work right is a rather delicate art - getting to work quickly and
> efficiently
> is something else all together.
Yeah, it did internally keep two types of sequences. I felt that using
4 bytes instead of 1 was an awful waste when storing large amounts of
text or graphics. Since most IO or graphics routines would have to
convert the 4-byte to 1-byte anyway (via puts or poke) why not leave the
sequence in that format. Irv and others were clamoring for that for a
long time. It made the sequence operations slower because it always had
to check what kind of sequence it was, and each operation was 4 to 8
times as complex (string op sequence, sequence op string, sequence op
sequence, string op string, atom op sequence, atom op string, etc.)
I've been giving (too much) thought to the concept of bit-sequences, as
an alternate representation of integer types. This would allow faster
bit slices or shifting without having to resort to silly hex masks and
multiplication or floored division. I liked the recent post about a
faster int_to_bytes using poke4+peek. That demonstrated exactly how
unexpectedly inefficient euphoria can be about the most trivial things.
> Yes. I think there were some cross-platform issues with Peuphoria. I was
>
> under the impression, for example, that Pete wasn't able to get it
> running on
> the Mac. There may have been Linux issues as well.
I don't have a Mac (or emulator) or compiler with otherwise I would. I
had compiled it on BeOS once, but I could never get the dynamic library
stuff to work. Linux basically worked from the command line, there were
a few problems with dynamic library routines but those were the source
of some major headaches.
> But I think if Pete got interested again, he could speed it up a bit.
> (hint hint).
I've got some ideas... they're just notes for now. I won't commit to
anything though.
> It's been a while since I've seen any release from Menno.
> As far as I know, the project is basically dead.
Basically. You can still download the various releases from
http://www.harborside.com/~xseal/euphoria/
Later,
Pete E.
6. RE: Eu OpenSource Vision
Pete E wrote:
>
> I've got some ideas... they're just notes for now. I won't commit to
> anything though.
>
> > It's been a while since I've seen any release from Menno.
> > As far as I know, the project is basically dead.
>
> Basically. You can still download the various releases from
> http://www.harborside.com/~xseal/euphoria/
>
> Later,
Hey Pete:
Glad to know your still around.
Maybe you can clear up somethings about PEU,
by simply adding a few comments to PEU.
What is the purpose of the typedef's procedures
and functions in the bound.h
Explain how decode works, etc.
Please when you get some time try adding a few comments.
It doesn't look like ROB will release source code until
at least BOXING day or later if he even does at all.
I think the users are getting impatient waiting for him.
At least we could work with your code, if it was more
commented. I'am sure that their are many users that would
like to contribute to it.
Bernie
