ANN: luacheia alpha1 release

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

ANN: luacheia alpha1 release

Thatcher Ulrich
luacheia is a full-featured, modular Lua distribution.  The project
homepage is at http://luacheia.lua-users.org

Our first alpha release can be downloaded now. Includes a source
tarball for all platforms, plus a precompiled self-installer for
Windows.

http://prdownloads.sourceforge.net/luacheia/luacheia5-5.0.0a1.tar.gz?download
http://prdownloads.sourceforge.net/luacheia/luacheia5-win32-5.0.0a1.exe?download

Thanks to all the (many many) contributors in the Lua community,
whether you realize you contributed or not!

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

John Belmonte-2
This is looking good and builds without any fuss. I wonder if a few points could be improved:

* support for use of external Lua library. Do you use a stock Lua library compile? This will be significant when packaging for Debian, etc. Also since IUP also contains the Lua source, and you want to make IUP a module, at least one of you will have to concede...

* rewriting wrapper names (for example, SDL.LoadBMP instead of SDL.SDL_LoadBMP)

Regards,
-John


Thatcher Ulrich wrote:
luacheia is a full-featured, modular Lua distribution.  The project
homepage is at http://luacheia.lua-users.org


--
http:// if   l .o  /


Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Peter Loveday-2
>      * support for use of external Lua library.  Do you use a stock Lua
> library compile?  This will be significant when packaging for Debian,
> etc.  Also since IUP also contains the Lua source, and you want to make
> IUP a module, at least one of you will have to concede...

Indeed... the naming issue of DLLs here is still a problem.  There's no
reason for LuaCheia, IUP, etc to work with a 'standard' Lua set of DLLs.  I
will certainly be shipping our own build of them with our application; but
I'm happy to follow standard naming rules to be compatible.

>      * rewriting wrapper names (for example, SDL.LoadBMP instead of
> SDL.SDL_LoadBMP)

Yep, there are a lot of these... the Lua ones got cleaned up when moved to a
"namespace".. but others are just in a table with exactly the same names as
before.  Another one that comes to mind is bitlib... bit.bor etc seem
redundant now.

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software


Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Antonio Scuri
In reply to this post by John Belmonte-2
At 12:09 5/8/2003, you wrote:
This is looking good and builds without any fuss. I wonder if a few points could be improved: * support for use of external Lua library. Do you use a stock Lua library compile? This will be significant when packaging for Debian, etc. Also since IUP also contains the Lua source, and you want to make IUP a module, at least one of you will have to concede...

  Lua is an external library for IUP.

In fact we have a modified Lua 4 inside our code, but we changed all the function names to avoid conflit with the Lua library itself. This code will probably be removed in the future.

[]´s
scuri


Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Thatcher Ulrich
In reply to this post by John Belmonte-2
On Aug 05, 2003 at 11:09 -0400, John Belmonte wrote:
> This is looking good and builds without any fuss.  I wonder if a few 
> points could be improved:
> 
>     * support for use of external Lua library.  Do you use a stock Lua 
> library compile?  This will be significant when packaging for Debian, 
> etc.

Good point.  Currently luacheia always builds its own Lua libraries,
but presumably we can adjust configure.ac so that it can use any
installed Lua5 libraries.  We do have an existing ./configure option
to select an alternate source directory for the Lua distro, but that's
not really the same thing.

We currently make one change to the stock Lua5, which is to extend
"loadlib()" so that it supports dylib's under OSX.  So far none of the
included modules rely on loadlib() so that's not really an obstacle.

Advice/help on packaging is very welcome, especially if you know
something about auto* tools!

> Also since IUP also contains the Lua source, and you want to make
> IUP a module, at least one of you will have to concede...

Agreed.  I imagine a modulized IUP would use the luacheia build
system, and clearly it would need to link to the same Lua libs as the
core.  AFAIK no luacheia developers have looked at this yet.  I did
some wxLua work though so the issues are probably similar.

Note: we would love it if somebody volunteered to adapt IUP as a
module for luacheia!

(Ditto for debugging the wxLua module, adding other modules, etc!)

>     * rewriting wrapper names (for example, SDL.LoadBMP instead of 
> SDL.SDL_LoadBMP)

Yup, noted.  Basically this is up to whoever the module maintainer is.
If it's me, I generally try to change as little as possible, and set
myself up for as little maintenance work as possible, if I'm working
with an existing lib.

In the case of SDL, Asko Kauppi is in charge of the module now.  When
I made a Lua4 wrapper, I used the double namespace because tolua
didn't have an easy way to remove the prefix.  Plus symbols like
SDLK_* would have needed extra attention.

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

SDL package (namespace problem)

Asko Kauppi-3
In reply to this post by John Belmonte-2

I've thought of the SDL namespace problem, and (personally) of the opinion that it should be in the global namespace. That is, SDL_LoadBMP() etc.

Reasons:
	- that's how C (sample) code is written
- if you code for SDL, it's not just a library (among the others) but a main part of your app

Opinions are welcome.


John Belmonte kirjoittaa tiistaina, 5. elokuuta 2003, kello 18:09:

This is looking good and builds without any fuss. I wonder if a few points could be improved:

* support for use of external Lua library. Do you use a stock Lua library compile? This will be significant when packaging for Debian, etc. Also since IUP also contains the Lua source, and you want to make IUP a module, at least one of you will have to concede...

* rewriting wrapper names (for example, SDL.LoadBMP instead of SDL.SDL_LoadBMP)

Regards,
-John


