1. Compiler status
- Posted by Robert Craig <rds at ATTCANADA.NET>
Jul 04, 2000
-
Last edited Jul 05, 2000
The Euphoria compiler project is moving along well.
I'm successfully compiling all DOS32 programs in
euphor22.zip, plus many large user programs
such as the ee editor (over 10,000 lines of Euphoria).
I even compiled the Cuny/Gayle Euphoria interpreter,
making it run the sieve benchmark 2.1x faster.
Sieve, compiled by the new compiler, runs 2.6x faster
than with ex. Shell sort runs 3.2x faster. That's with
minimal optimization. There's a lot more that I can do to
improve the generated C code.
I've decided that if I'm going to sell this thing,
I really should have a free version that people
can play with before (hopefully) buying. I don't want
people to buy the compiler and then send me an
endless stream of tech support requests along the lines
of "how do I install GNU C?" or "it didn't speed up my
application very much".
I'm still a bit fuzzy on the details, but I'm thinking the
free compiler will compile anything, but you'll get
a nag message before your .exe starts running.
The price to buy the compiler will be fairly cheap,
I haven't decided yet.
This will open up the "secrets of implementing Euphoria in C"
to many more people, but I'm not too worried about that anymore.
You'd need a lot of time and effort to seriously
compete with RDS in the Euphoria market. 
After some more optimizing, I'll start testing on WIN32 and Linux,
and hopefully release a trial version for Linux / GNU C,
and WIN32/WATCOM and DOS32/WATCOM (for the few
who have WATCOM) in a month or two. Other C compilers will
be supported after that.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
2. Re: Compiler status
- Posted by Hawke' <mikedeland at NETZERO.NET>
Jul 04, 2000
-
Last edited Jul 05, 2000
From: Robert Craig <rds at ATTCANADA.NET>
> The Euphoria compiler project is moving along well.
> I'm successfully compiling all DOS32 programs in
> euphor22.zip, plus many large user programs
> such as the ee editor (over 10,000 lines of Euphoria).
good job :)
> I even compiled the Cuny/Gayle Euphoria interpreter,
> making it run the sieve benchmark 2.1x faster.
> Sieve, compiled by the new compiler, runs 2.6x faster
> than with ex. Shell sort runs 3.2x faster.
outstanding :)
i'm a little puzzled tho...
is this creation of yours turning EU code -into- C code, which
then needs to be compiled using a C compiler...
or...
is it actually compiling EU code into a stand alone executable
similar to bind, but without the overhead of the interpreter tagged
onto the .exe???
or is it doing both :) parsing the EU code, generating temporary
C code (held in ram or disk as a temp file, invisible to the user) and
then in turn calling a C compiler to act upon that intermediate stage
C code?
how will this affect things like run time error checking, and wont it
significantly affect the (perhaps largest blessing of EU) edit/run cycle
of program development?
will we now have an edit/convert/compile/link/run cycle???
will unintialized variables still be detected?
will gracefull program crashes be a thing of the past, replaced with
those dreaded, mysterious, inexplicable crashes without any sort
of data dump?
in short, we will now be facing many of the reasons not to
use C listed in C.DOC????
don't get me wrong here...i see a rather large need for being able
to port towards C compatibility...would make other OS porting
tasks much easier...and it would make porting programs written
in C already much easier to port into native EU code as well...
and I know i cannot have my cake and eat it too...
once again, kudos rob :)
--Hawke'
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
3. Re: Compiler status
On Tue, 4 Jul 2000 22:16:57 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:
>The Euphoria compiler project is moving along well.
>I'm successfully compiling all DOS32 programs in
>euphor22.zip, plus many large user programs
>I've decided that if I'm going to sell this thing,
>I really should have a free version that people
>can play with before (hopefully) buying. I don't want
>people to buy the compiler and then send me an
>endless stream of tech support requests along the lines
>of "how do I install GNU C?" or "it didn't speed up my
>application very much".
>
>
>After some more optimizing, I'll start testing on WIN32 and Linux,
>and hopefully release a trial version for Linux / GNU C,
>and WIN32/WATCOM and DOS32/WATCOM (for the few
>who have WATCOM) in a month or two. Other C compilers will
>be supported after that.
>
Rob Why don't you just release a beta version of DOS32 compiler before
jumping into the other versions so we can see how it works. It will
probably make the writing of the other versions easier for you. You may
find that we can use the DOS32 version to do WIN32 programming.
Thanks
Bernie
4. Re: Compiler status
Hawke' writes:
> i'm a little puzzled tho...
> is this creation of yours turning EU code -into- C code, which
> then needs to be compiled using a C compiler...
Right. It translates your Euphoria program into a set
of C source files that you compile and link using
a C compiler/linker (not supplied by RDS).
It also makes a .bat file that will compile and link
everything for you.
For Language War you would type:
ec lw
One second later ec reports:
20 .c files created, type make to build your .exe
You type:
make
Your .c's are compiled and linked with
eruntime.lib (standard Euphoria run-time routines),
and you end up with lw.exe, which runs indentically to
ex lw.ex (but faster). Assuming similar compression,
compiled .exe's start off about 70K smaller than bound
.exe files, but the size grows more quickly than bound files.
> how will this affect things like run time error checking,
> and wont it significantly affect the (perhaps largest blessing
> of EU) edit/run cycle of program development?
The compiled code performs very little run-time error checking.
You should develop programs using the interpreter. When they
are running correctly, you can compile for greater speed.
If they crash, you can debug using the interpreter again.
> will unintialized variables still be detected?
No.
> will gracefull program crashes be a thing of the past,
> replaced with those dreaded, mysterious, inexplicable
> crashes without any sort of data dump?
You can get dreaded, mysterious crashes when your compiled
program has a bug. Simply run the same test again using
the interpreter, and you should get an error report.
The registered version of the compiler has
a trace facility that will let you see the last 100 or so
Euphoria statements performed just prior to any crash.
You specify "with trace" and trace(1).
It will also comment your .c files, showing each
Euphoria statement, followed by the C statements that
implement that Euphoria statement. This level of debugging
is more useful for myself in debugging the compiler.
People will normally debug using the interpeter.
> I know i cannot have my cake and eat it too...
Yes you can!
Both the compiler and the interpreter will be
maintained. They share a lot of code, and
the interpreter is essential for debugging,
and for people who don't have a C compiler,
which is most people.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Compiler status
Bernie Ryan writes:
> Rob Why don't you just release a beta version of DOS32
> compiler before jumping into the other versions so we
> can see how it works.
I'd rather keep moving ahead on my own.
I don't want to slow down and prepare a
very short-lived release.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Compiler status
> After some more optimizing, I'll start testing on
> WIN32 and Linux,
> and hopefully release a trial version for Linux /
> GNU C,
> and WIN32/WATCOM and DOS32/WATCOM (for the few
> who have WATCOM) in a month or two. Other C
> compilers will
> be supported after that.
Why don't you just generate GNU C for all 3 platforms?
Just tell people to install DJGPP and RSXNTDJ and DOS
& Win32 are good to go.
=====
It compiled. The first screen came up. Ship it.
--Bill Gates
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
7. Re: Compiler status
On 6 Jul 2000, at 10:43, Mike Hurley wrote:
> > After some more optimizing, I'll start testing on
> > WIN32 and Linux,
> > and hopefully release a trial version for Linux /
> > GNU C,
> > and WIN32/WATCOM and DOS32/WATCOM (for the few
> > who have WATCOM) in a month or two. Other C
> > compilers will
> > be supported after that.
>
> Why don't you just generate GNU C for all 3 platforms?
> Just tell people to install DJGPP and RSXNTDJ and DOS
> & Win32 are good to go.
>
> =====
> It compiled. The first screen came up. Ship it.
> --Bill Gates
Unn, i think the sig line explained why not do that.
Kat
8. Re: Compiler status
I would like to know how many REGISTERED users on this list have a
WATCOM compiler ? If its more than 1/2 percent of the users I will be
very supprised. I have 4 "C" compilers and none of them are WATCOM.
9. Re: Compiler status
Bernie wrote:
>
> I would like to know how many REGISTERED users on this list have a
>
> WATCOM compiler ? If its more than 1/2 percent of the users I will be
>
> very supprised. I have 4 "C" compilers and none of them are WATCOM.
Hi Bernie,
I have WATCOM C/C++ and F77 and also CauseWay 1.3 .
I do appreciate very much the possibility to compile EU progs for DOS32.
Have a nice day, Rolf
10. Re: Compiler status
On Fri, 7 Jul 2000 08:39:47 +0200, Rolf Schroeder <rolf.schroeder at DESY.DE>
wrote:
>I have WATCOM C/C++ and F77 and also CauseWay 1.3 .
>I do appreciate very much the possibility to compile EU progs for DOS32.
>
>Have a nice day, Rolf
Hi Rolf:
Looks like you will be the only one that will be able to test and
use the Euphoria compiler, the rest of us will have to wait until
Rob gets around using a compiler that the rest of us can purchase,
since WATCOM is a unavailable compiler.
Bernie
11. Re: Compiler status
Bernie Ryan writes:
> Hi Rolf:
> Looks like you will be the only one that will be able to test and
> use the Euphoria compiler, the rest of us will have to wait until
> Rob gets around using a compiler that the rest of us can purchase,
> since WATCOM is a unavailable compiler.
Bernie, for someone who initially opposed the idea
of making a compiler, you sure sound heart-broken at
having to wait a while before using it.
In addition to Rolf and a few others I know who have WATCOM
for DOS and Windows, the initial release will be usable by
*every* person who has Linux, and they won't have to
purchase anything, since they all have GNU C installed
on their systems.
Not too long after that, I hope to support GNU C on DOS.
Again, no purchase necessary.
Other C compilers will follow. The Euphoria compiler
itself will require almost zero change in supporting a
new C compiler, but the Euphoria runtime library that
you link with will have to be rebuilt with a few #ifdef's.
The biggest issue for DOS32 with non-WATCOM compilers,
will be the lack of the WATCOM graphics library.
Alternatives such as Pete's "Neil" graphics library exist.
I've successfully compiled to C, and run,
Neil-based Euphoria programs.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
12. Re: Compiler status
On 7 Jul 2000, at 15:31, Robert Craig wrote:
> In addition to Rolf and a few others I know who have WATCOM
> for DOS and Windows, the initial release will be usable by
> *every* person who has Linux, and they won't have to
> purchase anything, since they all have GNU C installed
> on their systems.
>
> Not too long after that, I hope to support GNU C on DOS.
> Again, no purchase necessary.
>
> Other C compilers will follow.
Ummm,, does this mean many different "translator-compiler" packages, one for
each
possible C compiler, or will Eu be smart enough to know/ask which compiler to
target?
Kat
13. Re: Compiler status
Kat writes:
> Ummm,, does this mean many different
> "translator-compiler" packages, one for each
> possible C compiler, or will Eu be smart enough to
> know/ask which compiler to target?
On Linux there will be one Euphoria compiler and one
runtime library file (eruntime.lib). No problem there.
On DOS and Windows, there will be more than
one C compiler supported. There will be
a single Euphoria to C compiler, that runs on (32-bit) DOS,
that is capable of generating C code for any of the
supported DOS or Windows C compilers, as well as
generating a .bat file for doing the C compiles and the
link with eruntime.lib. It would somehow "know" which
C compiler you were using, maybe with an environment
variable.
However, there will have to be a different version
of eruntime.lib for each supported C compiler.
You would download a Euphoria to C compiler to run on
either Linux, or DOS/Windows. Then you'd download
the version of eruntime.lib that's needed by your
specific brand of C compiler. You'd place the compiler
and eruntime.lib in euphoria\bin.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
14. Re: Compiler status
On 2000-07-07 EUPHORIA at LISTSERV.MUOHIO.EDU said:
EU>On Fri, 7 Jul 2000 08:39:47 +0200, Rolf Schroeder <rolf.
EU>schroeder at DESY.DE> wrote:
EU>>I have WATCOM C/C++ and F77 and also CauseWay 1.3 .
EU>>I do appreciate very much the possibility to compile EU progs for
EU>DOS32. >
EU>>Have a nice day, Rolf
EU>Hi Rolf:
EU>Looks like you will be the only one that will be able to test and
EU>use the Euphoria compiler, the rest of us will have to wait until
EU>Rob gets around using a compiler that the rest of us can purchase,
EU>since WATCOM is a unavailable compiler.
EU>Bernie
Why is this the instance ; when a website was given , previously ;
http://www.ballyhoo.eu.org/~euler/c/watcom11.zip
where the compiler might be [ freely ? ] downloaded.
Net-Tamer V 1.11 - Test Drive
15. Re: Compiler status
> eruntime.lib
I don't know if this is getting picky or not, but on
Linux and other platforms that may in the future go to
GNU C, won't the library file have to be something
like "liberuntime.a?" Since some people do DOS
programming in a pure DOS mode of one kind or another,
shouldn't it be named "libeurun.a?"
Just thought of this as I read Rob's last post on this
thread,
Mike Hurley
=====
It compiled. The first screen came up. Ship it.
--Bill Gates
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/
16. Re: Compiler status
> Other C compilers will follow. The Euphoria compiler
> itself will require almost zero change in supporting a
> new C compiler, but the Euphoria runtime library that
> you link with will have to be rebuilt with a few #ifdef's.
> The biggest issue for DOS32 with non-WATCOM compilers,
> will be the lack of the WATCOM graphics library.
> Alternatives such as Pete's "Neil" graphics library exist.
> I've successfully compiled to C, and run,
> Neil-based Euphoria programs.
Solutions ?
=======
Have a fourth constant returned by platform (). This way graphics.e can be
made to use Neil when compiling.
Or just kick the annoying Watcom graphics library out of the executable
anyway, which would almost save half the size of the ex.exe, is it not ?
With some minor modifications it would be backwards compatible. Thinking
about it, I would say only graphics_mode () and some palette routines need
to be added for backwards compatiblity. Then it would run *faster*
(esspecially compiled without all the error checking etc.), all graphics
function would be available on Linux, Win32 and Dos32. There would be
support for virtual screens, rle-sprites, etc.
Think about it. Talk to Pete. Find a way to incorporate Neil.e (renamed to
graphics.e ? ) and Asm.e should have been part of the core include files
anyway. (ps. platform independent mouse routines are also supported.!)
Come on, you need these changes. It just plain *silly* if not completely
inconsistent that you do link the watcom graphics library, but not a
windows-gui support library. Of all graphics libraries you choose to use to
clutter up the interpreter you choose watcom. Don't. Neil shrouded, is
faster, more usable, platform independent, so much smaller and it will even
be faster when compiling.
Robert, really, are you considering anything like this ?
Also, what will happen with bind when the eu-compiler is available ?
Maybe a silly suggestion, but since we have asm.e why not write a c to asm
compiler in Euphoria ?
This would mean, a small zip file, a compiler to any stage. (to c, to asm,
to exe).
The last thing I want to mention, when will top-level only mean
*out-of-routines* rather than *out-of-any-usuable-construct* .. i.e.
if this () then
include that.
end if
if that () then
constant err = 4
end if
Etc. What other reason could you possible have to support such constructs at
the top-level when we can only use them as if they are inside of a routine.
If you want to force this restriction, why didn't you go for a Main ()
routine ? Esspecially with the increasing platform independiblity we need
conditional ifs.
Greetings,
Ralf N.
nieuwen at xs4all.nl
17. Re: Compiler status
Ralf wrote:
> Or just kick the annoying Watcom graphics library out of the
> executable ...
What's so annoying about it? It's pretty basic, it reflects its age,
but it is quite fast and reliable, what else do you want?
As usual, Ralf rambled on:
> ... Find a way to incorporate Neil.e (renamed to graphics.e ? ) ...
Don't. When Neil works, it works well. When it doesn't, it doesn't.
For instance, it never worked with any NT machine I tried it on.
What's more, last time I looked, it lacked essential primitives like
line, ellipse, polygon, etc. No doubt it can be made more complete,
but as it stands now, it's a desirable extension, but definitely not a
suitable replacement.
jiri
18. Re: Compiler status
>Ralf wrote:
>> Or just kick the annoying Watcom graphics library out of the
>> executable ...
>What's so annoying about it? It's pretty basic, it reflects its age,
>but it is quite fast and reliable, what else do you want?
The fact is nobody uses it. Not even you, for any fast graphical demo.
But it is half the size of the dos-interpreter.
Come on. I had more troubles with the watcom thingie than I ever had with
Neil. Neil simply worked for me and I was assuming it did everywhere, until
I unfortunately heard it didn't work for you on the NT.
Well, the point remains though, I am still for removing the library and
having graphics.e use asm.e etc and provide the graphical functions itself.
And it *is* inconsistent, to have all this basic interface support for Dos
and Dos alone. What is it ? Is Euphoria a minimal language or does it have
bells and whistles or is it just minimal on Win32 and Linux and lots of
bell's and whistles on Dos32 .. What's the policy ? What are the criteria
to add a certain library to the executable ? Does it really need to be done
in C and packed with every Euphoria program ?
>As usual, Ralf rambled on:
As usual, Jiri was unreasonably annoyed by the idea alone 
>> ... Find a way to incorporate Neil.e (renamed to graphics.e ? ) ...
>Don't. When Neil works, it works well. When it doesn't, it doesn't.
>For instance, it never worked with any NT machine I tried it on.
>What's more, last time I looked, it lacked essential primitives like
>line, ellipse, polygon, etc. No doubt it can be made more complete,
>but as it stands now, it's a desirable extension, but definitely not a
>suitable replacement.
Ok, I didn't know. I agree. Reliability is a must if you want it to replace
the graphics library.
Neil isn't the way (yet?) .. but I'm still for kicking the watcom lib out..
or kicking many more libs in.
I mean, it would make much more sence to add a platform independent GUI lib
.. than to add a graphical lib that only works on Dos32. The Dos32 platform
still remains the home of Euphoria, no matter how you put it. Euphoria
doesn't even include win32lib in the download. Dos32 is the only platform
for which a new user, who has got Euphoria from some shareware cdrom
etc.will experience. He won't have the patience to try to set up and
download the win32 thingie. If he doesn't like Dos32 .. he won't even notice
the fact that it should also run under windows. The year is 2000, may I
remind you, no body uses Dos anymore, other than Euphoria game and graphics
programmers. The number of people who use the Pc has increased enormously,
but most of those people have trouble enough using Windows, they can't do
Dos!
So, what is it going to be ? Euphoria as a minumal language .. with
libraries for graphics and interface, and mouse, etc. in source code form,
or is it going to have some basic bells'and'whistles on *all* platforms ?
I'm in for kicking out the watcom libs, and for adding some cross-platform
graphical interface library. I dunno which, I suggest some one asks David ..
he seen 'em all.
Commercially, I suspect the addition of such a library *is* the answer as
well. It increases the producticity of using Euphoria enormously. I mean,
the need to add such thing, is much higher, than to add some silly new
feature that will make our algorithms just a tad little more elegant.
Algorithms alone don't make programs.
Robert, I'm quite sure, you have considered, or are considering such areas,
what are your plans ? what is going to be the policy ? where is euphoria
heading ? the compiler is really cool and all, but was speed really the
issue, well i *am* wondering what the speed increase will be for the win32
programs .... it is there where a better average of statements per sec, will
have a great impact. (and also where it is needed most)
Do you intend to move Euphoria futher into the Win32 platform ? Say,
installation, editor, inclusing of win32lib .. what, what is it, you're
gonna do ?
Ralf N.
nieuwen at xs4all.nl
19. Re: Compiler status
On Tue, 11 Jul 2000, Fam. Nieuwenhuijsen wrote:
> >Ralf wrote:
>
> >> Or just kick the annoying Watcom graphics library out of the
> >> executable ...
>
I agree. Graphics, being platform specific, don't belong in the core
language at all. They're no use to me when I write programs for
Windows, and equally useless when I write Linux programs. I can't
even "un-include" the names from the namespace. If it would make
Euphoria executables smaller, I'm in favor of separating the DOS-only
graphics, so we can include them if we want, or choose a similar
svga-lib for Linux, or just use Windows or X-win graphics.
Unfortunately, Neil hasn't worked on _any_ of the 3 computers I've
tried it on, so that's not an alternative.
Irv
20. Re: Compiler status
Ralf N. writes:
> But it is half the size of the dos-interpreter.
The DOS32 executable (ex.exe) is quite a bit
larger than the Linux or Windows executables (exu, exw).
I've indicated that this is due to the WATCOM graphics
library. That's not the whole story. A large part of the
extra size is due to the CauseWay DOS extender,
and some is simply due to less effective .exe compression.
It's hard to add up the numbers from the link
map, but the graphics library is not having as large
an effect as you might be imagining.
> I'm in for kicking out the watcom libs, and for adding
> some cross-platform graphical interface library.
I wish I had a cross-platform, separately-includable
graphics library, with source code, that was fast,
and compatible across (at least) Linux, Windows and DOS,
and supported all the different graphics cards out there.
Without a suitable replacement, I can't simply
scrap the WATCOM library in the name of cross-platform
consistency. It would break far too many programs.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
21. Re: Compiler status
Honestly, the file size was not a real worry. Its still just a fragment of
any other windows program (which is the standard).
>> I'm in for kicking out the watcom libs, and for adding
>> some cross-platform graphical interface library.
>I wish I had a cross-platform, separately-includable
>graphics library, with source code, that was fast,
>and compatible across (at least) Linux, Windows and DOS,
>and supported all the different graphics cards out there.
Well, I was under the impression some of such libraries exist, even though
most are just names I heard.
GTK, etc. David, what are the options ?
Off course, there are legal strings attached as well, I suppose ?
>Without a suitable replacement, I can't simply
>scrap the WATCOM library in the name of cross-platform
>consistency. It would break far too many programs.
Off course you can't, but does this means, that you have changed the policy
when adding thew Win32 and Linux platforms ? Where do you stand ? Will you
ever add libraries comparable to the Watcom graphics lib to the Win32
version and the Linux version ? How will the development go ?
I do still suggest you add things like Win32Lib to the standard download,
perhaps also a simple editor for Win32, an Win32 installation program ?
Ralf N.
nieuwen at xs4all.nl
22. Re: Compiler status
Ralf wrote:
> The fact is nobody uses [the DOS graphics library].
I guess that makes me a nobody.
> I mean, it would make much more sense to add a
> platform independent GUI lib than to add a
> graphical lib that only works on Dos32.
True, but no one is 'adding' a library. It's been part of Euphoria for quite
some time.
You're talking apples and oranges here. There's a world of difference
between a fullscreen/framebuffer type of graphic system (like DOS has), and
a windowed graphic system (like the X Window System). If you just want a
cross-platform replacement for the fullescreen DOS graphics library, I'd
suggest SciTech's MGL library (http://www.scitechsoft.com/download.html),
which runs under Windows, Linux, DOS, OS/2 and QNX.
Even if Robert added a cross-platform GUI, it seems to me that he would
still want to keep the DOS graphic library intact.
> The year is 2000, may I remind you, nobody
> uses Dos anymore
By the same criteria, 'nobody' codes in Euphoria, either. I do quite a bit
of DOS coding.
> I dunno which, I suggest some one asks
> David .. he seen 'em all.
You can find a good list of options at
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, and decide
if you agree with me or not.
On the commercial side, Qt (http://www.trolltech.com/) and Zinc
(http://www.zinc.com/products/zaf/zaf.htm) are probably the best options.
Both are C++ based, and Qt uses a pre-processor, so there would be some
challanges for Robert here, but they are surmountable. Both libraries seem
to have fairly small footprints, and Zinc even supports DOS and Macintosh.
But I doubt that Robert could afford either option - or that we'd be willing
to buy Euphoria to support the cost of the toolkit.
On the free side, V (http://www.objectcentral.com/vgui/vgui.htm) and
wxWindows (http://206.101.232.131/) are probably the best options. V is very
nice (and easier to learn), but wxWindows seems far more complete,
supporting many more platforms - even the Mac. Both libraries are in C++, so
there are no doubt serious issues to getting either working. On the other
hand, I know that Python bindings exist for wxWindows, so it should be quite
possible.
I'm quite fond of a number of other toolkits that don't offer complete
solutions, such as:
GTK+ (http://www.gtk.org)
Microwindows (http://microwindows.censoft.com/)
WINE (http://www.winehq.com)
OpenGL (http://www.opengl.org/)
OK, bottom line: if Robert were to graft a cross-platform library onto
Euphoria, I'd highly suggest using wxWindows:
- Free, even for commercial purposes
- Complete - cross-platform fonts, printing, etc.
- Well documented
- Well supported
- Runs on Win32, GTK+ and Macintosh
- Pending ports include BeOS and QNX
- wxPython shows can be used in scripting language
Personally, I'd love to see a port to wxWindows.
-- David Cuny
23. Re: Compiler status
- Posted by Rolf Schroeder <r.schr at T-ONLINE.DE>
Jul 11, 2000
-
Last edited Jul 12, 2000
Hi all non DOS programmers,
I would only like to state: still a lot of people like to use DOS
compatible programming, especially in eastern Europe, including Russia!
As pointed out, as long as you restrict the graphic on VGA or MCGA, the
DOS32 programs run ALSO from the Win32 cmd window. If you don't like the
DOS32 part, don't use it.
I have still some older PCs not useful for Win32, but very practical for
DOS32.
Have a nice day, Rolf
24. Re: Compiler status
- Posted by Ben Fosberg <BenFosberg at WORLDNET.ATT.NET>
Jul 11, 2000
-
Last edited Jul 12, 2000
Sounds to me like some people on this thread may be talking apples and
elephants. Would someone sort these issues out for me; I'm getting really
confused:
1) The "core language" is (PD)ex.exe for dos32 and (PD)exw.exe on Win32 (sorry,
Linux folk, I don't remember your lingo). Is it being claimed here that the
Win32 executable for the interpreter includes the dos graphics library? If not,
those of us writing for Win32 aren't being "burdened" with the library, are we?
If so, why?
2) Despite the fact that we all keep saying "compiler," I believe the gizmo Rob
described was a "translator." You put in Euphoria and you get out C source,
which you then feed into a C compiler. Unless Rob's gizmo and the (Watcom)
compiler are both aggressively "anti-optimizing," I don't understand how the
final binary will be any larger due to the translator's support for (dos
library) graphics routines that aren't being called (because they aren't
relevant) in a Windoz or Linux program.
While I'm yapping again, just for the polling stats:
I'm "programming" (almost) for DOS and Windoz on little slow machines and big
fast ones. DOS is far from dead outside the small world of "developers," and
Linux, et al., are a long way from common in the real world.
Small executables are always nice and speed is always nice - occasionally even
essential - regardless, but personally, I put big stock in not having to write a
whole lot of code that someone else has already provided, so I like the
libraries. But I think that adding more of them to the core executable is
counter-productive. There are many occasions, even in Windoz, when you don't
need Win32Lib, for instance, much as I like using it. And, thankfully, it keeps
growing. What seems to me to be more useful in the long run is a resolution of
the namespace conflicts, and perhaps even a "smart include" function in the
binder. In any event, I would certainly defer to others on the choice of
cross-platform graphics libraries.
Ben Fosberg
"Cuny, David@DSS" wrote:
> Ralf wrote:
>
> > The fact is nobody uses [the DOS graphics library].
>
> I guess that makes me a nobody.
>
> > I mean, it would make much more sense to add a
> > platform independent GUI lib than to add a
> > graphical lib that only works on Dos32.
>
> True, but no one is 'adding' a library. It's been part of Euphoria for quite
> some time.
>
> You're talking apples and oranges here. There's a world of difference
> between a fullscreen/framebuffer type of graphic system (like DOS has), and
> a windowed graphic system (like the X Window System). If you just want a
> cross-platform replacement for the fullescreen DOS graphics library, I'd
> suggest SciTech's MGL library (http://www.scitechsoft.com/download.html),
> which runs under Windows, Linux, DOS, OS/2 and QNX.
>
> Even if Robert added a cross-platform GUI, it seems to me that he would
> still want to keep the DOS graphic library intact.
>
> > The year is 2000, may I remind you, nobody
> > uses Dos anymore
>
> By the same criteria, 'nobody' codes in Euphoria, either. I do quite a bit
> of DOS coding.
>
> > I dunno which, I suggest some one asks
> > David .. he seen 'em all.
>
> You can find a good list of options at
> http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, and decide
> if you agree with me or not.
>
> On the commercial side, Qt (http://www.trolltech.com/) and Zinc
> (http://www.zinc.com/products/zaf/zaf.htm) are probably the best options.
> Both are C++ based, and Qt uses a pre-processor, so there would be some
> challanges for Robert here, but they are surmountable. Both libraries seem
> to have fairly small footprints, and Zinc even supports DOS and Macintosh.
> But I doubt that Robert could afford either option - or that we'd be willing
> to buy Euphoria to support the cost of the toolkit.
>
> On the free side, V (http://www.objectcentral.com/vgui/vgui.htm) and
> wxWindows (http://206.101.232.131/) are probably the best options. V is very
> nice (and easier to learn), but wxWindows seems far more complete,
> supporting many more platforms - even the Mac. Both libraries are in C++, so
> there are no doubt serious issues to getting either working. On the other
> hand, I know that Python bindings exist for wxWindows, so it should be quite
> possible.
>
> I'm quite fond of a number of other toolkits that don't offer complete
> solutions, such as:
>
> GTK+ (http://www.gtk.org)
> Microwindows (http://microwindows.censoft.com/)
> WINE (http://www.winehq.com)
> OpenGL (http://www.opengl.org/)
>
> OK, bottom line: if Robert were to graft a cross-platform library onto
> Euphoria, I'd highly suggest using wxWindows:
>
> - Free, even for commercial purposes
> - Complete - cross-platform fonts, printing, etc.
> - Well documented
> - Well supported
> - Runs on Win32, GTK+ and Macintosh
> - Pending ports include BeOS and QNX
> - wxPython shows can be used in scripting language
>
> Personally, I'd love to see a port to wxWindows.
>
> -- David Cuny
25. Re: Compiler status
- Posted by David Garcia <donovan at ABS.NET>
Jul 11, 2000
-
Last edited Jul 12, 2000
Ben Fosberg wrote:
> I'm "programming" (almost) for DOS and Windoz on little slow machines and big
> fast ones. DOS is far from dead outside the small world of "developers," and
> Linux, et al., are a long way from common in the real world.
DOS has it's uses, for example I have a (believe it or not) QBASIC program that
generates customized javascript for me... that just happened to be the tool at
hand.
btw, Linux is the OS for over half the machines that comprise the core of the
Internet, according to several recent studies. 
26. Re: Compiler status
>Robert Craig writes:
>I wish I had a cross-platform, separately-includable
>graphics library, with source code, that was fast,
>and compatible across (at least) Linux, Windows and DOS,
>and supported all the different graphics cards out there.
OpenGL *ahum* MesaGL *ahum* Allegro
Jason Leit,
Cheers! :)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
27. Re: Compiler status
>>Robert Craig writes:
>>
>>I wish I had a cross-platform, separately-includable
>>graphics library, with source code, that was fast,
>>and compatible across (at least) Linux, Windows and DOS,
>>and supported all the different graphics cards out there.
>>
>OpenGL *ahum* MesaGL *ahum* Allegro
>
>Jason Leit,
>Cheers! :)
...XLib, ClanLib.
It can be pretty hard to find something that'll work with all 3 OS:s though.
Gfx-libs typically work with DOS and Linux but not Windows, or Windows and
Linux but not DOS..
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
28. Re: Compiler status
- Posted by Robert Craig <rds at ATTCANADA.NET>
Jul 13, 2000
-
Last edited Jul 14, 2000
Ben Fosberg writes:
> Is it being claimed here that the Win32 executable for the
> interpreter includes the dos graphics library? If not,
> those of us writing for Win32 aren't being "burdened" with
> the library, are we?
Only the DOS32 interpreter contains the WATCOM
graphics library. That's why pixel-graphics
library routines such as polygon(), ellipse(), pixel() etc.
are currently only supported for DOS32. That's also *part*
of the reason why ex is bigger than exu and exw.
It would be nice to someday support these routines
on Linux and WIN32, but it's not a really high priority
at the moment.
> Despite the fact that we all keep saying "compiler,"
> I believe the gizmo Rob described was a "translator."
> You put in Euphoria and you get out C source,
> which you then feed into a C compiler.
A compiler is a translator from a source language to a lower-level
target language.
A C compiler translates the C language to machine language.
The Euphoria compiler translates Euphoria into C.
The techniques used are very similar to a normal compiler.
I think it's fair to call it a compiler, but to avoid confusion
I will frequently remind people that it translates to C and
that you need a C compiler to complete the job.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
29. Re: Compiler status
- Posted by Ben Fosberg <BenFosberg at WORLDNET.ATT.NET>
Jul 13, 2000
-
Last edited Jul 14, 2000
Robert Craig wrote:
> Ben Fosberg writes:
> > Is it being claimed here that the Win32 executable for the
> > interpreter includes the dos graphics library? If not,
> > those of us writing for Win32 aren't being "burdened" with
> > the library, are we?
>
> Only the DOS32 interpreter contains the WATCOM
> graphics library. That's why pixel-graphics
> library routines such as polygon(), ellipse(), pixel() etc.
> are currently only supported for DOS32. That's also *part*
> of the reason why ex is bigger than exu and exw.
> It would be nice to someday support these routines
> on Linux and WIN32, but it's not a really high priority
> at the moment.
Thanks for the clarification; that's what I thought, and therefore
whining about this support adding size to Win32/Linux programs is
baseless.
>
> > Despite the fact that we all keep saying "compiler,"
> > I believe the gizmo Rob described was a "translator."
> > You put in Euphoria and you get out C source,
> > which you then feed into a C compiler.
>
> A compiler is a translator from a source language to a lower-level
> target language.
>
> A C compiler translates the C language to machine language.
>
> The Euphoria compiler translates Euphoria into C.
That's a translator, not a compiler. You could also call it a
"pre-processor,' without complaint from me. I assume you're asserting
here that Euphoria is a higher level language than C, with which I
might agree. I disagree that a compiler produces a "lower level"
language - a compiler produces specifically "machine code."
>
> The techniques used are very similar to a normal compiler.
The "techniques" are not the issue; the product is the issue.
>
> I think it's fair to call it a compiler, but to avoid confusion
> I will frequently remind people that it translates to C and
> that you need a C compiler to complete the job.
I've never understood "fair;" if you call it a compiler when it's not,
then you'll confuse people. If you don't call it a compiler, you won't
have to keep reminding people that it doesn't compile, and you won't
have to deal with bogus issues like the size of the executables due to
support in your interpreter and translator for routines that, in fact,
aren't being compiled, and thus really don't add to the executables'
size.
In case you (or others) misread my tone, let me state for the record,
that as a _paying_ customer, I'm content with what you sold me, and
don't feel that having paid you what you asked for what you already
supplied entitles me to demand any further effort for my
interest/convenience. If you come up with something else I like at a
price I can accept, we'll be doing some more business; if you prefer
to work on something closer to your own heart, that's fine with me.
Unlike yourself, I have no interest in C, beyond having to grasp some
of it to navigate M$'s API, but I understand that lots of other people
do, and they have plenty to contribute to the "community."
Some free advice/encouragement, worth every penny:
You have a reputation for being a hard-nosed guy, unresponsive to the
needs/desires of your market. Personally, I think you've been
over-reacting to the complaints and wasting too much time in this
newlist dealing with piss-ant complaints and questions, although I'd
acknowledge that a very small number of them are probably legitimate.
To quote a very successful retailer, "you should always listen to your
customers, but you should never believe them."
Regard,
Ben Fosberg
High-Spirited Old Gasbag
>
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
30. Re: Compiler status
--
>> > Despite the fact that we all keep saying "compiler,"
>> > I believe the gizmo Rob described was a "translator."
>> > You put in Euphoria and you get out C source,
>> > which you then feed into a C compiler.
>>
>> A compiler is a translator from a source language to a lower-level
>> target language.
>>
>> A C compiler translates the C language to machine language.
>>
>> The Euphoria compiler translates Euphoria into C.
>
>That's a translator, not a compiler. You could also call it a
>"pre-processor,' without complaint from me. I assume you're asserting
>here that Euphoria is a higher level language than C, with which I
>might agree. I disagree that a compiler produces a "lower level"
>language - a compiler produces specifically "machine code."
It does? My Java *compiler* produces "Virtual Machine" Byte Code, not machine
code. Though I must give you that, the phrase "translating to C source code"
seems more logical than "compiling to C source code". Though the nature of the
word "compile" is too ambiguous when not compared to standards and history of
computing.
If it works, I'll call it whatever it wants to be called :)
Blah.
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
31. Re: Compiler status
On Tue, 4 Jul 2000 22:16:57 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:
>The Euphoria compiler project is moving along well.
>I'm successfully compiling all DOS32 programs in
>euphor22.zip, plus many large user programs
>such as the ee editor (over 10,000 lines of Euphoria).
>I even compiled the Cuny/Gayle Euphoria interpreter,
>making it run the sieve benchmark 2.1x faster.
>Sieve, compiled by the new compiler, runs 2.6x faster
>than with ex. Shell sort runs 3.2x faster. That's with
>minimal optimization. There's a lot more that I can do to
>improve the generated C code.
All right! Way to go, Rob!
32. Re: Compiler status
On Wed, 5 Jul 2000 11:49:00 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:
>Hawke' writes:
>> i'm a little puzzled tho...
>> is this creation of yours turning EU code -into- C code, which
>> then needs to be compiled using a C compiler...
>
>Right. It translates your Euphoria program into a set
>of C source files that you compile and link using
>a C compiler/linker (not supplied by RDS).
>It also makes a .bat file that will compile and link
>everything for you.
One tiny problem...some of us don't *have* the luxury of a C compiler.
Maybe you could try something that converts it directly into machine code.
I know, converting it to C is easier, but...
- Matt 'just had to chime in' Arriola
33. Re: Compiler status
"Darth Maul, aka Matt" wrote:
> On Wed, 5 Jul 2000 11:49:00 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:
>
> >Hawke' writes:
> >> i'm a little puzzled tho...
> >> is this creation of yours turning EU code -into- C code, which
> >> then needs to be compiled using a C compiler...
> >
> >Right. It translates your Euphoria program into a set
> >of C source files that you compile and link using
> >a C compiler/linker (not supplied by RDS).
> >It also makes a .bat file that will compile and link
> >everything for you.
>
> One tiny problem...some of us don't *have* the luxury of a C compiler.
> Maybe you could try something that converts it directly into machine code.
> I know, converting it to C is easier, but...
>
> - Matt 'just had to chime in' Arriola
There are pleanty of free compilers out there... gcc for Linux, and cygwin
(which is basically gcc and other unix development tools ported to windows).
Jeff Fielding
