1. Open Source, then...?
- Posted by akusaya at gmx.net
Nov 11, 2006
Nice to see the Eu went open source, .. at least in the following 2-3
days after the open source release.
Now what happens to Eu? Looks like no different from before.
Maybe some people now already started to make their own version of Eu,
and in a year maybe 4 different Euphoria derivatives come (e.g.
Elation, Bliss, Joy, Exhilaration..).. and very possibly none of them
has a significant market.
I think what is absolutely needed now is a repository of code (where
people can contribute codes, like other open source projects like
Firefox). Documentations should be there also, so that users don't
need to say "There is this mistake in this doc page!" in this mailing
list anymore.
Currently if one encounters a bug, he/she will report to Rob via this
mailing list and then Rob will fix it in the next release (which is
indeed faster but still 2-3 weeks which is too slow!).
Having the repository will fix the bug in 1 or 2 days (provided more
and more people come to understand the C codes).
Actually everyone can make Eu source code repository but it would be
better and more courteous if Rob make it himself.
Any opinions?
2. Re: Open Source, then...?
- Posted by Ray Smith <ray at RaymondSmith.com>
Nov 11, 2006
-
Last edited Nov 12, 2006
Hi Akusaya,
See comments below:
akusaya wrote:
> Now what happens to Eu? Looks like no different from before.
There won't be any major difference for a fair while.
I predict 1-2 years before we see any results (for normal users of Eu) of Eu
going open source.
> Maybe some people now already started to make their own version of Eu,
> and in a year maybe 4 different Euphoria derivatives come (e.g.
> Elation, Bliss, Joy, Exhilaration..).. and very possibly none of them
> has a significant market.
Possibly.
I agree, I was very outspoken on my point of view of using a license
which stopped closed source variations to be created.
Only time will tell if this splits (or grows?) the Eu community.
> I think what is absolutely needed now is a repository of code (where
> people can contribute codes, like other open source projects like
> Firefox). Documentations should be there also, so that users don't
> need to say "There is this mistake in this doc page!" in this mailing
> list anymore.
I agree, a central repository should be created.
It isn't "urgent". Anyone can still post their patches or modifications to the
list and Rob can incorporate them if applicable.
The central repository doesn't make it available for anyone to change. It is
still controlled (originally by Rob and in the future by a small number of
people who have proved their knowledge and commitment).
> Currently if one encounters a bug, he/she will report to Rob via this
> mailing list and then Rob will fix it in the next release (which is
> indeed faster but still 2-3 weeks which is too slow!).
I agree,
The repository will make this instant ... "svn update" (if using subversion).
Even in the mean time ... I'm sure Rob would provide patch files if requested?
It can't hurt to ask!
> Having the repository will fix the bug in 1 or 2 days (provided more
> and more people come to understand the C codes).
>
> Actually everyone can make Eu source code repository but it would be
> better and more courteous if Rob make it himself.
>
> Any opinions?
Eu being open sourced is exciting ... but it will take a number of years for
the full impact to be seen.
I would seem to agree that a central repository (and maybe an online bug
tracker)
would be the next steps. (Sourceforge seems to be a good choice??)
Regards,
Ray Smith
http://RaymondSmith.com
3. Re: Open Source, then...?
- Posted by Robert Craig <rds at RapidEuphoria.com>
Nov 11, 2006
-
Last edited Nov 12, 2006
akusaya wrote:
> Nice to see the Eu went open source, .. at least in the following 2-3
> days after the open source release.
>
> Now what happens to Eu? Looks like no different from before.
>
> Maybe some people now already started to make their own version of Eu,
> and in a year maybe 4 different Euphoria derivatives come (e.g.
> Elation, Bliss, Joy, Exhilaration..).. and very possibly none of them
> has a significant market.
I'm sure that will happen, but some of the ideas, code,
and expertise may flow back into the mainstream version.
> I think what is absolutely needed now is a repository of code (where
> people can contribute codes, like other open source projects like
> Firefox). Documentations should be there also, so that users don't
> need to say "There is this mistake in this doc page!" in this mailing
> list anymore.
Yes, that must happen eventually. Maybe soon.
> Currently if one encounters a bug, he/she will report to Rob via this
> mailing list and then Rob will fix it in the next release (which is
> indeed faster but still 2-3 weeks which is too slow!).
I don't think many users want to re-install Euphoria every
2 or 3 weeks. Only developers and testers need quick turn-around.
> Having the repository will fix the bug in 1 or 2 days (provided more
> and more people come to understand the C codes).
>
> Actually everyone can make Eu source code repository but it would be
> better and more courteous if Rob make it himself.
>
> Any opinions?
Already I expect to incorporate into the official source:
- the work of Konstantinos Tampouris in
adding two more C compilers to those supported by the Translator.
- the Mac OS X code from Alban Read
- the install program changes from Juergen Luethje
We will then need people to test these changes.
Mainly I'll be worried if someone's changes break
existing functionality, not whether the new functionality
actually works. I don't have time to fully test other peoples' code.
So we'll need an "under development" version that developers
can work on. I'm not sure whether to set up the code repository
before or after making these initial changes. I'm open to suggestion.
Some procedures for changing the code will emerge.
There's a political process as well as a mechanical
process leading to a change in the source. At the moment,
I'm still a kind of dictator, at least over the "official"
version, but I expect to give up more control as other people
learn more about the internals, and show that they can make
complicated changes without wrecking things. I may become
more of an overall Q/A type of person, rather than a major
initiator of new development. We'll see.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Open Source, then...?
- Posted by Jeremy Peterson <ptl99 at hotmail.com>
Nov 11, 2006
-
Last edited Nov 12, 2006
Robert Craig wrote:
*snipped*
> Already I expect to incorporate into the official source:
>
> - the work of Konstantinos Tampouris in
> adding two more C compilers to those supported by the Translator.
>
> - the Mac OS X code from Alban Read
>
> - the install program changes from Juergen Luethje
>
>
> Regards,
> Rob Craig
There is a version for Mac OS X?
Jeremy
5. Re: Open Source, then...?
Yes, see The Archive. I believe it has a bug though in the Dynamic Library
support. I tried wrapping libdbi and it fails randomly. Wrapping pgsql did the
same thing, random weirdness.
Jeremy
http://jeremy.cowgar.com
6. Re: Open Source, then...?
- Posted by alban read <alban.read at mac.com>
Nov 14, 2006
-
Last edited Nov 15, 2006
Jeremy Cowgar wrote:
>
> Yes, see The Archive. I believe it has a bug though in the Dynamic Library
> support.
> I tried wrapping libdbi and it fails randomly. Wrapping pgsql did the same
> thing,
> random weirdness.
>
> Jeremy
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
About OSX Intel components random dynamic library chaos..
Sorry - the random chaos in dynamic library calls is being caused by at least
two problems.
One is that Mac OSX (Intel) expects each half of a double to be copied the
opposite way around
to the way you would push them onto a stack. This may makes sense since they
are being copied
on rather than pushed down. That is very easy to do as it doesnt change the
function much.
The other problem is that the entire argument list needs to be reversed.
e.g If you called mul(22/7) it would end up doing mul(7/22) which doesnt matter,
but div(22/7)
compared to div(7/22) would matter quite a lot :)
Things seem to work a lot better if the arguments in the list are reversed then
copied.
I have tested copying the arguments into a buffer and then copying them out of
the buffer
in reverse order, this was easy to add to the call_c function.
It seems wrong to copy arguments out of the sequence twice.
I thought about reversing the argument sequence - but that may be slower if
anything.
Reading the sequence of arguments in reverse would work, if that was easy to do.
Another option would be to work out the complete argument list size (in bytes),
add it the
pointer then copy the arguments on in the reverse direction, decrementing the
pointer as you
do it. I dont know what is likely to be fastest and most reliable.
7. Re: Open Source, then...?
- Posted by Bernie Ryan <xotron at bluefrog.com>
Nov 14, 2006
-
Last edited Nov 15, 2006
alban read wrote:
>
> Jeremy Cowgar wrote:
> >
> > Yes, see The Archive. I believe it has a bug though in the Dynamic Library
> > support.
> > I tried wrapping libdbi and it fails randomly. Wrapping pgsql did the same
> > thing,
> > random weirdness.
> >
> > Jeremy
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
>
> About OSX Intel components random dynamic library chaos..
>
> Sorry - the random chaos in dynamic library calls is being caused by at least
> two problems.
> One is that Mac OSX (Intel) expects each half of a double to be copied the
> opposite
> way around
> to the way you would push them onto a stack. This may makes sense since they
> are being copied
> on rather than pushed down. That is very easy to do as it doesnt change the
> function much.
>
>
> The other problem is that the entire argument list needs to be reversed.
> e.g If you called mul(22/7) it would end up doing mul(7/22) which doesnt
> matter,
> but div(22/7)
> compared to div(7/22) would matter quite a lot :)
>
> Things seem to work a lot better if the arguments in the list are reversed
> then
> copied.
> I have tested copying the arguments into a buffer and then copying them out
> of the buffer
> in reverse order, this was easy to add to the call_c function.
> It seems wrong to copy arguments out of the sequence twice.
> I thought about reversing the argument sequence - but that may be slower if
> anything.
> Reading the sequence of arguments in reverse would work, if that was easy to
> do.
> Another option would be to work out the complete argument list size (in
> bytes),
> add it the
> pointer then copy the arguments on in the reverse direction, decrementing the
> pointer as you
> do it. I dont know what is likely to be fastest and most reliable.
Alban:
OSX was written originally for the PowerPC.
The Euphoria source code was written for Intel X86 PC.
PowerPC stores the most significant byte first while x86 stores the least
significant byte first. Byte ordering is also referred to as endian format;
PowerPC uses big endian, and x86 uses little endian.
You would need to write the code for the type of MAC OSX that you are
running on or create the code for Universal Binaries on Mac OS X.
Here is a link that might interest you.
http://developer.apple.com/macosx/adoptinguniversalbinaries.html
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
8. Re: Open Source, then...?
- Posted by alban read <alban.read at mac.com>
Nov 15, 2006
-
Last edited Nov 16, 2006
Thanks very much Bernie for the tip there is quite a bit of reading material
there.
The good news if you are interested in powerpc is that Euphoria does at least
compile
and appear to run in powerpc mode as well.
Some code would need to be rewritten to allow the ppc version to link into any
libraries.
I only had to comment out one line to make an exuppc file. This seems to run
"pure euphoria" programs fine although almost four times more slowly on my intel
Mac mini.
9. Re: Open Source, then...?
1. nightly build? for example, I use mingw, but the pacth is not in the current
official release.
2. a portable build? that is ec/ex find and set a default eulib/path/euinc
e.g,
when we launch c:\eu\bin\ec.exe, path will be c:\eu\bin;%path%,
euinc=c:\eu\include;%euinc%, and eudir=c:\eu;%eudir%