Thatcher Ulrich wrote:
luacheia is a full-featured, modular Lua distribution.  The project
homepage is at http://luacheia.lua-users.org


--
http:// if   l .o  /



Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Peter Loveday-2
My view is that modules should not be allowed to place things in the global
namespace.  Obviously we can't enfore it, but it can be strongly
discouraged.

I think SDL.LoadBMP() is far more consistant with anything else in LuaCheia.
It is a lot more obvoius to a user that a given module has functions within
a given table, and has the added bonus that dumping the contents of that
table gives you a quick list of functions available in the module.

I am not certain that SDL will be a major part of an app that uses it in
scripting...  For example, we don't use SDL in our app at all, and 99% of
scripts will not.  If a given script does then thats fine, but that is a
per-script thing, and to some degree per-use developing the script for our
app.  I can see the similarity to C code being appealing; but we're not
trying to reproduce C, we're trying to make a more consistant manageable
scripting system.

So, in summary, I would definitely vote for SDL.LoadBMP() etc :)

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software


----- Original Message ----- 
From: "Asko Kauppi" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Tuesday, August 05, 2003 1:11 PM
Subject: SDL package (namespace problem)


>
> I've thought of the SDL namespace problem, and (personally) of the
> opinion that it should be in the global namespace. That is,
> SDL_LoadBMP() etc.
>
> Reasons:
> - that's how C (sample) code is written
> - if you code for SDL, it's not just a library (among the others) but
> a main part of your app
>
> Opinions are welcome.
>
>
> John Belmonte kirjoittaa tiistaina, 5. elokuuta 2003, kello 18:09:
>
> > This is looking good and builds without any fuss.  I wonder if a few
> > points could be improved:
> >
> >     * support for use of external Lua library.  Do you use a stock Lua
> > library compile?  This will be significant when packaging for Debian,
> > etc.  Also since IUP also contains the Lua source, and you want to
> > make IUP a module, at least one of you will have to concede...
> >
> >     * rewriting wrapper names (for example, SDL.LoadBMP instead of
> > SDL.SDL_LoadBMP)
> >
> > Regards,
> > -John
> >
> >
> > Thatcher Ulrich wrote:
> >> luacheia is a full-featured, modular Lua distribution.  The project
> >> homepage is at http://luacheia.lua-users.org
> >
> >
> > -- 
> > http:// if   l .o  /
> >
>
>


Reply | Threaded
Open this post in threaded view
|

using LuaCOM and enumarators

Peter Loveday-2
In reply to this post by Thatcher Ulrich
I'm trying to get LuaCOM to work, and having some problems... has anyone had
any success enumerating collections?  For example, I'm trying to get a list
of drives:

    fso = luacom.CreateObject("Scripting.FileSystemObject")
    drives = fso.Drives

This returns a collection object, as expected.  I can index them by name:

    cdrive = drives:Item("C")

But numeric index does not seem to work (and as far as I can see, should do)

    firstdrive = drives:Item(1)

    LuaCOM Exception in file tLuaCOM.cpp at line 661: COM exception: The
parameter is incorrect.
    COM exception: The parameter is incorrect. (file tLuaCOM.cpp, line 661)

I also cannot seem to get a working enumerator object.  How do I do this?
drives:GetEnumerator() doesn't exist, and drives:_GetEnum returns a userdata
object, with nothing I can call.  The metatable for this object seems to
onbly contain "eq" and "gc", and the gc seems to crash...

Is there any way I can actually enumerate a collection, as it is really hard
to do a lot of things without this facility.

Thanks!

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software


Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Thatcher Ulrich
In reply to this post by Peter Loveday-2
On Aug 05, 2003 at 01:17 -0400, Peter Loveday wrote:
> My view is that modules should not be allowed to place things in the global
> namespace.  Obviously we can't enfore it, but it can be strongly
> discouraged.

I agree with this.

> I think SDL.LoadBMP() is far more consistant with anything else in
> LuaCheia.  It is a lot more obvoius to a user that a given module
> has functions within a given table, and has the added bonus that
> dumping the contents of that table gives you a quick list of
> functions available in the module.

Seconded.  I personally don't mind SDL.SDL_LoadBMP(), especially if it
takes some load off the module maintainer, but I agree SDL.LoadBMP()
looks nicer.

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Diego Nehab-3
In reply to this post by Thatcher Ulrich
Hi,

> We currently make one change to the stock Lua5, which is to extend
> "loadlib()" so that it supports dylib's under OSX.  So far none of the
> included modules rely on loadlib() so that's not really an obstacle.

Just out of curiosity, what did you have to change to get loadlib to
work? I am using the dlcompat here and I think it works fine. Except, of
course, for the damn "_" in the beginning of exported function names,
but that can be taken care of in a startup module written in Lua.

[]s,
Diego.


Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Luiz Henrique de Figueiredo
In reply to this post by Asko Kauppi-3
Another advantage of stripping library prefixes in Lua bindings is that it
automatically allows OO syntax, if the library functions always receive a
handle as the first argument. I've exploited this in my libraries for gdbm,
md5, and pdf.

So, for instance, it's much cleaner to write
	d:digest()
than
	d:md5_digest()
or even
	md5_digest(d)

On the other hand, if the Lua binding uses luaL_reg structs to define the
binding names, then it's pretty simple to traverse it and register the
functions as globals with the correct prefix attached. In this way, you
get both options.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Peter Loveday-2
> On the other hand, if the Lua binding uses luaL_reg structs to define the
> binding names, then it's pretty simple to traverse it and register the
> functions as globals with the correct prefix attached. In this way, you
> get both options.

Perhaps some standard means for a library to 'globalise' itself would be
useful for people who like such things?

Kind of along the lines of the compat stuff for Lua4 code, but per-module.
So by default when loading a module, you get it in a namespace, but by using
the module 'globalise' call, you can expose it. Something like:

    cheia.load("SDL")
    SDL:Gobalise()

By default this wopuld simply place any given module into global functions
with it's module prefix (SDL.LoadBMP gets put into SDL_LoadBMP() etc).
However a Module could override this to allow for other behaviour, or adding
some other 'compatibility' stuff (as the compat.lua layer does)

note, I don't think it should actually be called 'globalise' :)


Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software



Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Luiz Henrique de Figueiredo
In reply to this post by Asko Kauppi-3
>Perhaps some standard means for a library to 'globalise' itself would be
>useful for people who like such things?

function globalise(a)
	local t=_G[a]
	for k,v in t do
		_G[a.."_"..k]=v
	end
end

globalise"SDL"

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Martin Spernau
In reply to this post by Thatcher Ulrich

Also since IUP also contains the Lua source, and you want to make
IUP a module, at least one of you will have to concede...

Agreed.  I imagine a modulized IUP would use the luacheia build
system, and clearly it would need to link to the same Lua libs as the
core.  AFAIK no luacheia developers have looked at this yet.  I did
some wxLua work though so the issues are probably similar.
The reason I haven't looked into IUPLua yet is a lack (?) of examples, but maybe I haven't looked hard enough... With wxLua the benefits are instanty visible, it comes with a nice Lua-Editor as default and many nice GUI examples. Maybe some obvious usage-examples of IUP/Lua would be helpfull...

-Martin

Note: we would love it if somebody volunteered to adapt IUP as a
module for luacheia!

(Ditto for debugging the wxLua module, adding other modules, etc!)

* rewriting wrapper names (for example, SDL.LoadBMP instead of SDL.SDL_LoadBMP)

Yup, noted.  Basically this is up to whoever the module maintainer is.
If it's me, I generally try to change as little as possible, and set
myself up for as little maintenance work as possible, if I'm working
with an existing lib.

In the case of SDL, Asko Kauppi is in charge of the module now.  When
I made a Lua4 wrapper, I used the double namespace because tolua
didn't have an easy way to remove the prefix.  Plus symbols like
SDLK_* would have needed extra attention.




Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Thatcher Ulrich
In reply to this post by Diego Nehab-3
On Aug 05, 2003 at 03:25 -0400, Diego Nehab wrote:
> Hi,
> 
> > We currently make one change to the stock Lua5, which is to extend
> > "loadlib()" so that it supports dylib's under OSX.  So far none of the
> > included modules rely on loadlib() so that's not really an obstacle.
> 
> Just out of curiosity, what did you have to change to get loadlib to
> work? I am using the dlcompat here and I think it works fine. Except, of
> course, for the damn "_" in the beginning of exported function names,
> but that can be taken care of in a startup module written in Lua.

I'm not the OSX expert, but I think the reason was so that users
wouldn't have to install dlcompat.

Actually I was remembering wrong; I don't think we change the default
loadlib at all.  However we have a loadlib-derived wrapper for the use
of loadmodule and gluax which are embedded in the luacheia
interpreter.  Here's the wrapper code we use:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/luacheia/luacheia/src/luacheia/loadlib.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

-- 
Thatcher Ulrich
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

Re: using LuaCOM and enumarators

Vinicius da Silva Almendra
In reply to this post by Peter Loveday-2
Hello,

  The collection you are trying to use can't be "indexed" (with Item(n)). 
I tried that in VB and did not work too... The solution is to use the 
enumerator (VB uses it in its for...each...next), but LuaCOM does not 
implement this yet. I'm working on this now in perhaps in the end of the 
week I'll have a working solution.

Best regards,

  Vinicius Almendra
  TeCGraf/PUC-Rio researcher



Original Message
----------------

I'm trying to get LuaCOM to work, and having some problems... has anyone had
any success enumerating collections?  For example, I'm trying to get a list
of drives:

    fso = luacom.CreateObject("Scripting.FileSystemObject")
    drives = fso.Drives

This returns a collection object, as expected.  I can index them by name:

    cdrive = drives:Item("C")

But numeric index does not seem to work (and as far as I can see, should do)

    firstdrive = drives:Item(1)

    LuaCOM Exception in file tLuaCOM.cpp at line 661: COM exception: The
parameter is incorrect.
    COM exception: The parameter is incorrect. (file tLuaCOM.cpp, line 661)

I also cannot seem to get a working enumerator object.  How do I do this?
drives:GetEnumerator() doesn't exist, and drives:_GetEnum returns a userdata
object, with nothing I can call.  The metatable for this object seems to
onbly contain "eq" and "gc", and the gc seems to crash...

Is there any way I can actually enumerate a collection, as it is really hard
to do a lot of things without this facility.

Thanks!

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software


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

Message: 9
Date: Tue, 5 Aug 2003 15:15:47 -0400
From: Thatcher Ulrich <[hidden email]>
Subject: Re: SDL package (namespace problem)
To: Lua list <[hidden email]>
Message-ID: <20030805191547.GD696@...>
Content-Type: text/plain; charset=us-ascii

On Aug 05, 2003 at 01:17 -0400, Peter Loveday wrote:
> My view is that modules should not be allowed to place things in the global
> namespace.  Obviously we can't enfore it, but it can be strongly
> discouraged.

I agree with this.

> I think SDL.LoadBMP() is far more consistant with anything else in
> LuaCheia.  It is a lot more obvoius to a user that a given module
> has functions within a given table, and has the added bonus that
> dumping the contents of that table gives you a quick list of
> functions available in the module.

Seconded.  I personally don't mind SDL.SDL_LoadBMP(), especially if it
takes some load off the module maintainer, but I agree SDL.LoadBMP()
looks nicer.

-- 
Thatcher Ulrich
http://tulrich.com

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

Message: 10
Date: Tue, 5 Aug 2003 15:24:38 -0400 (EDT)
From: Diego Nehab <[hidden email]>
Subject: Re: select implementation for a "file descriptor set"
To: [hidden email]
Message-ID: <Pine.LNX.4.55.0308051523550.30927@...>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

> This is tricky on Windows... certainly you can wait for multiple
> objects such as file I/O, serial, sockets etc; but not with a
> select(), which is only valid for sockets.  This is one area of
> Windows that's a real PITA; the lack of a single signal/messaging
> system for timers, UI events, sockets, asyc I/O, semaphores etc...
> they all have different mechanisms.

Yes, this is why I didn't include a generic select in LuaSocket. I could
even add support for select on Lua file objects but that would only work
on Linux. I might do that in the future.

BTW, in case you are wondering how the Cygwin people implemented select
on Windows... At each call, they actually sort all "file desctiptors"
according to category (socket, file, handle to other stuff etc), spawn
one thread to wait on each category and then combine the results. This
is *not* an option for LuaSocket.

[]s,
Diego.


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

Message: 11
Date: Tue, 5 Aug 2003 15:25:34 -0400 (EDT)
From: Diego Nehab <[hidden email]>
Subject: Re: ANN: luacheia alpha1 release
To: [hidden email]
Message-ID: <Pine.LNX.4.55.0308051524470.30927@...>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

> We currently make one change to the stock Lua5, which is to extend
> "loadlib()" so that it supports dylib's under OSX.  So far none of the
> included modules rely on loadlib() so that's not really an obstacle.

Just out of curiosity, what did you have to change to get loadlib to
work? I am using the dlcompat here and I think it works fine. Except, of
course, for the damn "_" in the beginning of exported function names,
but that can be taken care of in a startup module written in Lua.

[]s,
Diego.


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

Message: 12
Date: Tue, 5 Aug 2003 16:31:54 -0300
From: Luiz Henrique de Figueiredo <[hidden email]>
Subject: Re: SDL package (namespace problem)
To: [hidden email]
Message-ID: <200308051931.QAA10840@...>

Another advantage of stripping library prefixes in Lua bindings is that it
automatically allows OO syntax, if the library functions always receive a
handle as the first argument. I've exploited this in my libraries for gdbm,
md5, and pdf.

So, for instance, it's much cleaner to write
	d:digest()
than
	d:md5_digest()
or even
	md5_digest(d)

On the other hand, if the Lua binding uses luaL_reg structs to define the
binding names, then it's pretty simple to traverse it and register the
functions as globals with the correct prefix attached. In this way, you
get both options.
--lhf

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

Message: 13
Date: Tue, 5 Aug 2003 15:36:56 -0400
From: "Peter Loveday" <[hidden email]>
Subject: Re: SDL package (namespace problem)
To: "Lua list" <[hidden email]>
Message-ID: <007101c35b88$ee39a160$2802a8c0@loveboy>
Content-Type: text/plain;	charset="iso-8859-1"

> On the other hand, if the Lua binding uses luaL_reg structs to define the
> binding names, then it's pretty simple to traverse it and register the
> functions as globals with the correct prefix attached. In this way, you
> get both options.

Perhaps some standard means for a library to 'globalise' itself would be
useful for people who like such things?

Kind of along the lines of the compat stuff for Lua4 code, but per-module.
So by default when loading a module, you get it in a namespace, but by using
the module 'globalise' call, you can expose it. Something like:

    cheia.load("SDL")
    SDL:Gobalise()

By default this wopuld simply place any given module into global functions
with it's module prefix (SDL.LoadBMP gets put into SDL_LoadBMP() etc).
However a Module could override this to allow for other behaviour, or adding
some other 'compatibility' stuff (as the compat.lua layer does)

note, I don't think it should actually be called 'globalise' :)


Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software



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

Message: 14
Date: Tue, 5 Aug 2003 16:41:50 -0300
From: Luiz Henrique de Figueiredo <[hidden email]>
Subject: Re: SDL package (namespace problem)
To: [hidden email]
Message-ID: <200308051941.QAA10880@...>

>Perhaps some standard means for a library to 'globalise' itself would be
>useful for people who like such things?

function globalise(a)
	local t=_G[a]
	for k,v in t do
		_G[a.."_"..k]=v
	end
end

globalise"SDL"

--lhf

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

Message: 15
Date: 05 Aug 2003 22:02:00 +0100
From: [hidden email] (Mark Junker)
Subject: tolua5: problem w. GC and user data
To: [hidden email]
Message-ID: <8rGH5TYe+GB@...>
Content-Type: text/plain; charset=US-ASCII

Hi,

I tested toLua 5 and found a problem. We wanted to use Lua 5 in an embedded  
environment with limited memory. We make extensive use of classes exported to  
Lua as user data. It was no problem to create a pkg file and calling the C++  
class members wasn't a problem at all.

However, the problem I've found was that in the following source, the  
TTestData objects will only be released (deleted from heap memory) when the  
lua_close(L) function is called.

So we ran out of memory when we don't open and close the lua interpreter at  
the beginning and the end of the script execution which is a big perfomance  
problem.

How can I avoid the need to open/close lua?

---------------------------- C++ header ------------------------------
class TTestData {
public:
        unsigned getValue(void) const;
};

class TTest {
public:
        unsigned getCount(void) const;
        TTestData getData(unsigned index) const;

};
---------------------------- C++ header ------------------------------

---------------------------- C++ source ------------------------------
unsigned TTestData::getValue(void) const
{
        return 1234;
}

unsigned TTest::getCount(void) const
{
        return 1234;
}

TTestData TTest::getData(void) const
{
        return TTestData();
}
---------------------------- C++ source ------------------------------

---------------------------- toLua pkg  ------------------------------
class TTestData {
        unsigned getValue(void) const;
};

class TTest {
        unsigned getCount(void) const;
        TTestData getData(unsigned index) const;

};
---------------------------- toLua pkg  ------------------------------

---------------------------- lua script ------------------------------
local count = var:getCount() - 1
for i=0,count do
  local data = var:getData(i);
  print(data.getValue())
end
---------------------------- lua script ------------------------------

Best regards,
Mark Junker

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

Message: 16
Date: Tue, 05 Aug 2003 22:08:16 +0200
From: Martin Spernau <[hidden email]>
Subject: Re: ANN: luacheia alpha1 release
To: Lua list <[hidden email]>
Message-ID: <3F300EB0.3070403@...>
Content-Type: text/plain; charset=us-ascii; format=flowed


>>Also since IUP also contains the Lua source, and you want to make
>>IUP a module, at least one of you will have to concede...
>>    
>>
>
>Agreed.  I imagine a modulized IUP would use the luacheia build
>system, and clearly it would need to link to the same Lua libs as the
>core.  AFAIK no luacheia developers have looked at this yet.  I did
>some wxLua work though so the issues are probably similar.
>  
>
The reason I haven't looked into IUPLua yet is a lack (?) of examples, 
but maybe I haven't looked hard enough...
With wxLua the benefits are instanty visible, it comes with a nice 
Lua-Editor as default and many nice GUI examples. Maybe some obvious 
usage-examples of IUP/Lua would be helpfull...

-Martin

>Note: we would love it if somebody volunteered to adapt IUP as a
>module for luacheia!
>
>(Ditto for debugging the wxLua module, adding other modules, etc!)
>
>  
>
>>    * rewriting wrapper names (for example, SDL.LoadBMP instead of 
>>SDL.SDL_LoadBMP)
>>    
>>
>
>Yup, noted.  Basically this is up to whoever the module maintainer is.
>If it's me, I generally try to change as little as possible, and set
>myself up for as little maintenance work as possible, if I'm working
>with an existing lib.
>
>In the case of SDL, Asko Kauppi is in charge of the module now.  When
>I made a Lua4 wrapper, I used the double namespace because tolua
>didn't have an easy way to remove the prefix.  Plus symbols like
>SDLK_* would have needed extra attention.
>
>  
>



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

Message: 17
Date: Tue, 05 Aug 2003 16:49:52 -0700
From: Ando Sonenblick <[hidden email]>
Subject: "Locking" global variables?
To: Lua list <[hidden email]>
Message-ID: <BB5590B0.E97E%ando@...>
Content-Type: text/plain; charset="US-ASCII"

Gang,

Is there a way in Lua to lock a global variable after initializing it so
that trying to reassign it will fail?

We'd like to prevent inadvertent reassignment of key global variables by
some unaware scriptor...

Thx,
Ando


-----------------
SpriTec Software
www.spritec.com



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

Message: 18
Date: Tue, 5 Aug 2003 17:05:58 -0700
From: "Nick Trout" <[hidden email]>
Subject: RE: What is differential inheritance? An example in Lua,
	Please.
To: "Lua list" <[hidden email]>
Message-ID:
	<911F8C8EB7A8084AAEDD55CEDC54D8F80CB53E@...>
Content-Type: text/plain;	charset="us-ascii"



> From: Vijay Aswadhati [[hidden email]]
> Sent: Saturday, August 02, 2003 9:35 AM
> To: 'Lua list'
> Subject: What is differential inheritance? An example in Lua, Please.
> 
> Steve Dekorte in a posting regarding windowing toolkits
> (Lui) mentioned about using Differential Inheritance if
> he were to rewrite Lui again.
> <http://lua-users.org/lists/lua-l/2003-02/msg00365.html>
> 
> What is it and can anyone provide a good example in Lua
> OR point me to any appropriate links.

I *think* the reason for the comment is that the Yindo's window library
uses inheritance by delegation, which I can see being slower than moving
to a differential system. Inheritance by delegation works by using a
metamethod to search the parent class for a missing field in the local
class instance - in effect looking to see if you inherited a field. I
think if you moved to a differential system (i.e. make small
differential changes to each specialised class) you would aggregate all
of your fields at instance time to avoid doing the search every time you
need to look for an inherited field. 

--nick



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

Message: 19
Date: Tue, 5 Aug 2003 17:54:30 -0700
From: "Nick Trout" <[hidden email]>
Subject: RE: wxLua on OS X?
To: "Lua list" <[hidden email]>
Message-ID:
	<911F8C8EB7A8084AAEDD55CEDC54D8F80CB53F@...>
Content-Type: text/plain;	charset="us-ascii"



> What I am looking for is a toolkit that is totally devoted to GUI and
> nothing else. For example no sockets, no threading and synchronization
> facilities.

But when you are porting, or maintaining, a cross platform application
there are other issues, like threading. So I can see how these become
part of such a code base, although they should probably be a separate
library.

> I have looked at TkLua, wxLua, Lua FLTK, Lui and IUP; none of the
current
> solutions satisfy the requirements I have (in my mind).
> 
> On the wild side, I have been spending some time investigating at
> potential
> candidates that meet the requirements at least from what I have read
about
> them. These are in no particular order:
> 	-- The fox toolkit <http://www.fox-toolkit.org>
> 	-- Java SWT from eclipse project
> <http://www.eclipse.org/articles/index.html>

I had a look for one a while ago as I was trying to write a cross
platform IDE for Lua. Perhaps this would be of interest to you:

	http://lua-users.org/wiki/VisLuaImplementation

When I looked at Fox it wasn't working on as many platforms, or has such
a large useful widget set as WX. Wouldn't SWT require a Java VM install?
Do you mean AWT or SWT - as it's from Eclipse? AWT uses native
non-portable widgets.


> However there is no gaurantee that they will remain so. For example
the
> author of fox toolkit is currently investigating on how to provide a
> HTML browser widget and I am sure any implementation would lead to
adding
> socket support to the library thus making even this toolkit a bit
"fat".
> An ideal marriage would be to find a toolkit that provides absolutely
> bare minimum of GUI abstractions and platform portability and the rest
> gets built using Lua itself. That is why I am leaning towards porting
> SWT to Lua, since only the very low level widget code is written
> in "C" and the rest is written using Java. The trouble is that I am
> still learning Lua and this is not a trivial excercise. And I do not
> want to use "toLua" since that again introduces a dependency.

I've settled on WX and I'll accept its size and shortcoming because it
has such good support, is bound to lots of scripting languages and is so
portable.

--nick


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

Message: 20
Date: Tue, 05 Aug 2003 21:44:53 -0400
From: Peter Shook <[hidden email]>
Subject: Re: "Locking" global variables?
To: Lua list <[hidden email]>
Message-ID: <3F305D95.1020108@...>
Content-Type: text/plain; charset=us-ascii; format=flowed

=== FAQ ===

Ando Sonenblick wrote:
> Gang,
> 
> Is there a way in Lua to lock a global variable after initializing it so
> that trying to reassign it will fail?
> 
> We'd like to prevent inadvertent reassignment of key global variables by
> some unaware scriptor...

If you want to make all globals readonly, see lua-5.0/test/readonly.lua

If you want to make only a few variables readonly, try something like this:

$ cat z.lua

local ReadOnly = {
   x = 5,
   y = 'bob',
   z = false,
}

local function check(tab, name, value)
   if ReadOnly[name] ~= nil then
     error(tostring(name) ..' is a read only variable', 2)
   end
   rawset(tab, name, value)  -- tab[name] = value
end

-- make some global variables readonly
setmetatable(_G, {__index=ReadOnly, __newindex=check})


$ lua -lz -i
 >
 > = x,y,z
5       bob     false
 > x = 44
stdin:1: x is a read only variable
stack traceback:
         [C]: in function `error'
         z.lua:10: in function <z.lua:8>
         stdin:1: in main chunk
         [C]: ?
 > z = 99
stdin:1: z is a read only variable
stack traceback:
         [C]: in function `error'
         z.lua:10: in function <z.lua:8>
         stdin:1: in main chunk
         [C]: ?
 > a,b = 1,2
 > = a,b
1       2
 >


Here are some similar threads:
http://lua-users.org/lists/lua-l/2003-06/msg00362.html
http://lua-users.org/lists/lua-l/2003-07/msg00298.html

- Peter


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

Message: 21
Date: Tue, 5 Aug 2003 22:50:26 -0400
From: Thatcher Ulrich <[hidden email]>
Subject: Re: ANN: luacheia alpha1 release
To: Lua list <[hidden email]>
Message-ID: <20030806025025.GE696@...>
Content-Type: text/plain; charset=us-ascii

On Aug 05, 2003 at 03:25 -0400, Diego Nehab wrote:
> Hi,
> 
> > We currently make one change to the stock Lua5, which is to extend
> > "loadlib()" so that it supports dylib's under OSX.  So far none of the
> > included modules rely on loadlib() so that's not really an obstacle.
> 
> Just out of curiosity, what did you have to change to get loadlib to
> work? I am using the dlcompat here and I think it works fine. Except, of
> course, for the damn "_" in the beginning of exported function names,
> but that can be taken care of in a startup module written in Lua.

I'm not the OSX expert, but I think the reason was so that users
wouldn't have to install dlcompat.

Actually I was remembering wrong; I don't think we change the default
loadlib at all.  However we have a loadlib-derived wrapper for the use
of loadmodule and gluax which are embedded in the luacheia
interpreter.  Here's the wrapper code we use:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/luacheia/luacheia/src/luacheia/loadlib.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

-- 
Thatcher Ulrich
http://tulrich.com

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

Message: 22
Date: Tue, 5 Aug 2003 20:44:20 -0700
From: "Vijay Aswadhati" <[hidden email]>
Subject: RE: wxLua on OS X?
To: "'Lua list'" <[hidden email]>
Message-ID: <00ef01c35bcd$05664e80$6601a8c0@integra04>
Content-Type: text/plain; charset="us-ascii"

<snip/>
> When I looked at Fox it wasn't working on as many platforms, 
> or has such a large useful widget set as WX. 

