Re: RES: package system modification (module loaders)

[skaller <skaller@...>]

On Tue, 2005-01-18 at 22:33, duck wrote:
> [package system]
> 
> > The problem left open seems to be how to install
> > C extensions, and packages that need them.
> 
> Could you be a bit more specific? You mean how to build them? How to 
> load them dynamically or statically? Where to stick the files? How to 
> avoid getting the lua part but not the library part? How to handle 
> CPU flavour in a binary distro?

All the above. I had a look at recently posted LuaThreads package ..
but to build it required modifying the Lua sources (via a macro
if I recall).

This is a likely problem for many system packages: sockets,
signals, exceptions, Apache module, blah blah etc ..

> ("Install" as in "copy to a well-known place and be done with
> it" I find easy. That is how I have found Lua to work for me :-)

Not quite so easy for me. The reason is I'm redistributing
Lua as part of my own system. Clients expect the subcomponents
to 'just work' including Lua. By that I mean, without them
having to make any decisions about where to put things.

So my build scripts have to decide that and make sure
Lua can find things.

For example -- to make sure the C level API is available,
I could put it all in a shared library.. but that creates
extra linkage problems, having to find it at link time ..
so I put Lua in my *standard* run time library instead.

I also have to compile the C codes and set macros as
needed to adapt the code to the client's platform.

> > I guess things will get even more difficult in 5.1
> > because of the write barrier, however, probably not
> > as bad as managing ref-counting in Python (which is
> > a nightmare ..)
> 
> What's a "write barrier"? I have heard of (and felt, alas, in a 
> "pedestrian meets bus" incident in Brisbane...boy was that bus in bad 
> shape!) the pain barrier and I have heard of (but not seen or felt)
> the barrier reef. But a write barrier...what you get when a 
> conference paper has snuck up on you, in my book.

LOL! In in the new garbage collector, you cannot store
pointers straight into an object anymore. Instead, you have
to call a subroutine to store a pointer. This subroutine
paints the object black white or grey to indicate its age
(well something like that .. )

This slows things down a bit when moving pointers
about, so that the garbage collector can run much
faster .. at least that's the theory.

If you're calling the C API to do stuff, all this is
handled automatically .. but if you're *extending*
Lua by fiddling with its internals, you have to remember
to the pointer storing routine instead of just using
a C assignment.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net