1. GtkLib
I've been trying to get GtkLib is shape for posting. I got fonts, graphics
and colors working under Win32, and was hoping to be able to post it last
night. But it's not creating a graphic context under Linux. So much for
cross-platform compatibility.
I don't remember if I mentioned it before, but the X Window libraries I've
looks at don't like to draw directly to the window. Instead, you have to
define a drawable area on the window, and draw to that. So I've created a
Canvas widget to get around that. I could either resort to using XLib calls
to handle the graphics (not a thrilling idea, but workable), or define a
similar construct in Win32Lib. Opinions?
In any event, progress is being made on GtkLib, and I hope to be able to fix
the bug(s) and have something to post in a couple of days.
-- David Cuny
2. GtkLib
I've sent a copy of GtkLib for Linux to Robert. It's pre-pre-alpha. It's a
clone of Win32Lib, using GTK+ (the GIMP toolkit library). It's a bit buggy,
and there are a couple points I'm having trouble with, like getting the
dropdown menus to work, and printing to the window. Help on these items is
appreciated.
If anyone wants to play with it under Win32 instead, I can send Robert the
Win32 DLLs as well.
Thanks!
-- David Cuny
3. GtkLib
- Posted by David Cuny <dcuny at LANSET.COM>
Aug 20, 1999
-
Last edited Aug 21, 1999
From the rumor mill at www.slashdot.org, I see that GTK is in the process of
being ported to the BeOS (take a look at www.gtk.org for screenshots).
I mention this because:
1. I'm playing around with Gtk,
2. rumor has it that Peuphoria runs on the BeOS, and
3. GtkLib just *might* run under Peuphoria.
GtkLib already runs/limps/crahses-and-burns under Win32 and Linux. The
possibility of being able run applications on three different operating
systems is a bit heady.
How's progress on Peuphoria going, Pete?
-- David Cuny
4. Re: GtkLib
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM>
Aug 20, 1999
-
Last edited Aug 21, 1999
David writes:
> From the rumor mill at www.slashdot.org, I see that GTK is in the
> process of being ported to the BeOS (take a look at www.gtk.org for
> screenshots).
>
> I mention this because:
>
> 1. I'm playing around with Gtk,
> 2. rumor has it that Peuphoria runs on the BeOS, and
This is still a rumor as far as I know, if anyone can confirm it, I would
be very appreciative.
> 3. GtkLib just *might* run under Peuphoria.
This could be questionable. Peu was still extremely buggy last time I
checked. I tried some of the Euphoria benchmarks, and got some weird
results... like negative time for the sequence initializations (which is
just a repeat() in a for loop.. the Peu evaluates the repeat() at compile
time because it is a constant function, so it ends up just assigning a
constant during the loop) and segfaults shortly thereafter.
> GtkLib already runs/limps/crahses-and-burns under Win32 and Linux. The
> possibility of being able run applications on three different operating
> systems is a bit heady.
Wait until you see Neil 2. I've got graphics windows in X with shared
pixmaps and all that jazz, truecolor support and everything you've come to
love (or hate) about Neil. It should run programs unmodified on Linux,
DOS32 and maybe WIN32 (if I ever boot into that horrid operating system
again 
(note: I'm typing this in Windows now, my parents don't have
linux and I doubt they would appreciate me installing it for them, they
even got a little tweaked about moving from windows 95 to 98... sheesh)
> How's progress on Peuphoria going, Pete?
prog-ress? noun. Forward movement toward a goal or accomplishment... Um,
I haven't touched Peu since Eu Linux came out... I'd much rather code in
Euphoria than code Euphoria in C. Rob Craig should be commended for all
the work he's done in making a stable, safe, easy programming language. I
can't wait until he releases an Alpha for Linux, so I can debug without
having to trace through big chunks of code.
I am still interested in writing Euphoria interpreters and compilers. I
think it's great that the EuOS team is involved in one. I have some
thoughts on how to convert Euphoria to native machine code, for a real
compiler, and that the compiler might be able to be written in Euphoria,
making it a just-in-time compiler. Since it would be compiled just before
runtime, it could take advantage of the processor instruction set,
utilizing 3DNow!, MMX, or SIMD instructions which could be great for
sequence manipulations. It could also use callbacks to itself in the
compiled code for doing some of the more difficult things... like
routine_ids or stuff like that. I remember Ralf spoke of moving
loop-invariant code out of loops, one of many optimizations that could be
done for Euphoria code. Other optimizations might be common
subexpressions and strength reduction (changing multiplies by a constant
into adds inside loops)
La, la, la, later,
_______ ______ _______ ______
[ _ \[ _ ][ _ _ ][ _ ]
[/| [_] |[/| [_\][/ | | \][/| [_\]
| ___/ | _] | | | _]
[\| [/] [\| [_/] [\| |/] [\| [_/]
[_____] [______] [_____] [______]
xseal at harborside.com ICQ:13466657
http://www.harborside.com/home/x/xseal/euphoria/
5. Re: GtkLib
Pete wrote:
>I haven't touched Peu since Eu Linux came out...
> I'd much rather code in Euphoria than code
> Euphoria in C.
Gee, *that* sounds familiar. A couple of months, I started coding Gnuphoria
again, but wrote it in a small subset of Euphoria that I could convert to C.
I guess if we really loved C that much, we wouldn't be coding in Euphoria,
would we?
>I am still interested in writing Euphoria
> interpreters and compilers.
Good!
> I have some thoughts on how to convert Euphoria
> to native machine code, for a real compiler, and that
> the compiler might be able to be written in Euphoria,
> making it a just-in-time compiler.
I've toyed around with compiling to a Euphoria virtual machine. To a large
extent, Robert's already written on. Think of machine_proc and machine_func
as defining some of the core methods, along with sequence manipulation
operations (create, clone, dereference, destroy, append, prepend, insert)
and you've got the core language.
These calls (written in C) would then be glued together by an interpreter,
which would convert Euphoria into C/assembly/Java bytecodes/Euphoria
bytecodes/whatever.
> Neil...
Sounds interesting. My DOS port of Llama got way to complex when I couldn't
decide if I was supposed to parent the Window into a Frame and redirect
graphic calls in the Window to the Frame, combine the Window and Frame into
a single object, or whatever... Hopefully, I'll get it right this time. I'd
really like to see Llama running under EWE.
-- David Cuny
6. Re: GtkLib
>Pete wrote:
>
>>I haven't touched Peu since Eu Linux came out...
>> I'd much rather code in Euphoria than code
>> Euphoria in C.
>
>Gee, *that* sounds familiar. A couple of months, I started coding Gnuphoria
>again, but wrote it in a small subset of Euphoria that I could convert to C.
>I guess if we really loved C that much, we wouldn't be coding in Euphoria,
>would we?
>
>>I am still interested in writing Euphoria
>> interpreters and compilers.
>
>Good!
>
>> I have some thoughts on how to convert Euphoria
>> to native machine code, for a real compiler, and that
>> the compiler might be able to be written in Euphoria,
>> making it a just-in-time compiler.
>
>I've toyed around with compiling to a Euphoria virtual machine. To a large
>extent, Robert's already written on. Think of machine_proc and machine_func
>as defining some of the core methods, along with sequence manipulation
>operations (create, clone, dereference, destroy, append, prepend, insert)
>and you've got the core language.
>
>These calls (written in C) would then be glued together by an interpreter,
>which would convert Euphoria into C/assembly/Java bytecodes/Euphoria
>bytecodes/whatever.
After reading this, I thought people might be interested in a recent posting
of mine to comp.lang.forth:-
'I'm considering writing a Euphoria to Forth cascader, both for practice in
Euphoria and to increase Euphoria's portability (and because the underlying
VM sounds quite close to Forth). "Euphorth"?'
BTW, Forth provides a virtual memory feature in most implementations, which
would also help. A "true" compiler could go one extra level, generating
Forth to put into an assembler skeleton, the way Eforth does - that's
intended to increase the Forth portability even further, by piggybacking on
whichever assemblers are available. PML.
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
