debian: no lua.h?

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

debian: no lua.h?

chris.danx
Hi,

I just installed lua on a debian sid system to start playing again, getting lua50 and lua50-doc, but it didn't come with lua.h or if it did it can't be found. Has anyone else installed the deb and if so did you have the same problem?

I don't use C regularly and am only playing with lua in C to get a feel for it, until I can bind to it, so perhaps I'm doing something wrong?


#include <stdio.h>
#include <lua.h>

int main (void)
{
    char line[BUFSIZ];
    lua_State *L = lua_open(0);
    ...
}


Cheers,
Chris


Reply | Threaded
Open this post in threaded view
|

Re: debian: no lua.h?

Daniel Silverstone
On Fri, 2003-09-12 at 15:41, chris.danx wrote:
> I just installed lua on a debian sid system to start playing again, 
> getting lua50 and lua50-doc, but it didn't come with lua.h or if it did 
> it can't be found.  Has anyone else installed the deb and if so did you 
> have the same problem?

You need to install the liblua50-dev and liblualib50-dev packages --
they are the development packages and will install the headers into
/usr/include/lua50/

D.
(I am the Debian package maintainer for Lua ;-)

-- 
Daniel Silverstone                       http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler: Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org       KeyId: 20687895



Reply | Threaded
Open this post in threaded view
|

debian: no lua.h?

Basile STARYNKEVITCH
In reply to this post by chris.danx
>>>>> "chris" == chris danx <[hidden email]> writes:

    chris> Hi, I just installed lua on a debian sid system to start
    chris> playing again, getting lua50 and lua50-doc, but it didn't
    chris> come with lua.h or if it did it can't be found.  Has anyone
    chris> else installed the deb and if so did you have the same
    chris> problem?


On Debian/Sid (aka unstable) at least you also need the liblua50-dev
and liblua50 packages.



-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Reply | Threaded
Open this post in threaded view
|

Re: debian: no lua.h?

chris.danx
In reply to this post by Daniel Silverstone
Daniel Silverstone wrote:
On Fri, 2003-09-12 at 15:41, chris.danx wrote:

You need to install the liblua50-dev and liblualib50-dev packages --
they are the development packages and will install the headers into
/usr/include/lua50/

Ah right.  Thanks.

Are they recommended by the package? I installed it but didn't think to look at the recommended packages.

How can I set the compiler to look for the header files in /usr/include/lua50 or include it?

D.
(I am the Debian package maintainer for Lua ;-)

Yeah, saw your name in the manpage and thought you might subscribe here.


Thanks again,
Chris


Reply | Threaded
Open this post in threaded view
|

Lua memory usage for games console

Stuart Middleton
In reply to this post by Basile STARYNKEVITCH
 Hi All,

We are currently evaluating lua as a replacement for our internal scripting
attempt. My initial evaluation (only 1 day) shows that each loaded script
uses a load of memory.

i.e.

xpos = 20.423987987234
ypos = 30.923874982343
zpos = 40.982374982734

function GetAllPos()
	return xpos+ypos+zpos;
end

function GetXPos()
	return xpos;
end

function GetYPos()
	return ypos;
end

function GetZPos()
	return zpos;
end

which is pitifully small (and does nothing useful) uses 822 bytes of memory.
I am using precompiled scripts with the debug info stripped. This memory
does not included the mem used to load the script in the first place.

As far as I can see its because of the over bloated structures inside lua.
For instance GCObject uses 72 bytes just because it's a union of common
types one of which being Proto which is 72 bytes long. So at a guess each
variable will be at least 72 bytes long?

Before I go rewriting how lua handles its internal structures or give up on
it completely I wondered if anyone out there has reworked the system to use
minimal memory.

As comparison a simple test script like this in our system would use about
250 bytes with new instances of the same script using < 100 bytes.

Any help would be much appreciated.

While I'm at it I have another question.
We will need to load multiple scripts, hundreds in fact, most of which would
be copies of each other. They all need to maintain their own global (or file
local) variables. Has anyone done this before? I guessed you would use
either the threading system or a new state for each (we are not
multi-threaded) but the overhead for a new system or even a new thread each
time is a bit over the top. Also our internal system was written so we could
load a script once and create instances of it with new variables but pointer
to the functions in just 1 copy of the byte code.

