Terry Bayne | 5 Sep 13:14 1997
Picon

LUA and Windows 3.1 and Win95

Hi,

I think I remember seeing something posted to the list about a Windows 3.x 
dll for LUA a while back - does anyone know if such an animal exists?  Also 
anyone know of the same (a DLL) for Win95?

Thanks 
Terry Bayne
Gnome
=========================================
gnome <at> iquest.com

When you lose your name, you become small.
When you lose your spirit, you become nothing.

                             -R.K. Partain

Ciaran Mc Namara | 7 Sep 17:44 1997
Picon
Picon

Tklua and Win95

Hi,

Does anyone know if it's possible to get the OpenGL canvas in TkLua to work under Win95? I have no idea how to do this, so I would like to know if anyone else has tried.
Thanks,

Ciaran Mc Namara
ciaranmn <at> iol.ie
http://www.iol.ie/~ciaranmn/

Waldemar Celes | 8 Sep 19:23 1997
Picon

Re: Tklua and Win95

> Does anyone know if it's possible to get the OpenGL canvas in TkLua to work
> under Win95? I have no idea how to do this, so I would like to know if
> anyone else has tried.

Yes, I have a very alpha version of TkLua that runs on Win95.
Unfortunately, I'm moving and have been quite busy these days.
How urgent do you need it? 
I can send you the version I'm working on
or you can wait until I get a more stable implementation.

-- waldemar

--------------
Waldemar Celes
Program of Computer Graphics
Cornell University
580 Engineering Theory Center Building
Ithaca, NY -- 14853
e-mail: celes <at> graphics.cornell.edu
home page: http://www.graphics.cornell.edu/~celes/

Mike Fahl | 8 Sep 23:25 1997
Picon

Thread-support in LUA

I'm interested in the possibility of doing some multi-threaded work with
LUA. However, there seem to be many global variables that could make
this diffucult. I would like to have each "LUA-thread" start out from
scratch (ie, as LUA normally starts up), and then only execute within
its own domain. 

I guess I could probably do this as separate processes (ie,
"fork"-style), but I would prefer to do it with separate threads within
the same process.

I assume this means I'd have to collect all LUA globals into a
LUAGlobals structure. I would then have to allocate one such LUAGlobal
structure for each thread, basically acting as a control block for its
LUA thread.

Does this make any sense? Have anybody else attempted something like
this? Any ideas or suggestions would be most welcome.

Mike Fahl

Bret Mogilefsky | 9 Sep 03:42 1997

RE: Thread-support in LUA

Yes, I've done it for my game, but due to legal constraints by my
company, I'm not allowed to fold the changes back into Lua.  I did
cooperative multitasking, meaning each thread has to yield in order for
other threads to run and data is shared among the tasks.  You're right
in that collecting the globals together per task is the main thing, but
there are some other concerns.  In particular, Lua uses recursion for
its call stack... This is fine without multitasking, but as soon as you
add multitasking to the mix things get complex.  What happens if, say,
you have functions calling back from C to Lua in one task, so your
frames look like this:

	Lua1
	C1
	Lua2
	C2
	C3
	Lua3

While in another task, it looks like this:

	Lua4
	Lua5

If you yield from that first task to the second task, you are nested way
too deeply for the second task to properly finish or even yield to other
tasks without causing the same problem.  The solution is of course to
flatten the Lua call stack, creating an actual stack data structure on
which to push frames without recursing in C.  This is actually a lot
more difficult if you do it second (as I discovered to my misery), so
try to get it out of the way before you collect up the global variables.

If you have any questions, send them on and I'll answer them the best I
can without sending out code.

Good luck!

Bret

> -----Original Message-----
> From:	fahl <at> dataton.se [SMTP:fahl <at> dataton.se]
> Sent:	Monday, September 08, 1997 4:07 PM
> To:	Bret Mogilefsky
> Subject:	Thread-support in LUA
> 
> I'm interested in the possibility of doing some multi-threaded work
> with
> LUA. However, there seem to be many global variables that could make
> this diffucult. I would like to have each "LUA-thread" start out from
> scratch (ie, as LUA normally starts up), and then only execute within
> its own domain. 
> 
> I guess I could probably do this as separate processes (ie,
> "fork"-style), but I would prefer to do it with separate threads
> within
> the same process.
> 
> I assume this means I'd have to collect all LUA globals into a
> LUAGlobals structure. I would then have to allocate one such LUAGlobal
> structure for each thread, basically acting as a control block for its
> LUA thread.
> 
> Does this make any sense? Have anybody else attempted something like
> this? Any ideas or suggestions would be most welcome.
> 
> Mike Fahl

