[ANNOUNCE] bare-bones loadlib

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] bare-bones loadlib

Luiz Henrique de Figueiredo
As proof-of-concept that a bare-bones dynamic library loader for Lua can be
small enough to be included in the standard distribution, I've written a
no-frills version based on the dlfcn interface. It's available at
	ftp://ftp.tecgraf.puc-rio.br/pub/lhf/loadlib.tar.gz

The tarball also includes an untested version for Windows and dlfcn emulation
for HPUX 10.

The purpose of this annoucement is to get as much feedback as possible,
specially reports of other systems that have dlfcn, ideally testing this
package, *simple* implementations along the same lines of loadlib.c for
systems that don't have dlfcn, and testing the Windows version.

Please send comments, suggestions, and bug reports directly to me.
Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Edgar Toernig
Just my 2 cent:

 - The API should be like that of loadfile: accept a string and return
   a function.  loadlib itself should only load the lib, not execute it.

 - It should perform some sanity checks like lua_undump (same Lua
   version; same number type; ...).

 - It should be possible to loadlib the same file multiple times.  Works
   with dl_open (has a ref-count).  The lib should assume that all
   loaded instances share the same static data/bss.

 - Unloading should be done by the GC.  It's easy to implement and
   requires only minimal support from the Lua core.

 - The same source file should be useable as a builtin library or as a
   dynamic library without any changes.  The build system should decide
   what to generate and the source file should adapt to that.

 - An API to access builtin libraries in the same way as dynamic ones.
   The best way would be that lua_loadfile (or a lua_load) handles all
   four cases:
    - Lua source file
    - Lua precompiled binary
    - Builtin C library
    - Dynamic C library
   That way the application does not have to care how some code has
   been implemented.  (not sure about the search order though...)

 - The currently included libraries (strlib, iolib, ...) should be
   converted to this scheme.

 - There should be a unique directory separator.  It would be ugly
   if one had to convert all
     require"lua/strings"
   to
     require"lua\\strings"
   and vice versa when moving some files to another system.  (I.e.
   like C, always use '/').

 - Similar for file name extensions.  If a dynamic loader requires
   a specific extensions (i.e. ".dll") the loader should append that
   by itself.

IMHO, creating such an infrastructure is much more important than the
actual implementation of the low level dynamic loader.  That seems to
be relatively easy on todays OSs...

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>Just my 2 cent:

Thanks for your input. Let me start from the end:

>IMHO, creating such an infrastructure is much more important than the
>actual implementation of the low level dynamic loader.  That seems to
>be relatively easy on todays OSs...

Right. My intention is exactly to try to establish that it is easy to
write a low level dynamic loader for todays OSs. It seems that most unixes
now support dlfcn. I'd like to hear about this, that is, about unixes that
do and that don't support dlfcn, and also about other OSs (Windows, Palm,
Macintosh, Mac OS X, Acorn RISC OS, EPOC, BeOS, OS/2, ...).

Once we have established that a low level dynamic loader either exists
or can be easily written, then we can move on to discuss a more convenient
user interface. As a writer of core tools, I'll then step down and let the
community take over.

> - The API should be like that of loadfile: accept a string and return
>   a function.  loadlib itself should only load the lib, not execute it.

I don't really see why this would be more flexible. In the scheme I have in
mind, the init function that is called when the library is loaded does all
the work, typically registering functions in Lua. Why would you want to load
a library and not init it? In any case, this is pretty easy to implement too,
if it proves to be useful.

> - It should perform some sanity checks like lua_undump (same Lua
>   version; same number type; ...).

I don't see how it can do this. All this info is in lua.h, but how can we
make sure that the library has been compiled with the same lua.h as the
Lua client that is loadling it? The info is not available at runtime.
Perhaps it should. Just to be clear: even without messing with dynamic
libraries, there is today no way to tell whether a library say in object
format is compatible with a given Lua installation. Or is there?

> - It should be possible to loadlib the same file multiple times.  Works
>   with dl_open (has a ref-count).  The lib should assume that all
>   loaded instances share the same static data/bss.

If so, then the init function can keep track of whether it has been called.
On the other hand, you might want to call init again, using a different
Lua state.

> - Unloading should be done by the GC.  It's easy to implement and
>   requires only minimal support from the Lua core.

Yes, this is in my TODO list. A general technique for registering clean-up
functions to be called when a state is closed is to add a userdata to
the registry and set a GC tag method for it; this function will be called
when the state is closed. Perhaps something similar could be done for
handling GC at other times, though I can't think of anything right now.

> - There should be a unique directory separator.  It would be ugly

This, and how to specify file name extensions and separator for lists of
directories to try is plainly the job of the smart user interface to loadlib.
Perhaps we should call the bare bones version _loadlib...

Here is a minimal implementation for the smart version:

 local _loadlib=loadlib

 function loadlib(lib,init,path,del)
  local i,j=nil,0
  local pat="(.-)"..del
  init = init or lib.."_start"
  local a
  path=path..del
  while 1 do
   local p
   i,j,p=strfind(path,pat,j+1) 
   if i==nil then break end
   p=p..del..lib..".so"
   a={_loadlib(p,init)}
   if a[1]~=nil then myfunc() return unpack(a) end
  end
  return nil
 end

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Edgar Toernig
Luiz Henrique de Figueiredo wrote:
> 
> I'd like to hear about this, that is, about unixes that
> do and that don't support dlfcn, and also about other OSs (Windows, Palm,
> Macintosh, Mac OS X, Acorn RISC OS, EPOC, BeOS, OS/2, ...).

You'll allways find a system that will not support it or where is really
hard.  But does it matter?  The worst thing would be that this system
will not have dynamic loader support.  That's all.  Just give them
a place where they can plug in their dyn-loader routines.

>... I'll then step down and let the community take over.

I take that as a joke *sg*

> > - The API should be like that of loadfile: accept a string and return
> >   a function.  loadlib itself should only load the lib, not execute it.
> 
> I don't really see why this would be more flexible. In the scheme I have in
> mind, the init function that is called when the library is loaded does all
> the work, typically registering functions in Lua. Why would you want to load
> a library and not init it? In any case, this is pretty easy to implement too,
> if it proves to be useful.

For the same reason there's now a lua_loadfile.  A dynamic loaded binary
mustn't be some kind of library with predefined behaviour.  Why make it
different to regular lua files when you can make them look 100% the same?

> > - It should perform some sanity checks like lua_undump (same Lua
> >   version; same number type; ...).
> 
> I don't see how it can do this.

Look at Sol.  A library has this statement:

	SOL_DYNLIB(startfunc);

somewhere in the file.  SOL_DYNLIB is a macro that creates a global
structure with a fixed name initialized with all the stuff you need
to check API incompatibilities and with startfunc.  The loader looks
for this structure, does the tests and returns a cclosure of startfunc.

And when the file is statically linked into Lua the macro would expand
to something different (that's not in Sol).

> > - Unloading should be done by the GC.  It's easy to implement and
> >   requires only minimal support from the Lua core.
> 
> Yes, this is in my TODO list. A general technique for registering clean-up
> functions to be called when a state is closed is to add a userdata to
> the registry and set a GC tag method for it; this function will be called
> when the state is closed.

I meant real garbage collection.  If there's no reference to the dynamic
binary it should be unloaded.  Because the only thing it can export are
functions that's not that difficult.

At the start you only have the startfunc.  All future pushcclosure with
a function from that binary has to be from startfunc or from some function
created by it.  And so on.

So, if one could keep track of a "function creation history" you can
detect when a dynamic binary is no longer in use.  Luckily that's easy *g*
You just keep a reference to the binary in the upvalues:

 - the change to Lua's core: lua_pushcclosure always appends the last
   upvalue of the currently active cclosure to the new cclosure (or nil
   if there is no active cclosure).

 - loadlib creates a userdata containing the handle for that binary.
   A GC call of the userdata will unload the binary.

 - loadlib attaches that userdata as the single upvalue for the created
   cclosure of startfunc.  (Needs a special pushcclosure or a magic
   nupvalue so that lua_pushcclosure will not do its append stuff.)

That's all.  Automatic garbage collection of dynamic loaded binaries.

> > - There should be a unique directory separator.  It would be ugly
> 
> This, and how to specify file name extensions and separator for lists of
> directories to try is plainly the job of the smart user interface to loadlib.

And you get another system dependant place to take care of.

As I said: I think the infrastructure is _much_ more important than the
actual implementation of the low level loader.

> Perhaps we should call the bare bones version _loadlib...

Who wants a _loadlib?  People want a load"some/file" without bothering
whether it's a source, precompiled, builtin or dynamic file.  You don't
make the difference visible for precompiled Lua files.  Why for pre-
compiled C files?  The Lua app won't see a difference anyway.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

lua_error() during GC?

Gambit
All -

What happens if I call lua_error() from my C GC handler for my user data?
-G


Reply | Threaded
Open this post in threaded view
|

Re[2]: [ANNOUNCE] bare-bones loadlib

Denis Andreev
In reply to this post by Edgar Toernig
ET> Just my 2 cent:
ET>  - The API should be like that of loadfile: accept a string and return
ET>    a function.  loadlib itself should only load the lib, not execute it.

I prefer get table with library contents rather than usless function.

For example:

strlib = loadlibrary("strlib")
m = strlib.format("%02d", 13)
--...

Or

tklua, message = loadlibrary("tklua")
assert(tklua, format("library tklua loading fail with error: %s", message))
label = tklua.tklabel{}
using(tklua)
name = tkentry{}
--...

This may resolve namespace collisions.

--Denq


Reply | Threaded
Open this post in threaded view
|

Re: lua_error() during GC?

Roberto Ierusalimschy
In reply to this post by Gambit
> What happens if I call lua_error() from my C GC handler for my user data?

Nasty things ;-)  Don't do that.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

James Hearn
In reply to this post by Luiz Henrique de Figueiredo
On a small note, the Windows example code compiled out of the box on my
cygwin machine. It took a little mucking about in the Makefile. I'm going to
mess with it some more and see what I come up with.

--James Hearn


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Eric Tetz-2
--- James Hearn <[hidden email]> wrote:
> On a small note, the Windows example code compiled out of the box on my
> cygwin machine. It took a little mucking about in the Makefile. I'm going to
> mess with it some more and see what I come up with.

I'm assuming that this whole dynamic loading business assumes that Lua itself is dynamically
loaded by the host app.  I don't know about Unix, but under Windows there would be no other way
for the host and library to share Lua's code. Unless the host did something like pass the library
a table of function pointers, or something like that.  Right?

Cheers,
Eric

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

James Hearn
> --- James Hearn <[hidden email]> wrote:
> > On a small note, the Windows example code compiled out of the box on my
> > cygwin machine. It took a little mucking about in the Makefile. I'm
going to
> > mess with it some more and see what I come up with.
>
> I'm assuming that this whole dynamic loading business assumes that Lua
itself is dynamically
> loaded by the host app.  I don't know about Unix, but under Windows there
would be no other way
> for the host and library to share Lua's code. Unless the host did
something like pass the library
> a table of function pointers, or something like that.  Right?

Let me preface this that I'm not very familiar with the specifics of how
dynamic loading works, and I'm fumbling my way through manuals, compiles,
and trial and error to figure this one out. I'm primarily a Unix coder - I'm
on a Windows box here right now with Visual Studio 6, but I work mostly with
the Cygwin tools and the Sun java compiler. A lot of my confusion comes from
my rudimentary understanding of the interactions between Cygwin and Windows.
Cygwin causes things to "just work" like I expect them to, but its "unix
compatibility layer" is everywhere.

What I got running was a really basic hack of the makefile. I'm pretty sure
it depended heavily on the unix compatibility layer. It definitely required
cygwin1.dll . It compiled lua.c into one program, statically pulling in
liblua and liblualib. Oh yes, I'm using Lua 4.1w4 for all of this.

The next step was to compile 'mylib' into a .dll . For some reason ld was
not happy when I tried to create shared code with it (this is where I
started mucking about). It gave lots of errors relating to undefined
references. After hunting through the manual a bit, a found that

mylib.dll: mylib.o
    dlltool mylib.o -e mylib.exp -l mylib.a -z mylib.def
    gcc -o $@ -shared $? mylib.exp mylib.a mylib.def -L$(LUALIB) -llua

produced a ".dll" that could be loaded dynamically from the test program.
You'll notice that liblua is statically compiled into the ".dll" . I say
".dll" because I'm not entirely convinced that it is a windows .dll proper.
I think it probably depends heavily on the cygwin unix compatibility layer.

Right this minute I'm working on compiling a completely native dynamically
loaded version of Lua and the loadlib test program using the cygwin
toolchain. I'm making progress. Wish me luck!

--James Hearn, who is learning a lot about this in the process...




Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Gambit
Not to be disrespectful of the progress you've made, James, but traditionally most programs will package VC++ makefiles/project files with the project. Cygwin, as you're finding out, is an absolute bastard of a dependency to have, and should be avoided /as a requirement/ imho at all costs. Anyone who's doing serious, or even mildly serious windows development, will be doing it in VC++.

VC++ does, fortunately, support exporting of a .mak file which can be built from the command line. I suggest that as a less troublesome and more dependency-free version. Alternately, you can support a natively compiled gmake. I strongly suspect that gcc will build under windows as well, but I haven't looked at it in a long time.

If you have any questions about makefiles or building under windows, feel free to email me.
-G

At 02:32 PM 3/22/2002 -0600, you wrote:
> --- James Hearn <[hidden email]> wrote:
> > On a small note, the Windows example code compiled out of the box on my
> > cygwin machine. It took a little mucking about in the Makefile. I'm
going to
> > mess with it some more and see what I come up with.
>
> I'm assuming that this whole dynamic loading business assumes that Lua
itself is dynamically
> loaded by the host app.  I don't know about Unix, but under Windows there
would be no other way
> for the host and library to share Lua's code. Unless the host did
something like pass the library
> a table of function pointers, or something like that.  Right?

Let me preface this that I'm not very familiar with the specifics of how
dynamic loading works, and I'm fumbling my way through manuals, compiles,
and trial and error to figure this one out. I'm primarily a Unix coder - I'm
on a Windows box here right now with Visual Studio 6, but I work mostly with
the Cygwin tools and the Sun java compiler. A lot of my confusion comes from
my rudimentary understanding of the interactions between Cygwin and Windows.
Cygwin causes things to "just work" like I expect them to, but its "unix
compatibility layer" is everywhere.

What I got running was a really basic hack of the makefile. I'm pretty sure
it depended heavily on the unix compatibility layer. It definitely required
cygwin1.dll . It compiled lua.c into one program, statically pulling in
liblua and liblualib. Oh yes, I'm using Lua 4.1w4 for all of this.

The next step was to compile 'mylib' into a .dll . For some reason ld was
not happy when I tried to create shared code with it (this is where I
started mucking about). It gave lots of errors relating to undefined
references. After hunting through the manual a bit, a found that

mylib.dll: mylib.o
    dlltool mylib.o -e mylib.exp -l mylib.a -z mylib.def
    gcc -o $@ -shared $? mylib.exp mylib.a mylib.def -L$(LUALIB) -llua

produced a ".dll" that could be loaded dynamically from the test program.
You'll notice that liblua is statically compiled into the ".dll" . I say
".dll" because I'm not entirely convinced that it is a windows .dll proper.
I think it probably depends heavily on the cygwin unix compatibility layer.

Right this minute I'm working on compiling a completely native dynamically
loaded version of Lua and the loadlib test program using the cygwin
toolchain. I'm making progress. Wish me luck!

--James Hearn, who is learning a lot about this in the process...


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

Eric Tetz-2
In reply to this post by James Hearn
--- James Hearn <[hidden email]> wrote:
> Right this minute I'm working on compiling a completely native
> dynamically loaded version of Lua and the loadlib test program using the
> cygwin toolchain. I'm making progress. Wish me luck!

Just for contrast, this is all easy to do with Borland C++ 5.5 (free).
>From the root of the Lua distribution:

(1) Build lua.dll (containing Lua API and libraries):

  bcc32 -elua.dll -Iinclude -DLUA_API=__declspec(dllexport) \
  -DLUALIB_API=__declspec(dllexport) -tWD src/*.c src/lib/*.c

(2) Create an import library fo lua.dll:

  implib lua.lib lua.dll

(3) Create a version of lua.exe that gets Lua from lua.dll:

  bcc32 -elua.exe -Iinclude -DLUA_API=__declspec(dllimport) \
  -DLUALIB_API=__declspec(dllimport) lua.lib src/lua/*.c

---------------------------------------------------------------------------

To try out the loadlib stuff: extract the 'loadlib' files to a directory
named 'loadlib' (in the root of the Lua distro), then rebuild lua.dll with
'loadlib\etc\windows.c' added:

  bcc32 -elua.dll -Iinclude -DLUA_API=__declspec(dllexport) \
  -DLUALIB_API=__declspec(dllexport) -tWD src/*.c src/lib/*.c \
  loadlib/etc/windows.c

Rebuild lua.exe - add 'lua_loadlibopen(l);' to openstdlibs in lua.c, then
repeate steps (2) and (3) above.

Build mylib.dll. mylib.c does not export mylib_start; you must add
__declspec(dllexport) before that name before you build.  Then, to build:

  bcc32 -Iinclude -DLUA_API=__declspec(dllimport) -tWD lua.lib \
  loadlib\mylib.c

That's it. You can run 'lua loadlib\test.lua'. Output: 'Hello from mylib'.

On complication: Borland C++ mangles the names __cdecl functions by
prepending an underscore. This means mylib.dll will actually export
_mylib_start instead of mylib_start.  You can either change test.lua to run
'_mylib_start', or create a module definition file for mylib.dll that maps
the exported symbol to the appropriate name.

mylib.def: EXPORTS mylib_start = _mylib_start

Cheers, Eric

P.S. In case that's a confusing jumble. Here's the short version of
building the Windows loadlib example with Borland C++ 5.5 (with the Lua
4.1 work 4):

Extract the 'loadlib' tarball into '(lua distro root)\loadlib', then..

Code changes: 

(1) Add the following line to include\lualib.h

  LUALIB_API int lua_loadlibopen (lua_State *L);

(2) Add the following line to src\lua\lua.c : 'openstdlibs'

  lua_loadlibopen(l);

(3) Change the 'mylib_start' line in loadlib\mylib.c to:

  __declspec(dllexport) int mylib_start(lua_State *L)

(4) Change the 'loadlib' line in loadlib\test.lua to:

  assert(loadlib(D.."\\mylib.dll","_mylib_start"))

(5) Build everything:

  bcc32 -elua.dll -Iinclude -DLUA_API=__declspec(dllexport) \
  -DLUALIB_API=__declspec(dllexport) -tWD src/*.c src/lib/*.c
  loadlib/etc/windows.c
  implib lua.lib lua.dll
  bcc32 -elua.exe -Iinclude -DLUA_API=__declspec(dllimport) \
  -DLUALIB_API=__declspec(dllimport) lua.lib src/lua/*.c
  bcc32 -Iinclude -DLUA_API=__declspec(dllimport) -tWD lua.lib \
  loadlib\mylib.c


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] bare-bones loadlib

sessil
At 03:14 PM 3/22/2002 -0800, Eric Tetz <[hidden email]> wrote:
>--- James Hearn <[hidden email]> wrote:
>> Right this minute I'm working on compiling a completely native
>> dynamically loaded version of Lua and the loadlib test program using the
>> cygwin toolchain. I'm making progress. Wish me luck!
>
>Just for contrast, this is all easy to do with Borland C++ 5.5 (free).
>From the root of the Lua distribution:

<snip bcc32 build of lua.dll with and without loadlib support>

Modifying Eric's procedure to work with 'gcc version 2.95.3-5 (cygwin
special)' resulted in the following steps (well, it works for the example
at least):

>Extract the 'loadlib' tarball into '(lua distro root)\loadlib', then..
>
>Code changes:
>
>(1) Add the following line to include\lualib.h
>
>  LUALIB_API int lua_loadlibopen (lua_State *L);
>
>(2) Add the following line to src\lua\lua.c : 'openstdlibs'
>
>  lua_loadlibopen(l);

(3) There is no step (3)!

>(4) Change the 'loadlib' line in loadlib\test.lua to:

assert(loadlib(D.."/mylib.dll","mylib_start"))

>(5) Build everything:

gcc -mno-cygwin -shared -o lua.dll -I./include src/*.c \
src/lib/*.c loadlib/etc/windows.c

gcc -mno-cygwin -o lua.exe -I./include -L. -llua src/lua/*.c

gcc -mno-cygwin -shared -o mylib.dll -I./include -L. -llua \
loadlib/mylib.c

(6) Run it from Windows command prompt (no cygwin1.dll in PATH!):

  C:\lua-4.1-work4dll\lua.exe loadlib\test.lua
  Hello from mylib

Regards,
Dean.

Reply | Threaded
Open this post in threaded view
|

[ANNOUNCE] LuaIDE 1.0 release

Tristan Rybak-2
In reply to this post by Luiz Henrique de Figueiredo
It's integrated environment for developing applications in lua. It's free
for commercial and non-commercial use.

Features:
- Support for Lua 5.0 work1
- Project management
- Multi document interface, printer support
- Output window for build/debug messages (jump to error when clicked)
- Debugger (Go, Step into, Step over, Step out and Run to cursor commands)
- Breakpoints
- Callstack trace window (jump to any stack level during execution)
- Locals trace window (shows local variables in current stack level)
- Watch window (evaluate user expressions in current stack level)
- API for dynamically loaded extensions for lua (sources for standard
library extension and skeleton for new extensions)

Environment is very similar to that used in Microsoft's Visual Studio. As
now there is only version for Windows.
Editor uses scintilla edit control.
To do your own extensions look at sources for standard library. There is
also skeleton project, just fill it and you have new extension.
Download it from http://www.gorlice.net.pl/~rybak/luaide/LuaIDE.zip
send any comments, bugs to Tristan Rybak <[hidden email]>

Tristan Rybak


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] LuaIDE 1.0 release

Tristan Rybak-2
I forgot to add that there is a small LuaIDE homepage at
http://www.gorlice.net.pl/~rybak/luaide

Tristan


Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] LuaIDE 1.0 release

Danilo Tuler de Oliveira
In reply to this post by Tristan Rybak-2
> - Support for Lua 5.0 work1

Do you have a Lua 4.0 version?

Thanks,
-- Danilo

ah, nice job.



Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] LuaIDE 1.0 release

Jim Mathies-2
In reply to this post by Tristan Rybak-2
wow. very nice. thank you.

----- Original Message -----
From: "Tristan Rybak" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, July 03, 2002 4:16 AM
Subject: [ANNOUNCE] LuaIDE 1.0 release


> It's integrated environment for developing applications in lua. It's free
> for commercial and non-commercial use.
>
> Features:
> - Support for Lua 5.0 work1
> - Project management
> - Multi document interface, printer support
> - Output window for build/debug messages (jump to error when clicked)
> - Debugger (Go, Step into, Step over, Step out and Run to cursor commands)
> - Breakpoints
> - Callstack trace window (jump to any stack level during execution)
> - Locals trace window (shows local variables in current stack level)
> - Watch window (evaluate user expressions in current stack level)
> - API for dynamically loaded extensions for lua (sources for standard
> library extension and skeleton for new extensions)
>
> Environment is very similar to that used in Microsoft's Visual Studio. As
> now there is only version for Windows.
> Editor uses scintilla edit control.
> To do your own extensions look at sources for standard library. There is
> also skeleton project, just fill it and you have new extension.
> Download it from http://www.gorlice.net.pl/~rybak/luaide/LuaIDE.zip
> send any comments, bugs to Tristan Rybak <[hidden email]>
>
> Tristan Rybak
>
>
>


Reply | Threaded
Open this post in threaded view
|

NULL user data ...

Alex Bilyk
I must be missing something but it appears LUA doesn't handle properly user
data that is (void*)NULL with a custom tag. Is this the case indeed?

On my application user data when some of it was represented by (void*)NULL
the "gc" event handler recieves some bogus pointers causing the app to
crash. I had to change my NULL user data  to have ANYTAG instead of my
object tag in order to avoid crashes in "gc" handler for that object tag.

What am I missing here?

Thanks,
AB


Reply | Threaded
Open this post in threaded view
|

Re: NULL user data ...

Enrico Colombini
>I must be missing something but it appears LUA doesn't handle properly user
>data that is (void*)NULL with a custom tag. Is this the case indeed?

I I understood correctly, it's a known bug of Lua 4.0 (I ran into it, too).

By the way, is there a place where the Lua 4.01 source could be downloaded?

  Enrico

Reply | Threaded
Open this post in threaded view
|

Re: NULL user data ...

Erik Hougaard
----- Original Message -----
From: "Enrico Colombini" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Thursday, July 04, 2002 10:03 AM
Subject: Re: NULL user data ...


> >I must be missing something but it appears LUA doesn't handle properly
user
> >data that is (void*)NULL with a custom tag. Is this the case indeed?
>
> I I understood correctly, it's a known bug of Lua 4.0 (I ran into it,
too).
>
> By the way, is there a place where the Lua 4.01 source could be
downloaded?
>
>   Enrico

The 4..0.1 is called 4.0-update and should be found on every mirror (You can
find it on my mirror ftp://ftp.hougaard.com/lua/dist/ )

/e


12