headers
Luiz Henrique de Figueiredo | 2 Feb 2000 16:03
Picon

Re: wxWindows for Lua? [repost]

>From luagnome <at> free.fr  Wed Feb  2 11:47:39 2000

En réponse à Nils Svangard <Nils.Svangard <at> abc.se>:

> Has anyone made a attempt of creating a interface for wxWindows in Lua?
>
> -- Nils
>
> 

Sorry if your concern is purely wxWindows, but if you search bindings to a GUI
toolkit, you can try luagnome (bindings to gtk+ and gnome libraries), see
<http://luagnome.free.fr>.
Permalink | Reply | 0 comments |
headers
Andre de Leiradella | 8 Feb 2000 13:37
Picon

Managing states

Is it possible to freeze the execution of a lua program, save its state
and, some time later, restore the saved state and resume execution from
where it stopped?

My idea is to provide a programming environment that makes it easier to
write cgis, freeing the programmer from having to write dozens of
separate programs to implement one system. Instead, the program could
be written all in once, providing the user with data (html) just before
calling the freeze function, and resuming execution after the user
presses the send button, making the program continue just after the
freeze as it nothing had happened, and providing some way to access the
form's parameters.

Of course it will require cookies to store information about the
particular state the user is bound to, but it's no big deal, since
apache has a module that implements this functionality.
Permalink | Reply | 1 comment |
headers
Luiz Henrique de Figueiredo | 8 Feb 2000 16:06
Picon

Re: Managing states

>From lua-l <at> tecgraf.puc-rio.br  Tue Feb  8 10:45:19 2000
>From: "Andre de Leiradella" <andre.leiradella <at> bra.xerox.com>

>Is it possible to freeze the execution of a lua program, save its state
>and, some time later, restore the saved state and resume execution from
>where it stopped?

No.

>My idea is to provide a programming environment that makes it easier to
>write cgis, freeing the programmer from having to write dozens of
>separate programs to implement one system. Instead, the program could
>be written all in once, providing the user with data (html) just before
>calling the freeze function, and resuming execution after the user
>presses the send button, making the program continue just after the
>freeze as it nothing had happened, and providing some way to access the
>form's parameters.

Why not have a single Lua interpreter running "forever" and have CGIs talk
to it?
You'll need some kind of interprocess communication, but it seems to me much
simpler than "freezing" the state of the program.
I think CGILua for Windows does something like this.
--lhf
Permalink | Reply | 0 comments |
headers
Erik Hougaard | 8 Feb 2000 19:00

Re: Managing states

Andre de Leiradella wrote:
> 
> Is it possible to freeze the execution of a lua program, save its state
> and, some time later, restore the saved state and resume execution from
> where it stopped?

Well I have done something like this in uCore. In my Debugger I freeze
(Going into a special Windows message loop waiting for semaphores!) one
state (in the linehook or callhook functions) and then the debugger is
running in another state controlling the debugged state. 

> My idea is to provide a programming environment that makes it easier to
> write cgis, freeing the programmer from having to write dozens of
> separate programs to implement one system. Instead, the program could
> be written all in once, providing the user with data (html) just before
> calling the freeze function, and resuming execution after the user
> presses the send button, making the program continue just after the
> freeze as it nothing had happened, and providing some way to access the
> form's parameters.
> 
> Of course it will require cookies to store information about the
> particular state the user is bound to, but it's no big deal, since
> apache has a module that implements this functionality.

I think it would be better to use a single LUA_T_ARRAY object to hold
all the data for a "cookie session" and then do some XML load/save 'ing
of that object when ever the cookie is requested, I think would make it
more usable!

/Erik
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Tong | 10 Feb 2000 17:28

re: Managing states

---
Is it possible to freeze the execution of a lua program, save its state
and, some time later, restore the saved state and resume execution from
where it stopped?

---

I spent alot of time researching topic this a few weeks back and have
implemented a solution that allows multiple lua programs to run
concurrently while being able to freeze, restart or terminate them at
any point.

The best bang for the buck solution I've found so far is to spawn each
lua invocation in it's own separate thread, and then have a manager
class suspend and wake each lua thread as needed.  That allows you to
neatly avoid many issues with thread syncronization. So far it has
seems to work well and is fairly efficient. I'm using it as the
scripting language for a game title.

What you end up doing is turning a take a bunch of fully multi-tasking
threads and make  them co-operativly multi-task =).

So the manager works like this.

 LuaManager -->
         Runs LuaProgram1 till lua program call waits or time X
         Runs LuaProgram2 ....
         Runs LuaProgram3 ....
         Runs LuaProgram4 ....
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Mathies | 10 Feb 2000 18:13
Favicon

RE: Managing states

This is a single vm / multiple thread solution if I'm reading
your description correctly?

What about a multithreaded version of Lua?  Is that on the horizon?

