1. Win32LIb/Llama Status
- Posted by David Cuny <dcuny at LANSET.COM>
Jun 24, 1999
-
Last edited Jun 25, 1999
For anyone curious about the status of Llama and Win32Lib:
[ The Bad News ]
Llama won't bind correctly, even with -clear_routines. I suspect the problem
is that I have a bunch of include files with the same local function names -
for example, "set".
(BTW, thanks for the hint about alt+034. I theory, that feature is supposed
to be in EE)
Anyway, Euphoria decides that the second "set" is a name conflict, and the
next "set" that follows... each is renamed some symbol like "Dg" or "Lw",
despite the -clear_routines option being selected.
Naturally, routine_id can't find the renamed symbol, and Llama returns error
after error about methods not being defined.
This is a Bad Thing. I could get around it by renaming the function to
unique identifiers, such as windowSet and pushButtonSet. But I'd prefer that
it just work correctly. I'd like to see this fixed, but not before the Linux
port.
[ Win32Lib Status ]
Sorry about not posting the latest version of Win32Lib. If anyone wants the
most current version (with updated documentation but no demos), snag the
copy that's posted with the Pretender demo. I've been hammering away at
Llama, and didn't get a chance to update it yet.
If anyone is holding off on writing an application using Win32Lib because
you think it'll be made obsolete by Llama, my advice is to use Win32Lib.
It's more stable and feature complete. When Llama finally gets stable enough
to start writing programs with, it should be trivial to port from Win32Lib.
[ New Llama Stuff ]
Pixmaps (color bitmaps) and BitBlt (fast graphic and sprites) work. I've
ported the Pretender demo; it seems to run ok. I didn't think I'd ever get
that stuff working.
The class library has been revamped, simplified and speeded up. All this is
invisible to the end user.
The native event handling code has been pulled out of the class library and
written in another module. This helps make the code more portable.
All the native widgets from the prior version of Llama have been ported to
the new version, except for menus. Menus are a bit more messy, and aren't
quite the no-brainer ports that most of the other classes were.
A couple of portable (emulated) controls have been implemented. I've got
push buttons, check boxes and radio buttons working, to some extent. These
controls look and feel like native controls, both to the developer and the
end user, and they work side-by-side with native controls.
And, of course, there are tons of small and large bug fixes.
[ What's Still Missing From Llama ]
Off the top of my head, I'd say the following features in Win32Lib have
still not been ported:
- multiple windows (they might work - I just haven't tested them)
- modal windows
- tab keys
- menus and menu bars
- decent documentation
All told, the gap between Win32Lib and Llama continues to close. I'm a bit
cautious about the speed of Llama - it seems to run OK, but I'm worried
about the overhead associated with the classes. With that said, I'm still
quite cautiously optimistic about Llama being able to replace Win32Lib.
[ So When Will It Be Posted ]
I'll try - really - to get a copy of Llama and the latest version of
Win32Lib out this weekend. No promises, though.
Comments?
-- David Cuny
-- David Cuny
2. Re: Win32LIb/Llama Status
On Thu, 24 Jun 1999, David Cuny wrote:
] [ The Bad News ]
[Paraphrase: Llama doesn't bind, whatever I do...]
] (BTW, thanks for the hint about alt+034. I theory, that feature is supposed
] to be in EE)
Gaah. I should have read this message before posting the last one :) :)
] Anyway, Euphoria decides that the second "set" is a name conflict, and the
] next "set" that follows... each is renamed some symbol like "Dg" or "Lw",
] despite the -clear_routines option being selected.
]
] Naturally, routine_id can't find the renamed symbol, and Llama returns error
] after error about methods not being defined.
]
] This is a Bad Thing. I could get around it by renaming the function to
] unique identifiers, such as windowSet and pushButtonSet. But I'd prefer that
] it just work correctly. I'd like to see this fixed, but not before the Linux
] port.
I think if this were to be fixed, BIND and SHROUD would have to become
2-pass compilers, which is something Rob wanted to avoid.
I'm just trying to think it through as I type...
Yup. Solved it, and it *doesn't* have to be 2-pass.
Routine_Ids should be set at compile time. They can't possibly change, so
I think this is a vialable option.
e.g.
function foo()
return time()
end function
bar = routine_id("foo")
Compiles to
function_token foo_tag ( ) return_token time_token ( ) end_token
function_token bar_tag = constant_from_id_table_for_foo
...or whatever. Notice it removes the need for a token for routine_id,
since it never gets used.
IMHO, it's a perfect argument for including and appending to an internal
routine_id() table for the interpreter.
We could then also do things like 'bar = routine_id("time")', without
having to define a wrapper function like 'foo()'.
Looks like I may have started another "we want _this_ feature" thread.
Sorry. :( :)
Carl
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail........: cyrek- at -bigfoot.com -- Remove hyphens. Ta :)
URL...........: http://www.bigfoot.com/~cyrek/
Uncrackable...: "19.6A.23.38.52.73.45 25.31.1C 3C.53.44.39.58"
3. Re: Win32LIb/Llama Status
>] Anyway, Euphoria decides that the second "set" is a name conflict, and the
>] next "set" that follows... each is renamed some symbol like "Dg" or "Lw",
>] despite the -clear_routines option being selected.
>]
>] Naturally, routine_id can't find the renamed symbol, and Llama returns error
>] after error about methods not being defined.
>]
<snip>
>I think if this were to be fixed, BIND and SHROUD would have to become
>2-pass compilers, which is something Rob wanted to avoid.
>
>I'm just trying to think it through as I type...
>
>Yup. Solved it, and it *doesn't* have to be 2-pass.
>Routine_Ids should be set at compile time. They can't possibly change, so
>I think this is a vialable option.
>
>e.g.
>
>function foo()
> return time()
>end function
>
>bar = routine_id("foo")
>
>Compiles to
>
>function_token foo_tag ( ) return_token time_token ( ) end_token
>function_token bar_tag = constant_from_id_table_for_foo
>
>..or whatever. Notice it removes the need for a token for routine_id,
>since it never gets used.
>
>IMHO, it's a perfect argument for including and appending to an internal
>routine_id() table for the interpreter.
Hmmm... might work. But we'd still need the routine_id token as well,
otherwise you couldn't get one on the fly:
sequence RoutineName
puts (1, "Enter procedure name to execute: ")
gets (RoutineName)
exec_procedure (routine_id (RoutineName), {})
RoutineName = GetInternalRoutine () -- determines another routine to use
exec_procedure (routine_id ("BuiltIn" & RoutineName), {})
But then, were Llama ever to construct the name of the routine, rather
than relying on a literal, we'd still run into the same problem... yuck.
>We could then also do things like 'bar = routine_id("time")', without
>having to define a wrapper function like 'foo()'.
Well, I'm really not too sure why we can't do this already. Then again,
I didn't write Euphoria... 
Rod Jackson
4. Re: Win32LIb/Llama Status
I've seen other attempts to make an otherwise procedural interpreted
language into an OOP language with the result being degraded performance
(eg. [incr] TCL). I believe trying to shoehorn OOP into Euphoria via Llama
with never result in the same level of performance now enjoyed by Win32Lib.
I, from a personal... and selfish standpoint, would prefer that you extend
Win32Lib into the BEST Windows GUI library for Euphoria that "money" can
"buy"! I know your ultimate goal is Cross-Platform GUI, but can't that be
achieved by redesigning Win32Lib instead? Other developers can learn to
extend it if you set the rules and provide examples.
Only my opinion... Gary.
-----Original Message-----
From: David Cuny <dcuny at LANSET.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, June 25, 1999 2:39 AM
Subject: Win32LIb/Llama Status
>For anyone curious about the status of Llama and Win32Lib:
>
>[ The Bad News ]
>
>Llama won't bind correctly, even with -clear_routines. I suspect the
problem
>is that I have a bunch of include files with the same local function
names -
>for example, "set".
>
>(BTW, thanks for the hint about alt+034. I theory, that feature is supposed
>to be in EE)
>
>Anyway, Euphoria decides that the second "set" is a name conflict, and the
>next "set" that follows... each is renamed some symbol like "Dg" or "Lw",
>despite the -clear_routines option being selected.
>
>Naturally, routine_id can't find the renamed symbol, and Llama returns
error
>after error about methods not being defined.
>
>This is a Bad Thing. I could get around it by renaming the function to
>unique identifiers, such as windowSet and pushButtonSet. But I'd prefer
that
>it just work correctly. I'd like to see this fixed, but not before the
Linux
>port.
>
>
>[ Win32Lib Status ]
>
>Sorry about not posting the latest version of Win32Lib. If anyone wants the
>most current version (with updated documentation but no demos), snag the
>copy that's posted with the Pretender demo. I've been hammering away at
>Llama, and didn't get a chance to update it yet.
>
>If anyone is holding off on writing an application using Win32Lib because
>you think it'll be made obsolete by Llama, my advice is to use Win32Lib.
>It's more stable and feature complete. When Llama finally gets stable
enough
>to start writing programs with, it should be trivial to port from Win32Lib.
>
>
>[ New Llama Stuff ]
>
>Pixmaps (color bitmaps) and BitBlt (fast graphic and sprites) work. I've
>ported the Pretender demo; it seems to run ok. I didn't think I'd ever get
>that stuff working.
>
>The class library has been revamped, simplified and speeded up. All this is
>invisible to the end user.
>
>The native event handling code has been pulled out of the class library and
>written in another module. This helps make the code more portable.
>
>All the native widgets from the prior version of Llama have been ported to
>the new version, except for menus. Menus are a bit more messy, and aren't
>quite the no-brainer ports that most of the other classes were.
>
>A couple of portable (emulated) controls have been implemented. I've got
>push buttons, check boxes and radio buttons working, to some extent. These
>controls look and feel like native controls, both to the developer and the
>end user, and they work side-by-side with native controls.
>
>And, of course, there are tons of small and large bug fixes.
>
>
>[ What's Still Missing From Llama ]
>
>Off the top of my head, I'd say the following features in Win32Lib have
>still not been ported:
>
> - multiple windows (they might work - I just haven't tested them)
> - modal windows
> - tab keys
> - menus and menu bars
> - decent documentation
>
>All told, the gap between Win32Lib and Llama continues to close. I'm a bit
>cautious about the speed of Llama - it seems to run OK, but I'm worried
>about the overhead associated with the classes. With that said, I'm still
>quite cautiously optimistic about Llama being able to replace Win32Lib.
>
>
>[ So When Will It Be Posted ]
>
>I'll try - really - to get a copy of Llama and the latest version of
>Win32Lib out this weekend. No promises, though.
>
>Comments?
>
>-- David Cuny
>
>-- David Cuny
5. Re: Win32LIb/Llama Status
On Fri, 25 Jun 1999, Roderick Jackson wrote:
] >IMHO, it's a perfect argument for including and appending to an internal
] >routine_id() table for the interpreter.
]
] Hmmm... might work. But we'd still need the routine_id token as well,
] otherwise you couldn't get one on the fly:
]
] sequence RoutineName
]
] puts (1, "Enter procedure name to execute: ")
] gets (RoutineName)
]
] exec_procedure (routine_id (RoutineName), {})
]
] RoutineName = GetInternalRoutine () -- determines another routine to use
]
] exec_procedure (routine_id ("BuiltIn" & RoutineName), {})
I hadn't thought of using routine_id() like that. Maybe because asking a
user for a subroutine name seems insecure. One good/bad guess and the
system goes belly-up.
The other idea is a good one, but for things like that, you should be
developing your own sequence/table of ids like so:
-- builtins.e --
global sequence BuiltIn
function joblot()
-- etc. etc.
return something
end function
-- etc. etc.
BuiltIn = {
routine_id("joblot"),
routine_id("etc. etc."),
---
}
-- program.ex --
-- Now use GIR() like so:
RoutineLocalId = GetInternalRoutine()
exec_procedure(BuiltIn[RoutineLocalId])
IMHO, using anything but straight strings in routine_id() calls is bad
programming practice. YMMV OC. :)
Carl
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail........: cyrek- at -bigfoot.com -- Remove hyphens. Ta :)
URL...........: http://www.bigfoot.com/~cyrek/
Uncrackable...: "19.6A.23.38.52.73.45 25.31.1C 3C.53.44.39.58"
6. Re: Win32LIb/Llama Status
>On Fri, 25 Jun 1999, Roderick Jackson wrote:
>
>] >IMHO, it's a perfect argument for including and appending to an internal
>] >routine_id() table for the interpreter.
>]
>] Hmmm... might work. But we'd still need the routine_id token as well,
>] otherwise you couldn't get one on the fly:
>]
>] sequence RoutineName
>]
>] puts (1, "Enter procedure name to execute: ")
>] gets (RoutineName)
>]
>] exec_procedure (routine_id (RoutineName), {})
>]
>] RoutineName = GetInternalRoutine () -- determines another routine to use
>]
>] exec_procedure (routine_id ("BuiltIn" & RoutineName), {})
>
>I hadn't thought of using routine_id() like that. Maybe because asking a
>user for a subroutine name seems insecure. One good/bad guess and the
>system goes belly-up.
I would never put it in public code myself; but I've used it for
debugging purposes before.
>The other idea is a good one, but for things like that, you should be
>developing your own sequence/table of ids like so:
<snip>
>IMHO, using anything but straight strings in routine_id() calls is bad
>programming practice. YMMV OC. :)
Well, I had originally planned on constructing routine names in Quartz...
until I discovered that routine_id is purposefully restricted from
accepting routine names ahead of it in source code, even at runtime. It
would have actually made things quite a bit cleaner, though. Granted,
it's probably a rare case, but it's also an example where maintaining a
table would have just made things more cumbersome. I guess it's kind of
like the obscure case where using 'goto' is actually *helpful*.
Um, by the way... what is YMMV OC??
Rod Jackson
7. Re: Win32LIb/Llama Status
Carl L White wrote:
> Looks like I may have started another
> "we want _this_ feature" thread.
I don't think I'm asking for anything new. Assuming I've diagnosed the bug
correctly (always an iffy proposition), I can't eveny start to suggest how
Robert solve the problem, because I don't know the internal workings of
Euphoria.
Roderick Jackson wrote:
> But then, were Llama ever to construct the name of the
> routine, rather than relying on a literal, we'd still run into
> the same problem... yuck.
Because of the way that routine_id is scoped (one of my running complaints
with Robert), I couldn't do this anyway. But I maintain an internal list of
method names, so the name of the function does *not* have to match the name
of the method. So I can construct names internally if I wanted - something
that I've toyed with.
Gary Dumer wrote:
> I've seen other attempts to make an otherwise
> procedural interpreted language into an OOP
> language with the result being degraded performance
> (eg. [incr] TCL). I believe trying to shoehorn OOP into
> Euphoria via Llama with never result in the same level
> of performance now enjoyed by Win32Lib.
This is, of course, true. Since all methods are akin to C virtual functions,
they are resolved at run time. Add a wrapper to these, and you have a
performance hit. The question is, it the performance still acceptable?
In prior versions of Llama, there was a lot of work involved in finding a
method - the program first check if the method was virtual or not, and then
walk up the inheritance tree to find the class which implemented the method.
It would then set the object to "spoof" that class, and then call the
method.
In the current version, all methods are "virtual" - that is, the method most
recently defined is the one executed. Looking up methods is trivial - all
method names are placed into a single (flat) table. The biggest performance
his *seems* to be the debugging stuff, which will be dropped from the final
run time anyway.
> I, from a personal... and selfish standpoint, would prefer
> that you extend Win32Lib into the BEST Windows GUI
> library for Euphoria that "money" can "buy"!
The reasoning behind OOP is, surprisingly enough, not cross-platform, but a
namespace kind of thing. It insulates the library, and allows easy extention
of new Win32 (or portable) objects.
> I know your ultimate goal is Cross-Platform GUI, but
> can't that be achieved by redesigning Win32Lib
> instead? Other developers can learn to extend it
> if you set the rules and provide examples.
Win32Lib was not designed to be extensible. Llama, on the other hand, is.
There are two general ways to make Win32Lib extendable. The first is to
extend the methods internally, such as:
global procedure setText( integer self, sequence text )
if myClass[ self ] = WINDOW then
-- window handling code
elsif myClass[ self ] = MENU then
-- menu handling code
else
-- normal control
end if
end procedure
This gets messy very quickly. And if developer #1 adds a class to the
library, and developer #2 adds a class, then someone is going to have to
resolve those different code bases together. A better approach is:
global procedure setText( integer self, sequence text )
integer routine
-- look up the routine
routine = setTextRoutine[ myClass[ self ] ]
-- run the proc
call_proc( routine, {text} )
end procedure
This way, all you need to do is include the new object in - no code to
resolve! Much, much cleaner. Same thing with hooking events.
There is so much sharing of functions between Win32 classes as it is that is
makes sense to use OOP to set up the structure. For example, all graphic
methods are defined in the Llama class are implemented in the class
Drawable. There is only a small difference between how a Window implements
these versus how a Bitmap does it - mainly in the getDC/releaseDC portion.
Extensibility is what differentiates Llama from Win32Lib, not cross-platform
compatiblity - it just turns out that the same methods that insulate classes
from each other are the same methods that insulate them from the underlying
operating system.
Class re-use is what drives the OOP model. At this point, it looks like the
correct decision.
The exception I'm worried about it fast graphic games, but at this point,
the Llama demo would seem to indicated that the performance is acceptable.
And keep in mund that the code is still under development - I haven't really
done much performance tuning.
-- David Cuny
8. Re: Win32LIb/Llama Status
David Cuny writes:
> Llama won't bind correctly, even with -clear_routines.
> I suspect the problem is that I have a bunch of include
> files with the same local function names - for example, "set".
Yes, that is likely the problem.
All programs that do not use routine_id() can be bound.
Most programs (e.g. win32lib.ew) that use routine_id()
can also be bound, using the existing bind program and
the -clear_routines option.
However, the bind program was designed long before
routine_id() was introduced, and there are some cases
that can't be handled.
After the Linux port, my top priority is to improve the
namespace situation, and part of that effort will involve
changes to the bind program, perhaps a major redesign.
That should allow binding to work for 100% of programs.
How the binder currently works:
The binder takes a multi-file program, consisting of a main
file and all necessary include files, and it converts it into
a single large file. In general, this shouldn't be possible if there
are local symbols in 2 different files that have the same name.
However, the binder changes all names to short,
meaningless names of it's own choosing. fred() in x.e
might be changed to aa(), while fred() in y.e might be changed
to bb(), so there's no conflict.
Now, suppose the programmer has routine_id("fred") in his
program. fred() has been changed to aa(), so this routine_id()
call is now wrong. The binder will issue a warning, and you
must rebind with -clear_routines. This will force the binder to
leave fred() in x.e and fred() in y.e unchanged. But now
when the second instance of fred is encountered, the binder
will issue a warning, and change the 2nd fred anyway,
in the hope that you aren't calling routine_id for the second fred().
If you ignore the warning, you can run, but things will likely fail.
In the redesign, I hope to get away from the concept
of creating "one" file. The source file
boundaries would be retained somehow, solving this
routine_id situation and making other features available,
such as the option to bind clear, unshrouded source, and
get proper ex.err dumps etc.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
9. Re: Win32LIb/Llama Status
On Fri, 25 Jun 1999, Roderick Jackson wrote:
] Um, by the way... what is YMMV OC??
"Your Milage May Vary, Of Course" :)
Sorry. Sometimes I just lapse into little used jargon.
Carl
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail........: cyrek- at -bigfoot.com -- Remove hyphens. Ta :)
URL...........: http://www.bigfoot.com/~cyrek/
Uncrackable...: "19.6A.23.38.52.73.45 25.31.1C 3C.53.44.39.58"