True. I am not sure if we both looked at it during the same 
time period. Lately, however it does have a very nice set of
widgets; the number of users are slowly growing and finally
the author is doing a great job by way of support offered 
via the newsgroup.

> Wouldn't SWT require a Java  VM install?

Not the way I plan on porting it to Lua. Read on...

> Do you mean AWT or SWT - as it's from Eclipse?

I meant SWT and yes it is from IBM's Eclipse project.

> AWT uses native non-portable widgets.
Hmmm. But I am not planning on porting AWT.

The understanding I have is from looking at the source 
code and by reading articles that talk about the design
and motivation of SWT <http://www.eclipse.org/articles/index.html>

SWT differs significantly from the approach taken by Sun. The
approach taken by the Eclipse team is to split the toolkit
into three layers:
 - Documented platform independent GUI object model (a.k.a SWT)
   that is written in Java. [L1]
   
 - An internal platform specific adaptation layer that is also
   written in Java. [L2]*N Where N is the number of platforms.

 - A native platform specific bridge layer that is written in "C"
   and bridges the internal platform specific Java adaptation layer
   to the OS supported GUI system calls. [L3]*N Where N is the 
   number of platforms.


What I am contemplating on is the following:
 - The native platform specific bridge layer written in "C" looks 
   "very" clean. This layer [L3] needs to be converted to Lua "C".
   Labor intensive yes, but nothing that cannot be mapped to Lua 
   "C" API (as a first approximation). This has to be done for
   all N
   
 - Port the entire Java code [L1] to Lua. This is to be done only
   once.

 - Port the [L2] for all N.


That was the scoop and that also explains my earlier post requesting
a sample for "differential inheritance".

Since Lua is faster than Java (metrics obtained from the "Great Language
Shootout"), I am thinking this should work. But then I could be overlooking
something. However I do believe that having a widget toolkit that was built
for Lua from the ground up would bring in a new wave of fans to Lua just 
as Tcl/Tk (which by the way is my definition of an ideal marriage)
did during its sunshine days.  

Comments and feedback are welcome.

-- Vijay Aswadhati
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2996 bytes
Desc: not available
Url : http://bazar2.conectiva.com.br/mailman/private/lua/attachments/20030805/06206e27/winmail-0001.bin

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

Message: 23
Date: Wed, 06 Aug 2003 20:20:50 +0530
From: "UriBoy b" <[hidden email]>
Subject: how does lua  apply the new configuration to the original
	program?
To: [hidden email]
Cc: [hidden email]
Message-ID: <LONDGOMBJIBPKGAA@...>
Content-Type: text/plain; charset=us-ascii

hi all...

   may i just ask 'how does lua communicate with the original program? i mean, if lua is a configuration languange, and you create a configuration file, how does lua apply the new configuration to the original program it is extending?'
   thanks...


=)



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

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

Message: 24
Date: Wed, 06 Aug 2003 20:20:50 +0530
From: "UriBoy b" <[hidden email]>
Subject: how does lua  apply the new configuration to the original
	program?
To: [hidden email]
Cc: [hidden email]
Message-ID: <LONDGOMBJIBPKGAA@...>
Content-Type: text/plain; charset=us-ascii

hi all...

   may i just ask 'how does lua communicate with the original program? i mean, if lua is a configuration languange, and you create a configuration file, how does lua apply the new configuration to the original program it is extending?'
   thanks...


=)



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

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

Message: 25
Date: Wed, 06 Aug 2003 20:20:50 +0530
From: "UriBoy b" <[hidden email]>
Subject: how does lua  apply the new configuration to the original
	program?
To: [hidden email]
Cc: [hidden email]
Message-ID: <LONDGOMBJIBPKGAA@...>
Content-Type: text/plain; charset=us-ascii

hi all...

   may i just ask 'how does lua communicate with the original program? i mean, if lua is a configuration languange, and you create a configuration file, how does lua apply the new configuration to the original program it is extending?'
   thanks...


=)



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

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

Message: 26
Date: Wed, 06 Aug 2003 11:56:46 -0300
From: Alex Sandro Queiroz e Silva <[hidden email]>
Subject: Re: how does lua  apply the new configuration to the original
	program?
To: Lua list <[hidden email]>
Message-ID: <3F31172E.5000108@...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hallo,

UriBoy b wrote:

>hi all...
>
>   may i just ask 'how does lua communicate with the original program? i mean, if lua is a configuration languange, and you create a configuration file, how does lua apply the new configuration to the original program it is extending?'
>   thanks...
>
>  
>
    Lua does this by calling functions in the C, C++ etc. side of the 
application.

-Alex


End of Lua Digest, Vol 16, Issue 3
~**********************************


Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Mark Stroetzel Glasberg
In reply to this post by Martin Spernau
Martin Spernau wrote:
> The reason I haven't looked into IUPLua yet is a lack (?) of examples,
> but maybe I haven't looked hard enough...

Martin, in the manual you can find examples in Lua of all IUP controls. 

Just go to the Controls section, pick whatever control you would like 
to see working and look at the bottom of its page. You find complete
examples both in C and Lua. 

If you download IUP executable files from Tecgraf's download center,
you should be able to execute all Lua examples found in the manual.

IUP Manual:

  http://www.tecgraf.puc-rio.br/iup

Download:

  http://www.tecgraf.puc-rio.br/download

Regards,
Mark

-- 
|\/|ark Stroetzel Glasberg
[hidden email]

System Analyst
Tecgraf/PUC-Rio
URL:  http://www.tecgraf.puc-rio.br/~mark
Tel:  55 21 2512-5984 ext. 116
Fax:  55 21 2259-2232