Any idea's

Hope you can help

Stuart Middleton (lua newbie)




Reply | Threaded
Open this post in threaded view
|

Re: Lua memory usage for games console

Roberto Ierusalimschy
> As far as I can see its because of the over bloated structures inside lua.
> For instance GCObject uses 72 bytes just because it's a union of common
> types one of which being Proto which is 72 bytes long.

Lua never allocates an object of this type. Each paticular type inside
this union uses exactly its own size. The union is only a polite way to
declare a pointer that can point to any of these structures.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Lua 5 vs Lua 4

Brian Weed-2
Can someone point me to information about what happened to the following :

LUA_ERRORMESSAGE
lua_pushuserdata
lua_getglobals
lua_rawcall

and alternatives that I should use instead.

Also, has anyone successfully used Lua 5 on the Mac (specifically Carbon) or
know of any caveats?

Brian Weed
Senior Software Architect
ImaginEngine Corp.


Reply | Threaded
Open this post in threaded view
|

Re: debian: no lua.h?

Daniel Silverstone
In reply to this post by chris.danx
On Fri, 2003-09-12 at 16:55, chris.danx wrote:
> > You need to install the liblua50-dev and liblualib50-dev packages --
> > they are the development packages and will install the headers into
> > /usr/include/lua50/
> Ah right.  Thanks.
> Are they recommended by the package?  I installed it but didn't think to 
> look at the recommended packages.

I don't believe so. It's rare for library packages to recommend their
-dev variants.

> How can I set the compiler to look for the header files in 
> /usr/include/lua50 or include it?

I tend to #include <lua50/lua.h> but you can just do #include <lua.h>
and then stick -I/usr/include/lua50 on the commandline.

Also, consider looking at lua-config50 which is a tool liblua50-dev
installs.

> > D.
> > (I am the Debian package maintainer for Lua ;-)
> Yeah, saw your name in the manpage and thought you might subscribe here.

Rumbled ;-)

D.

-- 
Daniel Silverstone                       http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler: Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org       KeyId: 20687895



Reply | Threaded
Open this post in threaded view
|

Re: Lua 5 vs Lua 4

Asko Kauppi-3
In reply to this post by Brian Weed-2

userdata: isn't it there? I did make a 4/5 compatibility layer above this anyways, you might want to take a look at 'gluax_50.c' (part of 'gluax-devel', http://sourceforge.net/projects/luacheia).

getglobals: something like 'getfenv' or so now.. (function environment) I was actually one of the people for the name change but ..now later.. would actually like the old terminology back. ;)

Lua on OS X: I use it all the time, but via gluax (no OS X specific stuff, graphics go via SDL etc.) What's your concern?

-ak


Brian Weed kirjoittaa perjantaina, 12. syyskuuta 2003, kello 20:06:

Can someone point me to information about what happened to the following :

LUA_ERRORMESSAGE
lua_pushuserdata
lua_getglobals
lua_rawcall

and alternatives that I should use instead.

Also, has anyone successfully used Lua 5 on the Mac (specifically Carbon) or
know of any caveats?

Brian Weed
Senior Software Architect
ImaginEngine Corp.



Reply | Threaded
Open this post in threaded view
|

Lua v5.0 on Mac (Carbon)

Brian Weed-2
In reply to this post by chris.danx
I am considering switching from Lua 4 to Lua 5, and have come accross a
problem when compiling Lua 5 in Carbon.

ldebug.c line 267 defines a macro called "check", and lparser.c line 89
defines a static function named "check".

But, the Carbon Headers define a macro named "check" in Debugging.h.

Normally these would not conflict with each other, since both of those lua
"check"s are in their own translation unit.  However, the nature of Carbon
forces me to automatically include the precompiled carbon headers as a
prefix to every source compile (CodeWarrior Prefix file).  And so I do have
a conflict.

I don't expect the Lua team to change the name of a couple functions just
for me, but it would be more Carbon friendly if those names were changed.

Is this the right list to post stuff like this?

Brian Weed
Senior Software Architect
ImaginEngine Corp.


Reply | Threaded
Open this post in threaded view
|

Re: debian: no lua.h?

chris.danx
In reply to this post by Daniel Silverstone
Daniel Silverstone wrote:

I don't believe so. It's rare for library packages to recommend their
-dev variants.

Ok.


How can I set the compiler to look for the header files in /usr/include/lua50 or include it?


I tend to #include <lua50/lua.h> but you can just do #include <lua.h>
and then stick -I/usr/include/lua50 on the commandline.

Also, consider looking at lua-config50 which is a tool liblua50-dev
installs.

That's a nice tool.  Thanks.

I started the Ada 95 binding tonight and although it doesn't do very much (just creates a state, loads the libs and fires some strings at lua ala the book), it's nice to see it working and it's not as bad as I'd feared (some c libs are really painful to bind to, but this is a doddle).


Cheers,
Chris


Reply | Threaded
Open this post in threaded view
|

Re: Lua v5.0 on Mac (Carbon)

Ando Sonenblick
In reply to this post by Brian Weed-2
I too came across this when incorporating the sources.   I couldn¹t find
anything better than renaming the mac's check to "maccheck" (and changing
all the references to it as well).

I chose to edit the mac's files because it looks so esoteric and like
nothing encountered in my daily work.

Whereas I knew lua would be using its check...

Ando


> I am considering switching from Lua 4 to Lua 5, and have come accross a
> problem when compiling Lua 5 in Carbon.
> 
> ldebug.c line 267 defines a macro called "check", and lparser.c line 89
> defines a static function named "check".
> 
> But, the Carbon Headers define a macro named "check" in Debugging.h.
> 
> Normally these would not conflict with each other, since both of those lua
> "check"s are in their own translation unit.  However, the nature of Carbon
> forces me to automatically include the precompiled carbon headers as a
> prefix to every source compile (CodeWarrior Prefix file).  And so I do have
> a conflict.
> 
> I don't expect the Lua team to change the name of a couple functions just
> for me, but it would be more Carbon friendly if those names were changed.
> 
> Is this the right list to post stuff like this?
> 
> Brian Weed
> Senior Software Architect
> ImaginEngine Corp.

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



Reply | Threaded
Open this post in threaded view
|

RE: Lua 5 vs Lua 4

Brian Weed-2
In reply to this post by Asko Kauppi-3
>> Lua on OS X: I use it all the time, but via gluax (no OS X specific
>> stuff, graphics go via SDL etc.) What's your concern?