To get around this myself in Windows, I've been experimenting 
around with compiling the Lua src into a cross platform executable 
format such as elf, and then loading it manually into memory
on a per thread basis.  My application requires a single
Lua lib, one process, multiple threads all executing at the same time.

I like the time slice idea, except - you have to call that suspend callback
to give up control.  If a programmer doesn't do this - well, your
program could lock up or fail.  Plus, performance isn't very good 
if you have say, 10 scripts running at the same time.

Regards,
Jim Mathies

-----Original Message-----
From: Thomas Tong [mailto:toes <at> firestarters.org]
Sent: Thursday, February 10, 2000 8:32 AM
To: Multiple recipients of list
Subject: re: Managing states

---
Is it possible to freeze the execution of a lua program, save its state
and, some time later, restore the saved state and resume execution from
where it stopped?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Hougaard | 10 Feb 2000 18:41

Re: Managing states

----- Original Message -----
From: "Jim Mathies" <jim <at> mathies.com>
To: "Multiple recipients of list" <lua-l <at> tecgraf.puc-rio.br>
Sent: Thursday, February 10, 2000 6:13 PM
Subject: RE: Managing states

> This is a single vm / multiple thread solution if I'm reading
> your description correctly?
>
> What about a multithreaded version of Lua?  Is that on the horizon?
>
> To get around this myself in Windows, I've been experimenting
> around with compiling the Lua src into a cross platform executable
> format such as elf, and then loading it manually into memory
> on a per thread basis.  My application requires a single
> Lua lib, one process, multiple threads all executing at the same time.
>
> I like the time slice idea, except - you have to call that suspend
callback
> to give up control.  If a programmer doesn't do this - well, your
> program could lock up or fail.  Plus, performance isn't very good
> if you have say, 10 scripts running at the same time.
>

I'm using my Multistate Lua (www.hougaard.com/lua/lua32.zip) to have a
multithreaded Windows application. I have a state in each thread!

/Erik
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luiz Henrique de Figueiredo | 10 Feb 2000 19:43
Picon

RE: Managing states

>From lua-l <at> tecgraf.puc-rio.br  Thu Feb 10 15:14:09 2000
>From: Jim Mathies <jim <at> mathies.com>
>
>What about a multithreaded version of Lua?  Is that on the horizon?

Yes, the next version of Lua will be multi-state in the sense that all API
functions will take an explicit state as their first argument.
So, it'll be ready for use in multithreaded applications.
However, how to do multithreading is beyond ANSI C, which is all that our
implementation claims (and wants) to be.
An alpha version should be out soon.
--lhf
Permalink | Reply | 0 comments |
headers
Jim Mathies | 10 Feb 2000 20:14
Favicon

RE: Managing states

Right, but only one thread is in the vm at any point, 
correct?

I have a single process app, with multiple threads
running different Lua scripts.  If two threads enter 
the vm lib (compiled in a dll) at the same time - it 
crashes both.

Does the multistate version of Lua allow for
multiple threads in the same lib at the same time?

Regards,
Jim Mathies

-----Original Message-----
From: erik <at> hougaard.com [mailto:erik <at> hougaard.com]
Sent: Thursday, February 10, 2000 9:44 AM
To: Multiple recipients of list
Subject: Re: Managing states 

----- Original Message -----
From: "Jim Mathies" <jim <at> mathies.com>
To: "Multiple recipients of list" <lua-l <at> tecgraf.puc-rio.br>
Sent: Thursday, February 10, 2000 6:13 PM
Subject: RE: Managing states

> This is a single vm / multiple thread solution if I'm reading
> your description correctly?
>
> What about a multithreaded version of Lua?  Is that on the horizon?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Tong | 10 Feb 2000 22:59

Re: Managing states

Yes and no, each thread has it's own VM since each thread own's it's
own LUA state, and of course it's own callstack.

Since the LUA programs run serially, they don't fumble each other up. 
So it does the following.

LuaManager -->
         Sets LUA state to Program1's --- Runs LuaProgram1   
         Sets LUA state to Program2's --- Runs LuaProgram2   
         Sets LUA state to Program3's --- Runs LuaProgram3   
      etc.

-- Performance and error handling isn't an issue right now.  You
essentially give the LUA thread a certain amount of time to run or give
up control.  If it goes over it's allocated time, it gets killed for
being a bad script, whoever wrote it gets his hand chopped off.
probably me ;) 

Other than the thread switch over-head, putting it together this way
doesn't incur any performance over head.  Even then you can stagger
each script's time slice, so that you don't do 10 thread switchs per
update.  I've load-tested it with 50+ scripts running various tasks in
the background and the time required to switch between them is fairly
insignificant.

Thomas
-------------------------
This is a single vm / multiple thread solution if I'm reading
your description correctly?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane