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
|
Not Categorized, Please Help
|
|