David Jeske | 9 Sep 04:03 1997
Picon

Re: Thread-support in LUA

On Mon, Sep 08, 1997 at 08:08:24PM -0300, Mike Fahl wrote:
> I'm interested in the possibility of doing some multi-threaded work with
> LUA. However, there seem to be many global variables that could make
> this diffucult. I would like to have each "LUA-thread" start out from
> scratch (ie, as LUA normally starts up), and then only execute within
> its own domain. 

I have an interest in doing the same thing. 

> I guess I could probably do this as separate processes (ie,
> "fork"-style), but I would prefer to do it with separate threads within
> the same process.

Same..

> I assume this means I'd have to collect all LUA globals into a
> LUAGlobals structure. I would then have to allocate one such LUAGlobal
> structure for each thread, basically acting as a control block for its
> LUA thread.

This was my plan when I decided I needed to do this. I have not had the
time to implement it though. A "psudo-overlapping" desire of mine is to
have first-class function definetions (like lambda functions, in that you
would do something like "boo = function(a,b) ... end". When I brought this
up before, it was said that the parser needs to be made reenterant for
this to work, so I was hoping to combine my efforts for these two things.

--

-- 
David Jeske (N9LCA) + jeske <at> chat.net

David Jeske | 9 Sep 06:07 1997
Picon

Re: Thread-support in LUA

On Tue, Sep 09, 1997 at 12:00:25AM -0300, Bret Mogilefsky wrote:
> cooperative multitasking, meaning each thread has to yield in order for
> other threads to run and data is shared among the tasks.  You're right
> in that collecting the globals together per task is the main thing, but
> there are some other concerns.  In particular, Lua uses recursion for
> its call stack... This is fine without multitasking, but as soon as you
> add multitasking to the mix things get complex.  What happens if, say,
> you have functions calling back from C to Lua in one task, so your
> frames look like this:

However, what both of us were talking about won't run into this problem.
We were not going to share data and have a concept of "multiple-lua"
threads. We effectively just want to be able to instantiate multiple
copies of the "lua environment", each in it's own thread, but completely
separate. 

While it would be nice to include all of this functionality into Lua, I
don't have any immediate need for multiple threads within one global lua
space.

--

-- 
David Jeske (N9LCA) + jeske <at> chat.net

Picon

Re: Thread-support in LUA

>A "psudo-overlapping" desire of mine is to
>have first-class function definetions (like lambda functions, in that you
>would do something like "boo = function(a,b) ... end". When I brought this
>up before, it was said that the parser needs to be made reenterant for
>this to work, so I was hoping to combine my efforts for these two things.

We currently are working on exactly this extension for Lua 3.1.
Keep tuned. :-)
--lhf

PS: About the junk in lua-l lately:
    1. Spam is too hard to avoid. Any ideas, besides moderation?
    2. Unfortunately we have not managed to change the headers produced by
       listproc so as to avoid personal replies being sent to the list.
       listproc even puts the "wrong" "From" field, and misleads people
       into thinking that the reply will go to the sender instead of to the
       list. The "Reply-to" field is set to "lua-l", but is usually hidden
       from view.
       Does anyone know how to change this in listproc?
       In the meantime, please double check a reply before sending it.
       (This applies to me too!)

       As a whole, we are less than happy with listproc; we are thinking
       about switching to majordormo, as soon as our sysadm has some time.
       On the other hand, I'm pleased with the traffic in Lua: not too much,
       no junk at all (except for the last few days), only good questions
       and answers.

--lhf

Mark Ian Barlow | 9 Sep 14:20 1997
Picon
Picon

Re: Thread-support in LUA

In message <19970908210724.58827 <at> home.chat.net> David Jeske wrote:
 > On Tue, Sep 09, 1997 at 12:00:25AM -0300, Bret Mogilefsky wrote:
 > > cooperative multitasking, meaning each thread has to yield in order for
 > > other threads to run and data is shared among the tasks.  You're right
 > > in that collecting the globals together per task is the main thing, but
 > > there are some other concerns.  In particular, Lua uses recursion for
 > > its call stack... This is fine without multitasking, but as soon as you
 > > add multitasking to the mix things get complex.  What happens if, say,
 > > you have functions calling back from C to Lua in one task, so your
 > > frames look like this:
 > 
 > However, what both of us were talking about won't run into this problem.
 > We were not going to share data and have a concept of "multiple-lua"
 > threads. We effectively just want to be able to instantiate multiple
 > copies of the "lua environment", each in it's own thread, but completely
 > separate. 

There's a terminology confusion here, I think. Traditionally "threads" are
lightweight, and all share the same stack while "processes" are completely
independent as David describes. Threads do not *have* to share other data,
however, and current thinking amongst most formal methods folk is that they
shouldn't be *seen* to (from the user's point of view) even if they actually
*do* at the implementation level.