I saw that threads were added to v5, and I just wanted to make sure that I
didn't waste my time converting from v4 to v5 if v5 was not going to work in
Carbon.  But, it seems to work (except for the few things I had to comment
out in my own code that aren't in v5 anymore).

Brian

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of Asko Kauppi
Sent: Friday, September 12, 2003 3:23 PM
To: Lua list
Subject: Re: Lua 5 vs Lua 4



userdata: isn't it there?  I did make a 4/5 compatibility layer above
this anyways, you might want to take a look at 'gluax_50.c' (part of
'gluax-devel', http://sourceforge.net/projects/luacheia).

getglobals: something like 'getfenv' or so now.. (function environment)
I was actually one of the people for the name change but ..now later..
would actually like the old terminology back. ;)

Lua on OS X: I use it all the time, but via gluax (no OS X specific
stuff, graphics go via SDL etc.) What's your concern?

-ak


Brian Weed kirjoittaa perjantaina, 12. syyskuuta 2003, kello 20:06:

> Can someone point me to information about what happened to the
> following :
>
> LUA_ERRORMESSAGE
> lua_pushuserdata
> lua_getglobals
> lua_rawcall
>
> and alternatives that I should use instead.
>
> Also, has anyone successfully used Lua 5 on the Mac (specifically
> Carbon) or
> know of any caveats?
>
> Brian Weed
> Senior Software Architect
> ImaginEngine Corp.
>



Reply | Threaded
Open this post in threaded view
|

extern "C" ?

Brian Weed-2
In reply to this post by Brian Weed-2
I had to add the following to every Lua header file to be consistent accross
my two target platforms (Win32, Carbon):

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif

It would be nice if Lua already had this.

Brian Weed
Senior Software Architect
ImaginEngine Corp.


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5 vs Lua 4

Ando Sonenblick
In reply to this post by Brian Weed-2
Rest assured, lua 5 works very well in carbon land.  Just the typical tweaks
to get it integrated and then its pretty much trouble free...

ando

>>> Lua on OS X: I use it all the time, but via gluax (no OS X specific
>>> stuff, graphics go via SDL etc.) What's your concern?
> 
> I saw that threads were added to v5, and I just wanted to make sure that I
> didn't waste my time converting from v4 to v5 if v5 was not going to work in
> Carbon.  But, it seems to work (except for the few things I had to comment
> out in my own code that aren't in v5 anymore).
> 
> Brian
> 
> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Asko Kauppi
> Sent: Friday, September 12, 2003 3:23 PM
> To: Lua list
> Subject: Re: Lua 5 vs Lua 4
> 
> 
> 
> userdata: isn't it there?  I did make a 4/5 compatibility layer above
> this anyways, you might want to take a look at 'gluax_50.c' (part of
> 'gluax-devel', http://sourceforge.net/projects/luacheia).
> 
> getglobals: something like 'getfenv' or so now.. (function environment)
> I was actually one of the people for the name change but ..now later..
> would actually like the old terminology back. ;)
> 
> Lua on OS X: I use it all the time, but via gluax (no OS X specific
> stuff, graphics go via SDL etc.) What's your concern?
> 
> -ak
> 
> 
> Brian Weed kirjoittaa perjantaina, 12. syyskuuta 2003, kello 20:06:
> 
>> Can someone point me to information about what happened to the
>> following :
>> 
>> LUA_ERRORMESSAGE
>> lua_pushuserdata
>> lua_getglobals
>> lua_rawcall
>> 
>> and alternatives that I should use instead.
>> 
>> Also, has anyone successfully used Lua 5 on the Mac (specifically
>> Carbon) or
>> know of any caveats?
>> 
>> Brian Weed
>> Senior Software Architect
>> ImaginEngine Corp.
>> 
> 

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



Reply | Threaded
Open this post in threaded view
|

Re: Lua v5.0 on Mac (Carbon)

Mark Hamburg-4
In reply to this post by Brian Weed-2
You could use Project Builder instead of CodeWarrior and avoid the
pre-compiled headers.

You could build Lua into a library that doesn't reference Carbon and thereby
avoid the pre-compiled headers.

You might even be able to get a CodeWarrior project to work without
pre-compiled headers, but I'm not as certain of that.

Mark

on 9/12/03 12:56 PM, Brian Weed at [hidden email] wrote:

> I am considering switching from Lua 4 to Lua 5, and have come accross a
> problem when compiling Lua 5 in Carbon.
> 
> ldebug.c line 267 defines a macro called "check", and lparser.c line 89
> defines a static function named "check".
> 
> But, the Carbon Headers define a macro named "check" in Debugging.h.
> 
> Normally these would not conflict with each other, since both of those lua
> "check"s are in their own translation unit.  However, the nature of Carbon
> forces me to automatically include the precompiled carbon headers as a
> prefix to every source compile (CodeWarrior Prefix file).  And so I do have
> a conflict.
> 
> I don't expect the Lua team to change the name of a couple functions just
> for me, but it would be more Carbon friendly if those names were changed.
> 
> Is this the right list to post stuff like this?
> 
> Brian Weed
> Senior Software Architect
> ImaginEngine Corp.
> 


Reply | Threaded
Open this post in threaded view
|

RE: extern "C" ?

Richard Ranft
In reply to this post by Brian Weed-2
EVERYONE has to add that....

The thing of it is, as cool as C++ is not everyone uses it.  So, if you
change it the C people will object.  If you leave it the C++ people cry.
This discussion comes up EVERY time someone starts using Lua.

Can't you just extern "C" {} the headers where you include them?  Or doesn't
that work?

Besides, you've already added it, too late to change it now....  ;)

Rich

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of Brian Weed
Sent: Friday, September 12, 2003 3:13 PM
To: Lua list
Subject: extern "C" ?


I had to add the following to every Lua header file to be consistent accross
my two target platforms (Win32, Carbon):

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif

It would be nice if Lua already had this.

Brian Weed
Senior Software Architect
ImaginEngine Corp.


Reply | Threaded
Open this post in threaded view
|

RE: Lua memory usage for games console

Richard Ranft
In reply to this post by Stuart Middleton
Did your original "scripting attempt" work?

A VM takes a bit of overhead just to support it's ability to translate
between the scripting language and the program.  When you make semi-typeless
variables you then have to use a union (or something similar) to handle it
(you could make all variables members of a class that can overload operators
so that, well, you get the idea....).

As for the multiple copies of the same script bit, why not just hold the
local info for each copy of the script that you would have made, then
literally load that info in before you run the single copy of the script -
like C++'s vtable for member functions in classes.  Load one copy of code,
use many individual instances of data.  Keep a vtable on the C++ side to
separate your data, and I believe there is a way to change global data in a
LuaState....  I might be WAY off base here.

Probably not very helpful, but I hope it sparks some ideas for you....

Rich

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of Stuart
Middleton
Sent: Friday, September 12, 2003 9:17 AM
To: Lua list
Subject: Lua memory usage for games console



 Hi All,

We are currently evaluating lua as a replacement for our internal scripting
attempt. My initial evaluation (only 1 day) shows that each loaded script
uses a load of memory.

i.e.

xpos = 20.423987987234
ypos = 30.923874982343
zpos = 40.982374982734

function GetAllPos()
	return xpos+ypos+zpos;
end

function GetXPos()
	return xpos;
end

function GetYPos()
	return ypos;
end

function GetZPos()
	return zpos;
end

which is pitifully small (and does nothing useful) uses 822 bytes of memory.
I am using precompiled scripts with the debug info stripped. This memory
does not included the mem used to load the script in the first place.

As far as I can see its because of the over bloated structures inside lua.
For instance GCObject uses 72 bytes just because it's a union of common
types one of which being Proto which is 72 bytes long. So at a guess each
variable will be at least 72 bytes long?

Before I go rewriting how lua handles its internal structures or give up on
it completely I wondered if anyone out there has reworked the system to use
minimal memory.

As comparison a simple test script like this in our system would use about
250 bytes with new instances of the same script using < 100 bytes.

Any help would be much appreciated.

While I'm at it I have another question.
We will need to load multiple scripts, hundreds in fact, most of which would
be copies of each other. They all need to maintain their own global (or file
local) variables. Has anyone done this before? I guessed you would use
either the threading system or a new state for each (we are not
multi-threaded) but the overhead for a new system or even a new thread each
time is a bit over the top. Also our internal system was written so we could
load a script once and create instances of it with new variables but pointer
to the functions in just 1 copy of the byte code.

Any idea's

Hope you can help

Stuart Middleton (lua newbie)




Reply | Threaded
Open this post in threaded view
|

Re: extern "C" ?

Eric Tetz-2
In reply to this post by Brian Weed-2
--- Brian Weed <[hidden email]> wrote:
> I had to add the following to every Lua header file [...]

http://lua-users.org/lists/lua-l/2003-04/msg00121.html

Cheers,
Eric

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: extern "C" ?

Brian Weed-2
In reply to this post by Richard Ranft
> Besides, you've already added it, too late to change it now....  ;)

Yeah, but thats the 2nd time I had to do that.  Once in v4, and now again in
v5.  And when a new update comes out, I will have to do it again (or merge
the diffs).

Brian


----- Original Message ----- 
From: "Richard Ranft" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Friday, September 12, 2003 7:50 PM
Subject: RE: extern "C" ?


> EVERYONE has to add that....
>
> The thing of it is, as cool as C++ is not everyone uses it.  So, if you
> change it the C people will object.  If you leave it the C++ people cry.
> This discussion comes up EVERY time someone starts using Lua.
>
> Can't you just extern "C" {} the headers where you include them?  Or
doesn't
> that work?
>
> Besides, you've already added it, too late to change it now....  ;)
>
> Rich
>
> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Brian Weed
> Sent: Friday, September 12, 2003 3:13 PM
> To: Lua list
> Subject: extern "C" ?
>
>
> I had to add the following to every Lua header file to be consistent
accross
> my two target platforms (Win32, Carbon):
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> ...
>
> #ifdef __cplusplus
> }
> #endif
>
> It would be nice if Lua already had this.
>
> Brian Weed
> Senior Software Architect
> ImaginEngine Corp.
>
>


12