Reply | Threaded
Open this post in threaded view
|

Re: ANN: luacheia alpha1 release

Asko Kauppi-3
In reply to this post by Thatcher Ulrich

yes, the reason was to avoid dependency on dlcompat. Whereas it does work fine (and should, basically, be part of OS X in the first place?) it is yet another dependency and we can live better without it. :)

-ak


Thatcher Ulrich kirjoittaa keskiviikkona, 6. elokuuta 2003, kello 05:50:

On Aug 05, 2003 at 03:25 -0400, Diego Nehab wrote:
Hi,

We currently make one change to the stock Lua5, which is to extend
"loadlib()" so that it supports dylib's under OSX. So far none of the
included modules rely on loadlib() so that's not really an obstacle.

Just out of curiosity, what did you have to change to get loadlib to
work? I am using the dlcompat here and I think it works fine. Except, of
course, for the damn "_" in the beginning of exported function names,
but that can be taken care of in a startup module written in Lua.

I'm not the OSX expert, but I think the reason was so that users
wouldn't have to install dlcompat.

Actually I was remembering wrong; I don't think we change the default
loadlib at all.  However we have a loadlib-derived wrapper for the use
of loadmodule and gluax which are embedded in the luacheia
interpreter.  Here's the wrapper code we use:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/luacheia/luacheia/src/ luacheia/loadlib.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

--
Thatcher Ulrich
http://tulrich.com



Reply | Threaded
Open this post in threaded view
|

Re: SDL package (namespace problem)

Asko Kauppi-3
In reply to this post by Peter Loveday-2

it was nice to get much attention to the naming issue.

in fact, i've already started work on 'sdl_wrap.lua' (part of gluax 2.18) that uses the SDL.* notation. However, it does this by redirecting the original (C++) module's function, and enhancing some of them. For compatibility reasons, i keep the 'old stuff' as they are.

In gluax, you can either say USES 'sdl' (for the old interface) or USES 'sdl_new' (for the new one).

Seems like that wrapper should be brought to LuaCheia, too.

-ak

p.s. it is quite possible to enforce not using global namespace. i've done that, with modules that themselves think they're putting stuff to global. Eventually (for apps) it becomes something_else.*


Peter Loveday kirjoittaa tiistaina, 5. elokuuta 2003, kello 20:17:

My view is that modules should not be allowed to place things in the global
namespace.  Obviously we can't enfore it, but it can be strongly
discouraged.

I think SDL.LoadBMP() is far more consistant with anything else in LuaCheia. It is a lot more obvoius to a user that a given module has functions within a given table, and has the added bonus that dumping the contents of that
table gives you a quick list of functions available in the module.

I am not certain that SDL will be a major part of an app that uses it in scripting... For example, we don't use SDL in our app at all, and 99% of scripts will not. If a given script does then thats fine, but that is a per-script thing, and to some degree per-use developing the script for our
app.  I can see the similarity to C code being appealing; but we're not
trying to reproduce C, we're trying to make a more consistant manageable
scripting system.

So, in summary, I would definitely vote for SDL.LoadBMP() etc :)

Love, Light and Peace,
- Peter Loveday
Director of Development, eyeon Software


----- Original Message -----
From: "Asko Kauppi" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Tuesday, August 05, 2003 1:11 PM
Subject: SDL package (namespace problem)



I've thought of the SDL namespace problem, and (personally) of the
opinion that it should be in the global namespace. That is,
SDL_LoadBMP() etc.

Reasons:
- that's how C (sample) code is written
- if you code for SDL, it's not just a library (among the others) but
a main part of your app

Opinions are welcome.


John Belmonte kirjoittaa tiistaina, 5. elokuuta 2003, kello 18:09:

This is looking good and builds without any fuss.  I wonder if a few
points could be improved:

* support for use of external Lua library. Do you use a stock Lua
library compile?  This will be significant when packaging for Debian,
etc.  Also since IUP also contains the Lua source, and you want to
make IUP a module, at least one of you will have to concede...

    * rewriting wrapper names (for example, SDL.LoadBMP instead of
SDL.SDL_LoadBMP)

Regards,
-John


Thatcher Ulrich wrote:
luacheia is a full-featured, modular Lua distribution.  The project
homepage is at http://luacheia.lua-users.org


--
http:// if   l .o  /






Reply | Threaded
Open this post in threaded view
|

evaluatin IupLua [was: Re: ANN: luacheia alpha1 release9

Martin Spernau
In reply to this post by Mark Stroetzel Glasberg
Mark Stroetzel Glasberg wrote:

Martin, in the manual you can find examples in Lua of all IUP controls. Just go to the Controls section, pick whatever control you would like to see working and look at the bottom of its page. You find complete examples both in C and Lua.

Ok, as I said, I didn't look hard enough, big sorry from me...
Those example are definetly nice and answer a lot of questions!
Thanks!

But I'd still like to see one or a few 'complete' examples, say a 'real' application written in Lua/IUP, that actually does something 'usefull' ;) Does someone have such an example? Could that maybe be made availeable to the community? Like on the WiKi or such? That would be really nice. I think many people looking at a 'new' toolkit first have a look at the applications written in it...

Thanks again,
-Martin

If you download IUP executable files from Tecgraf's download center,
you should be able to execute all Lua examples found in the manual.

IUP Manual:

 http://www.tecgraf.puc-rio.br/iup

Download:

 http://www.tecgraf.puc-rio.br/download

Regards,
Mark




12