On this basis I'd say David is on the right track, but Bret has a point: You
couldn't preemtively multitask between your threads unless they each had a
protected stack space, because if you did a longjmp() to some point inside
a previously suspended thread it might subsequently walk all over the call
stack of the one you just suspended. The only way you could make this work
using a single stack would be if each thread's stack requirements were
statically determinable at compile time (with Lua? no chance!).

Pragmatically then, fork/join would be the best way to get things working
quickly, and pipes could be used for communication. David doesn't say (this
confuses me a bit) that he wants to multitask his Lua sessions and communicate
between them but I don't see what use they would be if you couldn't; If you
just want multiple independent sessions surely you just spawn them from a
shell script? I suppose this goes beyond ANSI C, however; such a "Parallel
Lua" would really need POSIX compliance as well. To go the other way would
need, as Bret says, the splitting off of Lua's call stack from C's and it's
incorporation into a "Lua_Thread" structure along with the globals.

A lot of the basic theory for multitasking derives from C.A.R. Hoare's work
at Oxford University here in the UK. IMHO, the designers of Java slipped up
badly when they used his earlier concept of monitors (ie: 'synchronised'
methods) rather than his later and much superior CSP ("Communicating-
Sequential-Processes") model as used (but not exclusively) in Ada. In the
former, a thread-safe application *can* be written, with due discipline;
in the pure form of the latter it is impossible to write an un-safe one.

Note that it is still possible under both schemes to write an application
that will deadlock, ie: halt because a closed loop of processes are all
waiting for their predecessors to perform some action before they can
continue. If you want to avoid this you must analyse your program using
higher-level concepts; Eg: restrict yourself to a client-server model and
ensure that if closed communication loops exist then the client => server
direction is always either "clockwise" or "anti".

I write embedded (sometimes quite safety-critical) multi-processor robotic
applications and I've been using an obscure parallel processing language
called 'occam' for years now. See http://www.hensa.ac.uk/parallel/occam/
if you're interested. It's based on CSP, with strict type-checking applied
to communications (and assignments too, of course). The confidence, and
hence productivity you gain from not being allowed to make mistakes is
well worth the frustration of seeing a few extra compiler errors, believe me!

I'm not suggesting Lua needs strict typing BTW, just that it *doesn't* need
<yuck> shared memory. I suppose what I *am* saying is that multi-threaded,
multi-tasking programming is only ever going to be much fun to do on a large
scale if you have a lot of compiler support, which goes against Lua's spirit
somewhat.  Java people struggle and thrash around trying to coordinate of the
order of 10 threads; Ada pushes that envelope a bit, and occam allows me to
cope easily with 100+ but only at the expense of great formality in the
language: The pre-compilation checking must be > 80% of the total
compiler code!

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    Mark <at> nlcc.demon.co.uk            Voice / Fax: +44 (0)1207 562 154

Tony Wetmore | 9 Sep 17:16 1997

RE: Thread-support in LUA


Luiz,

> We currently are working on exactly this extension for Lua 3.1.

Do you have an idea when you might be releasing v3.1 of Lua?  Can
you describe what exactly you intend to implement in 3.1 to address
the "thread" issues discussed here?

Along with a co-worker, I am currently investigating various "embedded
languages" for use in our games, and need to decide which language
to integrate fairly soon.  The other languages we are currently considering
are Tcl and Python.

The single biggest problem that I see with Lua is the global environment,
where Lua seems to assume that you are only running one Lua program
at a time.

We would like to use an embedded programming language to control
many objects within our game, each having its own "brain".  Lua is one
of our top choices for such a language, obviously, but currently we
would add this multiple environment layer on top of Lua.  If you guys 
are already working on such an enhancement, however, that's better! :)

Thanks for all the great work!

+===========================================+=====================+
| Tony Wetmore (mailto: wetmore <at> kesmai.com) | Senior Programmer   |
|-------------------------------------------| Kesmai Studios      |
| Opinions are mine, ALL mine!              | Charlottesville, VA |
+===========================================+=====================+


Gmane