1. A Portable API for Euphoria
------ =_NextPart_000_01BD5D67.09055140
Content-Transfer-Encoding: quoted-printable
Hi, All.
This is another one of those "gimme some feedback" posts.
I've been working on a port of Win32Lib to DOS. I've got most of the =
graphic primitives working, and can display most of the widgets that I =
need - text, buttons, check boxes and the like. Now I have to add =
functionality to the program.
Here's a screen shot of the kind of things that it can currently draw:
=20
I've been thinking about cross-platform issues, in the hope that some =
day in the near future Robert ports Euphoria to Linux and the Mac. It is =
unlikely that any of the Win32Lib code could usefully be ported to =
either platform - which would mean that any work on a GUI those =
platforms would again have to be coded from scratch, and would have no =
cross-platform compatibility.
Then I ran across Sun's recent port of Tcl/Tk. It runs on all three =
platforms with a native look and feel. This seemed like an ideal thing =
for Euphoria to use as a GUI library. Unfortunately, it seems unlikely =
that the Tk disentangled from the Tcl code easily, although there are a =
number of languages that use "pure" Tk as the basis for their user =
interface, so I know it can be done.
So I decided, what the heck - I'll try to put together a portable API. =
The proposed architecture is:
1. Minimal graphics core. This assumes nothing more than the ability to =
create windows, and read and write to a bitmaps on them. In the case of =
DOS, windows are emulated.
2. Widget display. This code displays windows, widgets and text using =
the graphics core. All the display is done using the graphics code in =
DOS - text is constructed from bitmaps. If the OS can handle these =
things, you'd use the regular OS calls.
=20
3. Widget emulation. This code provides functionality for any widget =
that cannot be handled by the OS. In the case of DOS, that means =
everything. In the case of any other OS, it would mean making "native" =
calls where possible. As an example of how this is different from the =
display level, a button bar would be emulated at this level for a GUI =
like X Windows, and the actual display of the buttons would be a native =
call in the widget display.
4. Event loop. This hooks into the Win32Lib code, as well as the widget =
emulation
5. I/O. This sends events from the OS to event loop. In DOS, this means =
converting mouse events and keystrokes into queued events for the event =
loop, such as "mouse click :menu bar" or "mouse move over:radio button =
32".
I'm using Tk as a rough model for the middle levels, so I don't just a =
port of the Win32 API. I've selected the Mac for similar reasons: it =
places various widgets in different locations than Win32 (the menu, the =
go away box, the status bar, etc.).
Since DOS will need to emulate *everything*, the minimum port to a new =
OS would be layers 1 and 5. To do a minimal port to Win32, for example, =
you would provide a large window with a bitmap as the screen, and =
capture mouse and keystroke events, and feed them to the event loop.
I've got the first two layers written for DOS32Lib. That's the easy =
part. The third layer is obviously the most difficult - especially =
keeping it GUI independant. Much of this code I've written before, for =
the TextGUI.=20
I hope to get *something* posted in the next couple of weeks. It =
probably won't do much, other than to pop up a window, print some text, =
and maybe toggle some controls.
OK, now for some questions:
1. Robert: Is there likely to be a Mac/Linux port in the near future? =
There's no point in doing all this work if Euphoria is going to remain =
locked to the WinTel architecture forever.
2. Is there a better way of doing this? I'm especially interested in =
people who might have a clue about X Windows, since I suspect that would =
be the next Euphoria port. Can I just hack into the Tcl/Tk DLL?
3. General comments?
Thanks for reading this.
-- David Cuny
------ =_NextPart_000_01BD5D67.09055140
2. Re: A Portable API for Euphoria
At 12:09 PM 4/1/98 -0800, David Cuny wrote:
re: portable GUI
<snip>
This is a really good idea, especially if Euphoria is ever
going to be ported to Un*x. Using the Windoz API is like
carrying an anchor from the Titanic to hold your rowboat.
Now, for a favor: Please consider sending your graphics
files to my web site. I still have room there, I'll make more
if you need it, and it would save a lot of people a lot of
bandwidth. They can look if they want.
(Some -- many? -- have to pay by the minute to download
these messages)
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
3. Re: A Portable API for Euphoria
>2. Is there a better way of doing this? I'm especially interested in
>people who >might have a clue about X Windows, since I suspect that would
>be the next >Euphoria port. Can I just hack into the Tcl/Tk DLL?
David:
I was also thinking in interfacing Euphoria to Tk.
I=B4ve been using Tk for a while, and it seems to cover all the needs for a =
GUI.
Beside this,as you stated, is cross-platform, and is written in C with
public-domain source code and *lots* of extents. Have you seen vtcl (Visual
Tcl)?.
There is also a nice paper on interfacing Tk with C at
http://users.vnet.net/drh/ET.html (Embedded Tk).
Since Euphoria is coded in C there should be no problem for Robert to write
such an interface...
And we could enjoy a portable platform (as soon as we have Euphoria ported ;=
-)
>3. General comments?
>
I agree in that some kind of cross-platform GUI generator is mandatory to
speed up the development of Euphoria applications. We should think that
with a very little programming resources, Euphoria development has arrived
very quickly to a mature level. Compare it to Visual Basic or other
Micro$oft pproducts, for instance. How long has taken to Java to establish
itself in the market?. And with how many people developing behind?.
Jesus, (sincerely believing in the future of Euphoria).
4. Re: A Portable API for Euphoria
At 11:20 PM 4/1/98 -0500, Jesus, (sincerely believing in the future of
Euphoria). wrote:
>>
>I agree in that some kind of cross-platform GUI generator is mandatory to
>speed up the development of Euphoria applications. We should think that
>with a very little programming resources, Euphoria development has arrived
>very quickly to a mature level. Compare it to Visual Basic or other
>Micro$oft pproducts, for instance. How long has taken to Java to establish
>itself in the market?. And with how many people developing behind?.
>
True:
Euphoria 1.5 compares well with, for example, Borland's 6.0
version of Pascal, which took what -- 8 or 10 years to evolve?
There are lots of things I would write in Euphoria if there were
a suitable GUI available.
David Cuny's text-gui was a good start. I'm looking
forward to the platform-independent version. Hopefully,
It will be written in an object-oriented manner. I started
writing my own winDoze package, keeping it as OO
as possible, and I am really impressed:
So far I have only implemented 3-d windows
with the usual titlebar/close/min/max buttons,
Borland style pushbuttons (the kind with shadowed
glyphs that change when clicked),
bitmapped window decorations (a la win95),
auto wrap text boxes, wallpaper backgrounds,
and (primitive) message passing. I need help with that part.
What surprised me was how little code (usually 20-50 lines)
it takes to implement each new window gadget, and how
easy it is to have a new gadget *inherit* behaviors from
its parent object. Another thing that will be important later:
due to Euphoria's ability to manage memory, there should
be an almost unlimited amount of what windoz knows
as "resources".
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
5. Re: A Portable API for Euphoria
>I've been working on a port of Win32Lib to DOS. I've got most of the
>graphic primitives working, and can display most of the widgets that
>I need - text, buttons, check boxes and the like. Now I have to add
>functionality to the program.
Excellent! The library could be so smart that using the platform() function
automatically knows wich "version" of the routines to load. Hmmm... thinking
it twice, it won't work... you need exw for win32, but it won't run on old
DOS :(
I don't know about Tcl/Tk, so no opinion.
>Here's a screen shot of the kind of things that it can currently draw:
Where?
>I've been thinking about cross-platform issues, in the hope that some
>day in the near future Robert ports Euphoria to Linux and the Mac. It
After Irv's experiments on Euphoria CGI, a Linux port would be quite more
usefu, and it's still x86 platform... faster to develop perhaps. A Mac port
would give a wider extension to the language, but who of us will develop for
Mac? It would be like starting from zero.
Maybe an Alpha (NT) port will help follow the Win32 developing line.
BTW David, I bought (is that how you spell it?) today Petzold's book. I
won't bother you for some time while I read it.
Regards,
Daniel Berstein.
6. Re: A Portable API for Euphoria
David Cuny wrote:
> 1. Robert: Is there likely to be a Mac/Linux port in the near future?
> There's no point in doing all this work if Euphoria is going to remain
> locked to the WinTel architecture forever.
That's a good question. I can't give a definitive answer right now.
I would like to see a version of Euphoria running on Linux and
the Mac, but there are difficult issues that I haven't resolved yet.
Such as:
- who is going to do it? Me? Junko? Someone I authorize?
Should I just release the core source to the world (minus
the DOS/Windows-specific code)?
- will it be totally free, or will there be a registered version?
- who controls the evolution of the language? Will there be
17 different flavors of Euphoria floating around?
- etc.
If someone other than myself does a port, I'm sure
they will need a lot of my help to get started. The code was designed
more for speed than for portability. It uses some WATCOM-specific
routines and features, although when I first ported from Atari to PC
I got it compiled and running using GNU C, before switching to
WATCOM.
Compared to DOS+Windows, Linux and Mac are both small
markets. I suspect that most
Linux people expect to get their programming languages,
and everything else, completely free including
full source code (Perl, Python, GNU, etc.).
I'll be thinking about these strategic issues
over the next few weeks. If anyone has any ideas,
let me know.
Regards,
Rob Craig
Rapid Deployment Software
7. Re: A Portable API for Euphoria
> That's a good question. I can't give a definitive answer right now.
> I would like to see a version of Euphoria running on Linux and
> the Mac, but there are difficult issues that I haven't resolved yet.
> Such as:
> - who is going to do it? Me? Junko? Someone I authorize?
> Should I just release the core source to the world (minus
> the DOS/Windows-specific code)?
> - will it be totally free, or will there be a registered version?
> - who controls the evolution of the language? Will there be
> 17 different flavors of Euphoria floating around?
> If someone other than myself does a port, I'm sure
> they will need a lot of my help to get started. The code was designed
> more for speed than for portability. It uses some WATCOM-specific
> routines and features, although when I first ported from Atari to PC
> I got it compiled and running using GNU C, before switching to
> WATCOM.
> Compared to DOS+Windows, Linux and Mac are both small
> markets. I suspect that most
> Linux people expect to get their programming languages,
> and everything else, completely free including
> full source code (Perl, Python, GNU, etc.).
well, Linux is a subset of Unix... very important to remember for the
moment... as far as Watcom C is concerned, take out all the
intrinsicly specific code to watcom C and you have 'generic' C
which will compile on any C compiler for any platform...
little bit of tweaking will be needed o'course...
in other words...
strip the specific and it will port easily...
and there will be multiple versions of euphoria needed
for each subset of Unix, or at least multiple makefiles
(which produce multiple versions anyway--of course)
now speed....heh... going back to generic code will then
prompt the necessity of optimizing for each subset...
I wouldn't worry about that, if I were you Rob...
there are enough proficient coders out there that will
tweak *anything* *anyway* just for sh_ts and giggles...
putting the Inet to work for you will take the burden from you...
catch22 is avoided because the sloppy versions that come about will
automatically be 'filtered' out once it's discovered that it's a
sloppy port for that particular Unix variant...
so, this covers the how and who...the two simpler questions you
proffered...
should it be free? Euphoria share/freeware already is...
perhaps the non-tweaked generic C version should be as well...
then offer registered versions that do what the current registered
version does, as well as registered & tweaked versions for common
Unix variants that are created by your team and do everything the
registered version does.(in theory they would be the best of all the
tweaked versions that arise? wouldn't they? :) )
should you release your code to the world?
Netscape did... but did it help them? not that I can see so far...
the premise of letting bunches of people look over your code for
loopholes and errors and optimization etc...well...
not a bad premise... but not really a great premise either IMHO.
it robs the programmer... some code 'should' be shared with
the world, other code not... reuseable code for app generation
probably should be freely given (small toolboxes and the like)...
compilers/interpreters and end result applications probably not...
linux and mac are small markets for some things..yes...
but Unix isn't... web servers alone...whew... how many
webservers are running on BSD Apache alone?????
euphoria used as a script CGI clone ala Irv and
compileable/interpretable on all those native Unix
OS's....big market...
throw in a TCP/IP toolbox, you've got multiuser
games in a big hurry...
my final take:releaseing the code itself is not something I would do.
releaseing unoptimized generic C ports to the Unix world in .exe
format for the most common Unix variants (very little work to do
that, I think?) would be good. Selling the code itself is also not
unheard of...you need to decide if Euphoria is a labor of love or if
you need it to keep the wolf from the door...
Mike
8. Re: A Portable API for Euphoria
- Posted by Daniel Berstein <danielberstein at USA.NET>
Apr 03, 1998
-
Last edited Apr 04, 1998
> - who is going to do it? Me? Junko? Someone I authorize?
> Should I just release the core source to the world (minus
> the DOS/Windows-specific code)?
I don't think you should "public" release the code (I'll continue the
issue later).
> - will it be totally free, or will there be a registered version?
Use the same principle you've succesfully used until now. A "lite"
version is freely available, and royalty-free, an enhanced version must be
registered. This way you get both: expansion (users) of the language and
money from who really needs Euphoria.
> - who controls the evolution of the language? Will there be
> 17 different flavors of Euphoria floating around?
RDS should control the evolution of the language, based on users request
off course. Euphoria is an RDS propietary language, I don't expect an
ANSI/ISO group defining it. The language definition should be just one for
all platforms, and only have "widgets" specific. I don't see any
inconcistensy. The first approach wouldn't include any special I/O such as
graphics, just STDIN, STDOUT and file access.
>If someone other than myself does a port, I'm sure
>they will need a lot of my help to get started. The code was designed
>more for speed than for portability. It uses some WATCOM-specific
>routines and features, although when I first ported from Atari to PC
>I got it compiled and running using GNU C, before switching to
>WATCOM.
During the last 2 years, RDS has won many inconditional users/contributors,
why not depend on this (some very skilfull) people for the subject?
I'm sure the whole thing can be broked on small tasks. The intelectual
property could be somewhat safe by letting each person access only some part
of the project. I personally won't feel offended if strategical code isn't
revealed to me... we would do this to improve Euphoria, and to be able to
use it on other platforms.
While a group of users is "portabilisizing" the 90% of the code, you can
have to time to port the classified 10%.
Even more, if you want to reward this people you can pay (in any mechanism
you choose, maybe as the actual "happy users" scheme) them with a
distribution of the first incomes from the ported program. RDS hasn't to
stay with 2 "employees" (you and Junko) you can "hire" others. People that
helps you are the ones who belive on Euphoria's future.
During this process, a byte-compiler ( EuJava ;) ) can be achieved... not a
bad idea huh!
>Compared to DOS+Windows, Linux and Mac are both small
>markets. I suspect that most
>Linux people expect to get their programming languages,
>and everything else, completely free including
>full source code (Perl, Python, GNU, etc.).
I'm sure developers will be quite intereset on a language that provides 40
to 60 times faster responce than Pearl or Python, 10 to 20 times faster
development time than C/C++, and 1/2 to 1/5, or less, cost than other
"professional" development tools. (even if WATCOM's optimization is lost,
Euphoria will certainly beat Pearl and Python).
>I'll be thinking about these strategic issues
>over the next few weeks. If anyone has any ideas,
>let me know.
Just remember that the future (present?) is the net. Euphoria running on a
networking OS will open a bigger market than what you think, dont fall on
Bill's short minded thoughts "640K ought to be enought...".
(or something like that).
Regards,
Daniel Berstein.
9. Re: A Portable API for Euphoria
- Posted by "Graeme." <hmi at POWERUP.COM.AU>
Apr 03, 1995
-
Last edited Apr 04, 1995
>> - who is going to do it? Me? Junko? Someone I authorize?
>> Should I just release the core source to the world (minus
>> the DOS/Windows-specific code)?
>
> I don't think you should "public" release the code.
I agree, please don't.
I am a bit sceptical about the whole cross platform thing.
Euphoria is an excellent package as is, and is moving forward at an
astounding rate, attempting to go sideways can only wash off the
momentum at a time when the launguage is blossoming.
One of Euphoria's most attractive features is it's reliability,
letting every man and his dog have a crack at it can only result
in multiple buggy versions floating around and potential new users
tossing it out after their first couple of GP errors. The fact of
the matter is that 90% of the world's computer users run Windoze on
a PC, unless you feel an urge to provide the world with an online
games engine why not keep going and push Eu into the major league
(where it deserves to be)?
At least save releasing the source until (if ever) you are totaly
sick of looking at it and you don't want to do any more with it.
In short, EU lacks every one of those annoying things found in other
launguages that make you want to stick your hand through your
monitor and throttle the person who wrote it. Don't let them get their
grubby mits on it!
VOTE 1 RDS for sole Euphoria developer (or at least Cheif Editors).
Tinkle Tinkle (two cents)
Graeme.
BTW any time you want to introduce vertical sequence slicing, I for
one won't complain.
10. Re: A Portable API for Euphoria
- Posted by Michael Sabal <mjs at OSA.ATT.NE.JP>
Apr 03, 1998
-
Last edited Apr 04, 1998
----------
From: Mike[SMTP:mdeland at NWINFO.NET]
Sent: Friday, 03 April, 1998 1:41 AM
To: Multiple recipients of list EUPHORIA
Subject: Re: A Portable API for Euphoria
<big snip>
About linux & mac -- double ditto for me.
Mike Sabal
11. Re: A Portable API for Euphoria
Robert Craig wrote:
<huge clip >
> I'll be thinking about these strategic issues
> over the next few weeks. If anyone has any ideas,
> let me know.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
Just my 2 cents worth,
one: RDS need to keep max controll over Euphoria, it's an amazing
language and I want to keep it that way.
Note I said controll, this isn't necesarily at odds with
release of (some) of the source code. just do it in very carefull
way, with contracts/license agreements/ threats to sue the life
outa those who don't toe the line, whatever it takes.
(perhaps give part of the linux/mac profits to whoever does
the port, but leave yourself the rights to the language itself, and
final say over wether the port is releasable(and the right to find
a new porter if necessary))
Two: before you port the source code to other OS/CPU combo's
you might want to consider getting all the docs converted
to multiple languages to increase the number of people on wintell
machines who can use it easily this might just create a bigger market
than porting to linux/mac.
Perhaps you could make set up a permesion to copy the manuals
for profit as long as the copies are not in any language RDS
publishess in?
Or give full registered versions of euphoria in exchange for
translating the manuals (and maybe ed?) into other languages.
Or somthing.
Three: I'm much more interested in a full compile ver of euphoria than
a mac euphoria. (though full compile is needed much less in euphoria
than most other languages), or possible a rewrite of as much of
the euphoria interpreter into ASM (assuming you haven't squeezed
every last bit into asm allready)
Kasey
