1. Help Wanted (EUPHORIA source)
Attention: Developers of the Interpreter Source
I have heard the plea for help by Jeremy for developers to help with EUPHORIA's
source. I would like to point out that even if you are not brave enough to
modify the interpreter's source you can help by downloading the source and
trying
it out. If most of us on this list downloaded the source tried it against their
own source we might be tripping over bugs now instead of finding out after 4.0
comes out.
Putting new features in the language definition is one thing, but using those
new features in the source itself is another. The language that the interpreter
is written in should be C and EUPHORIA 3.1 for now.
Suppose, someone wants to try out Euphoria's 4.0 features or to actually
run some tests. Suppose I want to tryout a new linux kernel. I download it
and compile it and select the options I need. It compiles. I don't have to
modify the source. I don't even have to know C. Now, the linux kernel,
which runs a dozen platforms and it much more impressive than EUPHORIA, with all
due respect to Robert Craig, has that as a build process. Now, EUPHORIA,
you download and you cannot never compile it right out of the box as with Linux
and EUPHORIA only really runs on three OSes. WINDOWS and DOS being one platform
and each version interfaces with that oS in a different way, the other two being
Linux and BSD. It only works on x86 hardware. Yet, even with this tighter
platform restriction you need to manually modify the source before building.
So, by putting up this barrier Jeremy and friends have (I suppose inadvertently)
restricted those who will bother even trying it out.
Shawn Pringle B.Sc.
2. Re: Help Wanted (EUPHORIA source)
Shawn Pringle wrote:
>
> Attention: Developers of the Interpreter Source
>
> I have heard the plea for help by Jeremy for developers to help with
> EUPHORIA's
> source. I would like to point out that even if you are not brave enough to
>
> modify the interpreter's source you can help by downloading the source and
> trying
> it out. If most of us on this list downloaded the source tried it against
> their
> own source we might be tripping over bugs now instead of finding out after 4.0
> comes out.
>
> Putting new features in the language definition is one thing, but using those
> new features in the source itself is another. The language that the
> interpreter
> is written in should be C and EUPHORIA 3.1 for now.
>
>
> Suppose, someone wants to try out Euphoria's 4.0 features or to actually
> run some tests. Suppose I want to tryout a new linux kernel. I download it
> and compile it and select the options I need. It compiles. I don't have to
> modify the source. I don't even have to know C. Now, the linux kernel,
> which runs a dozen platforms and it much more impressive than EUPHORIA, with
> all
> due respect to Robert Craig, has that as a build process. Now, EUPHORIA,
> you download and you cannot never compile it right out of the box as with
> Linux
> and EUPHORIA only really runs on three OSes. WINDOWS and DOS being one
> platform
> and each version interfaces with that oS in a different way, the other two
> being
> Linux and BSD. It only works on x86 hardware. Yet, even with this tighter
> platform restriction you need to manually modify the source before building.
>
> So, by putting up this barrier Jeremy and friends have (I suppose
> inadvertently)
> restricted those who will bother even trying it out.
Yeah, some 4.0-isms have crept into the standard library (though not in
things actually used by the front end). Part of the reason is that different
people are working on different things. The stdlib *should* use 4.0 features.
But it can create a chicken and egg problem.
There is a capability to build a source distribution that would include the
translated C files, to remove the dependency upon having a working 4.0
interpreter. A couple of these have even been put up on sourceforge.
When the real releases are done (alpha, beta, release candidate, official),
you *will* be able to download and compile right out of the box. On *nix,
at least, you'll also be able to install (i.e., sudo make install).
I'm not sure what you mean by "you need to manually modify the source before
building." This has never been the case (except for BSD, which isn't true
any more either). The build process follows the standard configure and make
paradigm.
Matt
3. Re: Help Wanted (EUPHORIA source)
Shawn Pringle wrote:
>
> Suppose, someone wants to try out Euphoria's 4.0 features or to actually
> run some tests. Suppose I want to tryout a new linux kernel. I download it
> and compile it and select the options I need. It compiles. I don't have to
> modify the source. I don't even have to know C.
You are comparing a stable (post beta) release of the linux kernel to a
pre-alpha checkout of Euphoria? (Yes, not even a release yet, just a checkout.)
How often have you tried to check out the kernel source from git and made the
bleeding edge version compile???
Also, it seems quite crazy that we have to wait until 4.1 to be able to use 4.0
features in the stdlib. Matt Lewis has already solved the chicken and egg problem
- even for the alpha release, the code will come pretranslated for you. So no
bootstrap and no euphoria requred. Just a good C compiler.
> Now, EUPHORIA,
> you download and you cannot never compile it right out of the box as with
> Linux
> and EUPHORIA only really runs on three OSes. WINDOWS and DOS being one
> platform
> and each version interfaces with that oS in a different way, the other two
> being
> Linux and BSD. It only works on x86 hardware. Yet, even with this tighter
> platform restriction you need to manually modify the source before building.
>
Yes, it is rather unfortunate that no one provided precompiles executables like
http://jeremy.cowgar.com/files/eu40bins-578.zip to allow you to build yourself.
> So, by putting up this barrier Jeremy and friends have (I suppose
> inadvertently)
> restricted those who will bother even trying it out.
Currently, a few simple changes, it is not so bad, considering that the target
is (for right now) those who already undersgtand euphoria. It is very annoying,
however.
>
> Shawn Pringle B.Sc.
4. Re: Help Wanted (EUPHORIA source)
Matt Lewis wrote:
> I'm not sure what you mean by "you need to manually modify the source before
>
> building." This has never been the case (except for BSD, which isn't true
> any more either). The build process follows the standard configure and make
>
> paradigm.
>
> Matt
He probably meant the need to modify two include files which use entry in order
to make the interpreter build with a 3.1 version of euphoria.
5. Re: Help Wanted (EUPHORIA source)
Shawn Pringle wrote:
> Now, EUPHORIA, you download and you cannot never compile it right
> out of the box ...
Wasn't this explained to you Shawn, that the build scripts/makefile needs
correcting so that you can do exactly that.
I'm no expert in this but it seems to me that there is no reason why the 3.1.1
translator cannot deal with building the front-end code in theory. I think that
the problem at the moment is that it also tries to pull in standard library files
from the v4.0 area instead of the v3.1.1 area. To get around this behaviour there
is some manual messing around, but I believe that Matt Lewis is looking into the
build script issue. Plus this only applies to the initial build of 4.0 by 3.1.1
translator. Once you have a 4.0 executable, subsequent builds are not an issue.
Of course, the back-end is already written in C so that doesn't matter.
There is presently a limited number of C compilers supported but the two main
ones that are easily accessible are GCC for Linux and OpenWatcom for Windows.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
6. Re: Help Wanted (EUPHORIA source)
Shawn Pringle wrote:
>
> Attention: Developers of the Interpreter Source
>
> I have heard the plea for help by Jeremy for developers to help with
> EUPHORIA's
> source. I would like to point out that even if you are not brave enough to
>
> modify the interpreter's source you can help by downloading the source and
> trying
> it out. If most of us on this list downloaded the source tried it against
> their
> own source we might be tripping over bugs now instead of finding out after 4.0
> comes out.
>
Thank you.
> Putting new features in the language definition is one thing, but using those
> new features in the source itself is another. The language that the
> interpreter
> is written in should be C and EUPHORIA 3.1 for now.
>
This is not the case. Standard Library really *needs* to make use of 4.0
features. For instance, one new 4.0 feature is optional parameters. If we decided
not to use any new 4.0 features in the standard library, we would be forced to
release things like:
round(object nums)
round_to(object nums, integer precision)
match_all(object needle, object haystack)
match_all_from(object needle, object haystack, integer from)
There are *tons* of these such functions in standard library, now everything is
much simpler, lower function count to learn, etc...
round(object nums, integer precision=1)
match_all(object needle, object haystack, integer from=1)
>
> So, by putting up this barrier Jeremy and friends have (I suppose
> inadvertently)
> restricted those who will bother even trying it out.
>
They were added very much on purpose for reasons stated above and also for
simplicity of coding. The new features we have added to 4.0 makes it easier to
code and easier to maintain.
Official binaries will start to be produced with our first alpha. If anyone
wishes to help with the development of Euphoria you do not have to fear the
compilation process. It's pretty easy and I have helped many to compile w/o issue
over IRC. I have also provided binaries for both Windows and Linux to jump start
anyone as well. Those binaries are intended for developers as they are just
binaries, they do not include the SVN source tree, includes, etc...
--
Jeremy Cowgar
http://jeremy.cowgar.com
7. Re: Help Wanted (EUPHORIA source)
Matt Lewis wrote:
<snip>
>
> When the real releases are done (alpha, beta, release candidate, official),
>
> you *will* be able to download and compile right out of the box. On *nix,
> at least, you'll also be able to install (i.e., sudo make install).
>
> I'm not sure what you mean by "you need to manually modify the source before
>
> building." This has never been the case (except for BSD, which isn't true
> any more either). The build process follows the standard configure and make
>
> paradigm.
>
> Matt
If not already done, could you please consider in .configure/make/make install
chain the possibility to choose an alternative install dir, such as /home/foo
etc. ?
Unless you have a proper Debian package, to be installed with apt-get install,
someone could prefer a local non-root installation to a system-wide one,
especially on a pc. .... TIA. (Of course this is valid for other distros, as
well.)
Cheers.
MBianchi
8. Re: Help Wanted (EUPHORIA source)
MBianchi wrote:
>
> If not already done, could you please consider in .configure/make/make install
> chain the possibility to choose an alternative install dir, such as /home/foo
> etc. ?
>
> Unless you have a proper Debian package, to be installed with apt-get install,
> someone could prefer a local non-root installation to a system-wide one,
> especially
> on a pc. .... TIA. (Of course this is valid for other distros, as well.)
Yes, that's a good point. I think that we'll be turning to configuration
and build issues such as this pretty soon
Matt
9. Re: Help Wanted (EUPHORIA source)
Shawn Pringle wrote:
>
> Attention: Developers of the Interpreter Source
>
> I have heard the plea for help by Jeremy for developers to help with
> EUPHORIA's
> source. I would like to point out that even if you are not brave enough to
>
> modify the interpreter's source you can help by downloading the source and
> trying
> it out. If most of us on this list downloaded the source tried it against
> their
> own source we might be tripping over bugs now instead of finding out after 4.0
> comes out.
>
> Putting new features in the language definition is one thing, but using those
> new features in the source itself is another. The language that the
> interpreter
> is written in should be C and EUPHORIA 3.1 for now.
>
>
> Suppose, someone wants to try out Euphoria's 4.0 features or to actually
> run some tests. Suppose I want to tryout a new linux kernel. I download it
> and compile it and select the options I need. It compiles. I don't have to
> modify the source. I don't even have to know C. Now, the linux kernel,
> which runs a dozen platforms and it much more impressive than EUPHORIA, with
> all
> due respect to Robert Craig, has that as a build process. Now, EUPHORIA,
> you download and you cannot never compile it right out of the box as with
> Linux
> and EUPHORIA only really runs on three OSes. WINDOWS and DOS being one
> platform
> and each version interfaces with that oS in a different way, the other two
> being
> Linux and BSD. It only works on x86 hardware. Yet, even with this tighter
> platform restriction you need to manually modify the source before building.
>
> So, by putting up this barrier Jeremy and friends have (I suppose
> inadvertently)
> restricted those who will bother even trying it out.
>
> Shawn Pringle B.Sc.
I actually started correcting some of this night before last. I just didn't get
any of it done last night...
Maybe someone else will take my idea for me:
Make a new dir called "include3" or some such. Copy the modified files there.
Yes, they may have to be kept updated if they change in the main include file.
Change the configure.bat script to point EUINC to include3.
Like I said, though, I haven't tested this out yet.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: Help Wanted (EUPHORIA source)
Derek Parnell wrote:
> There is presently a limited number of C compilers supported but the two main
> ones that are easily accessible are GCC for Linux and OpenWatcom for Windows.
May I strongly suggest that MinGW be included in the list of compilers for
Windows. We found that using MinGW with Ruby, has definate speed increasements,
even over Microsoft Visual Studio.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
11. Re: Help Wanted (EUPHORIA source)
- Posted by Matt Lewis <matthewwalkerlewis at gmai?.com>
Jun 06, 2008
-
Last edited Jun 07, 2008
Mario Steele wrote:
>
> Derek Parnell wrote:
>
> > There is presently a limited number of C compilers supported but the two
> > main
> > ones that are easily accessible are GCC for Linux and OpenWatcom for
> > Windows.
>
> May I strongly suggest that MinGW be included in the list of compilers for
> Windows.
> We found that using MinGW with Ruby, has definate speed increasements, even
> over Microsoft Visual Studio.
Sure. Come on over and get started on it!
Matt
12. Re: Help Wanted (EUPHORIA source)
- Posted by Jeremy Cowgar <jeremy at cowga??com>
Jun 06, 2008
-
Last edited Jun 07, 2008
Mario Steele wrote:
>
> May I strongly suggest that MinGW be included in the list of compilers for
> Windows.
> We found that using MinGW with Ruby, has definate speed increasements, even
> over Microsoft Visual Studio.
Wow! I've only three main apps on Windows in C and in all cases MinGW was
significantly slower, I am speaking of 20-30% slower (than MSVC). I have not
benchmarked them against Watcom as I have only used it in relation to Euphoria.
--
Jeremy Cowgar
http://jeremy.cowgar.com
13. Re: Help Wanted (EUPHORIA source)
Jeremy Cowgar wrote:
>
> Mario Steele wrote:
> >
> > May I strongly suggest that MinGW be included in the list of compilers for
> > Windows.
> > We found that using MinGW with Ruby, has definate speed increasements, even
> > over Microsoft Visual Studio.
>
> Wow! I've only three main apps on Windows in C and in all cases MinGW was
> significantly
> slower, I am speaking of 20-30% slower (than MSVC). I have not benchmarked
> them
> against Watcom as I have only used it in relation to Euphoria.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Regardless of speed, one of the main reasons of using MingW would be to leverage
the commonality it shares with other gcc compilers.
But I ain't doin' it, so good luck to whoever does!
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
14. Re: Help Wanted (EUPHORIA source)
Jason Gade wrote:
>
> Regardless of speed, one of the main reasons of using MingW would be to
> leverage
> the commonality it shares with other gcc compilers.
>
> But I ain't doin' it, so good luck to whoever does!
>
To me speed would be the only reason to do it. We already have watcom supported
adding yet another one to the mix is not going to simplify anything. Supporting
it would probably be pretty easy as it is GCC and we already have GCC figured
out, but watcom is free, much easier to download and install.
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: Help Wanted (EUPHORIA source)
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> >
> > Regardless of speed, one of the main reasons of using MingW would be to
> > leverage
> > the commonality it shares with other gcc compilers.
> >
> > But I ain't doin' it, so good luck to whoever does!
> >
>
> To me speed would be the only reason to do it. We already have watcom
> supported
> adding yet another one to the mix is not going to simplify anything.
> Supporting
> it would probably be pretty easy as it is GCC and we already have GCC figured
> out, but watcom is free, much easier to download and install.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Well, for ease of installation I'd go with dmc. But I haven't finished that yet
-- need to get back to it.
No idea about speed though.
MingW is still pretty easy to install, though.
Note: other than stuff read on the internet I have no idea about the relative
performance of the different compilers. Remember, I'm a hardware guy more than a
software guy.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
16. Re: Help Wanted (EUPHORIA source)
I just thought I would clarify what I said earlier about building EUPHORIA 4.0.
Speaking about the standard library. I didn't actually say that the new
features
of EUPHORIA 4.0 should stay out of it. I simply expected that the source of
interpreter itself and its dependencies would not use the new syntax. If the
interpreter source uses this standard library, you have a circular dependency:
To get the Euphoria 4.0 binary, you need the C source, to get the C source you
need ec to change the Euphoria 4.0 source into C, but the only ec that will do
it requires the Euphoria 4.0 binary.
I tried to use the Euphoria 3.1 includes in the beginning. It turns out that
int.ex depends on sequence.e which doesn't exist in Euphoria 3.1's standard
library.
The solution of supplying the C source in the distribution would solve this
problem. When it hits 4.0 though, one should be able to go from Euphoria
source to Euphoria binary.
Shawn Pringle
17. Re: Help Wanted (EUPHORIA source)
Jim Brown wrote:
>
> Matt Lewis wrote:
> > I'm not sure what you mean by "you need to manually modify the source before
> >
> > building." This has never been the case (except for BSD, which isn't true
> > any more either). The build process follows the standard configure and make
> >
> > paradigm.
> >
> > Matt
>
> He probably meant the need to modify two include files which use entry in
> order
> to make the interpreter build with a 3.1 version of euphoria.
Working with this right now, it's more than two files -- and I'm working with a
slightly dated version.
search.e, sequence.e, file.e, hmm.
Actually, I think it's gotten to where you can't build 4.0 with 3.1. Some of the
ifdef changes in file.e I would have to rewrite those bits the old way.
Guess I'll have to find a precompiled interpreter to compile the interpreter.
Chicken and egg.
Maybe information on how to get one should be included in the build instructions
on the wiki?
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
