debian: no lua.h?

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

Re: extern "C" ?

Luiz Henrique de Figueiredo
>> 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).

How about creating a lua.hpp with the code below?

 extern "C"{
 #include "lua.h"
 }

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua v5.0 on Mac (Carbon)

Luiz Henrique de Figueiredo
In reply to this post by Brian Weed-2
>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.

>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.

#define LUA_USER_H to a header file of yours and in it #define check to be
Mycheck or something.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Re: extern "C" ?

D Burgess-2
In reply to this post by Brian Weed-2
Beats me why externally defining LUA_API
as 'extern "C"' would not work. e.g. in vc
/D LUA_API='extern "C"'

+++++++++++++++++++++++++++++++++
>--- 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" ?

Philip D. Bober
In reply to this post by Richard Ranft
But if that were in the original files, it wouldn't affect C users (because
of the #ifdef __cplusplus), only C++ users.

----- 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: extern "C" ?

Eric Tetz-2
--- "Philip D. Bober" wrote:
> But if that were in the original files, it wouldn't affect C
> users (because of the #ifdef __cplusplus), only C++ users.

Right, it would affect them negatively. Lua can be compiled as C or
as C++. If you compile it as C++ then names will be appropriately
mangled and you don't need the 'extern "C"' to link. You only need
the 'extern "C"' if you compile the Lua source as C, in which case
you don't need to add 'extern "C"' it to the Lua headers, you can
just create a new header:

// lua.hpp
extern "C" {
#include "lua.h"
}

In other words, the way it's setup now is more flexible.

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" ?

Jamie Webb-3
In reply to this post by Philip D. Bober
On Sunday 14 September 2003 18:06, Philip D. Bober wrote:
> But if that were in the original files, it wouldn't affect C users (because
> of the #ifdef __cplusplus), only C++ users.

You're missing the point: we might want to compile Lua using the C++ compiler. 
You then don't want the externs despite being a C++ user. It's only if you 
compile Lua using a C compiler (or use prebuilt library) and your program 
using a C++ compiler that you need them.

A suggestion: how about using a different macro, e.g. #ifdef LUA_EXTERN_C..., 
then people who want the externs can add that their makefiles once and leave 
the sources alone, and people who don't want the externs won't get them.

 -- Jamie Webb

How to hack a Computer: Step 1: Take axe and...

Reply | Threaded
Open this post in threaded view
|

Re: extern "C" ?

Brian Weed-2
Anyone compiling the lib as C++ is making a mistake.  C++ name mangling is
not portable, so if they ever switched compilers they would have to
re-compile the LUA libs just to be able to re-link.  If it were a C lib, and
correctly used the #ifdef __cplusplus, it would work accross all compilers
(on the same platform).
And this is what almost all other libs do (Png, Zip, FreeType, etc...)

However, I can see that this won't change the minds of the people who
matter, so I therefore endorse this guys suggestion, or something else
similar like:

#if defined(_cplusplus) && !defined(LUA_CPP)
extern "C" {
#endif

So the few people who NEED it to be C++ can define LUA_CPP

But, whatever the solution, Joe Programmer should not have to modify the
source code to make it compile.  Libs like this should work out of the box.

Brian

----- Original Message ----- 
From: "Jamie Webb" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Sunday, September 14, 2003 3:53 PM
Subject: Re: extern "C" ?


> On Sunday 14 September 2003 18:06, Philip D. Bober wrote:
> > But if that were in the original files, it wouldn't affect C users
(because
> > of the #ifdef __cplusplus), only C++ users.
>
> You're missing the point: we might want to compile Lua using the C++
compiler.
> You then don't want the externs despite being a C++ user. It's only if you
> compile Lua using a C compiler (or use prebuilt library) and your program
> using a C++ compiler that you need them.
>
> A suggestion: how about using a different macro, e.g. #ifdef
LUA_EXTERN_C...,
> then people who want the externs can add that their makefiles once and
leave
> the sources alone, and people who don't want the externs won't get them.
>
>  -- Jamie Webb
>
> How to hack a Computer: Step 1: Take axe and...
>


Reply | Threaded
Open this post in threaded view
|

RE: extern "C" ?

Vijay Aswadhati-2
Brian has a point that escaped me completely when this subject was discussed
earlier. C++ name mangling is not portable and hence LUA library compiled
for C++ by Visual C++ for instance cannot be used by an application that
uses Borland compiler (wont link because of name mangling differences).

For what its worth I second Brian's suggestion on handling this in
satisfying all camps and school thought. And concur that Joe Programmer
should not have to modify the source code to make it compile.

Vijay Aswadhati




> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Brian Weed
> Sent: Sunday, September 14, 2003 1:41 PM
> To: Lua list
> Subject: Re: extern "C" ?
>
>
> Anyone compiling the lib as C++ is making a mistake.  C++
> name mangling is
> not portable, so if they ever switched compilers they would have to
> re-compile the LUA libs just to be able to re-link.  If it
> were a C lib, and
> correctly used the #ifdef __cplusplus, it would work accross
> all compilers
> (on the same platform).
> And this is what almost all other libs do (Png, Zip, FreeType, etc...)
>
> However, I can see that this won't change the minds of the people who
> matter, so I therefore endorse this guys suggestion, or something else
> similar like:
>
> #if defined(_cplusplus) && !defined(LUA_CPP)
> extern "C" {
> #endif
>
> So the few people who NEED it to be C++ can define LUA_CPP
>
> But, whatever the solution, Joe Programmer should not have to
> modify the
> source code to make it compile.  Libs like this should work
> out of the box.
>
> Brian
>
> ----- Original Message -----
> From: "Jamie Webb" <[hidden email]>
> To: "Lua list" <[hidden email]>
> Sent: Sunday, September 14, 2003 3:53 PM
> Subject: Re: extern "C" ?
>
>
> > On Sunday 14 September 2003 18:06, Philip D. Bober wrote:
> > > But if that were in the original files, it wouldn't affect C users
> (because
> > > of the #ifdef __cplusplus), only C++ users.
> >
> > You're missing the point: we might want to compile Lua using the C++
> compiler.
> > You then don't want the externs despite being a C++ user.
> It's only if you
> > compile Lua using a C compiler (or use prebuilt library)
> and your program
> > using a C++ compiler that you need them.
> >
> > A suggestion: how about using a different macro, e.g. #ifdef
> LUA_EXTERN_C...,
> > then people who want the externs can add that their
> makefiles once and
> leave
> > the sources alone, and people who don't want the externs
> won't get them.
> >
> >  -- Jamie Webb
> >
> > How to hack a Computer: Step 1: Take axe and...
> >
>
>


Reply | Threaded
Open this post in threaded view
|

RE: extern "C" ?

Eric Tetz-2
--- Vijay Aswadhati <[hidden email]> wrote:
> C++ name mangling is not portable and hence LUA library compiled
> for C++ by Visual C++ for instance cannot be used by an
> application that uses Borland compiler (wont link because of name
> mangling differences).

Well, library files aren't portable either. They may happen to be
interchangeable between a few Windows compilers (I don't know), but
this is hardly a guarantee.
 
> Joe Programmer should not have to modify the source code to make
> it compile.

That is the current situation. Brian did *not* need to modify the
Lua headers. Luiz showed a simple, straight-forward solution:

// lua.hpp
extern "C" {
#include "lua.h"
}

What's wrong with that?

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
> // lua.hpp
> extern "C" {
> #include "lua.h"
> }
>
> What's wrong with that?

1) Joe Programmer has to make modifications to a system before it works for
him.  Thats whats wrong.  Some 3rd party libs (like pnglib for example) even
ship with the project files for various compilers so Joe Programmer doesn't
even have to create them.  Anything to save Joe Programmer time is key.
Thats the whole point of 3rd party libs (even the free ones).  Joe could
write his own scripting language or bitmap file format, but these libs exist
to save him time (and to build standards).

2) The .hpp thing would not work for me in my Codewarrior build environment
because of the precompiled Carbon headers.  I had to add the extern "C" to
every header file, not just the public ones, and therefore, I would have had
to modify all Lua files to #include whatever.hpp instead.  It would have
been easier for me to rename every .C to .CPP.  I'm not saying that my
Codewarrior build environment is perfect, but the less mods I have to make
to get something to compile, the better.

3)  This defeats information hiding.  By using that .hpp, you are making
assumptions about the library, and if the library ever changed to be a C++
lib, it would all of a sudden not link for you.  But if it had the #ifdef
__cplusplus thing placed by the "owners", then you would not have to even
think about "what do I need to do to get this thing to compile?".  The
"owners" only have to do it once, where as the 20,000 Joe Programmers using
Lua all have to do it manually.  Here is a similar example.  In the Mac API,
pretty much all header files are included like this.

#ifndef SOMEHEADERFILE
#include "someheaderfile.h"
#endif

#ifndef SOMEOTHERHEADERFILE
#include "someotherheaderfile.h"
#endif

They did this to speed up compiles because the header file is not opened if
it was already included (and therefore defined a SOMEHEADERFILE).  If this
check was inside the header file, then there is a disk hit to open and read
the header only to then find out that it was already included.
In this environment, Joe Programmer must know something about the header
files he is including for fear of including them twice.  I am of the mindset
that all Joe should have to do is just include the header, and not worry
about "gee, did I include it correctly?".  Joe's code should look like this:

#include "one.h"
#include "two.h"
#include "three.h"

and not

#ifndef ONE
#include "one.h"
#endif

#ifndef TWO
#include "two.h"
#endif

#ifndef THREE
#include "three.h"
#endif


I don't want to waste too much more time on this topic, since I'm sure the
Lua guys have heard all this before, and if they haven't changed the code by
now, then we should not bug them any more about it.

Brian.

----- Original Message ----- 
From: "Eric Tetz" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Sunday, September 14, 2003 8:12 PM
Subject: RE: extern "C" ?


> --- Vijay Aswadhati <[hidden email]> wrote:
> > C++ name mangling is not portable and hence LUA library compiled
> > for C++ by Visual C++ for instance cannot be used by an
> > application that uses Borland compiler (wont link because of name
> > mangling differences).
>
> Well, library files aren't portable either. They may happen to be
> interchangeable between a few Windows compilers (I don't know), but
> this is hardly a guarantee.
>
> > Joe Programmer should not have to modify the source code to make
> > it compile.
>
> That is the current situation. Brian did *not* need to modify the
> Lua headers. Luiz showed a simple, straight-forward solution:
>
> // lua.hpp
> extern "C" {
> #include "lua.h"
> }
>
> What's wrong with that?
>
> 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: Lua memory usage for games console

Stuart Middleton
In reply to this post by Richard Ranft
Thanks for the reply rich,

Yes the original attempt worked and got published in our game but its error
trapping was a joke and it had problems with parsing complex math functions.
The programmer that originally wrote it has now left so we decided to look
around before giving it to another programmer. We are all a little
intimidated as the original programmer has a degree in computer language
design. On the other hand he has left his course notes here so it may not be
so bad.

I will spend another couple of days on lua before giving up.

Thanks

Stu

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of Richard Ranft
Sent: 13 September 2003 01:00
To: Lua list
Subject: RE: Lua memory usage for games console

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: Lua 5 vs Lua 4

Brian Weed-2
In reply to this post by Asko Kauppi-3
Ok, so I have alternatives for all except LUA_ERRORMESSAGE.

In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
function so that any errors detected by Lua would call my error handler
instead of it's own.  But now that function is gone, and I am wondering how
I can do this in v5.

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
|

Re: Lua 5 vs Lua 4

D Burgess-2
In reply to this post by Brian Weed-2
WHen you start everything off with pcall(), you can add
your own error handler to the pcall() call.

This means that you can  vector to your own error handler.

lua.c is an example.



+++++++++++++++++++++++++++++++++
>Ok, so I have alternatives for all except LUA_ERRORMESSAGE.
>
>In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
>function so that any errors detected by Lua would call my error handler
>instead of it's own.  But now that function is gone, and I am wondering how
>I can do this in v5.
>
>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
|

RE: Lua 5 vs Lua 4

Brian Weed-2
Turns out that the correct answer to my question was:

use "_ALERT" instead of "_ERRORMESSAGE"

Brian.

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of D Burgess
Sent: Monday, September 15, 2003 6:30 PM
To: Lua list
Subject: Re: Lua 5 vs Lua 4


WHen you start everything off with pcall(), you can add
your own error handler to the pcall() call.

This means that you can  vector to your own error handler.

lua.c is an example.



+++++++++++++++++++++++++++++++++
>Ok, so I have alternatives for all except LUA_ERRORMESSAGE.
>
>In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
>function so that any errors detected by Lua would call my error handler
>instead of it's own.  But now that function is gone, and I am wondering how
>I can do this in v5.
>
>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
|

Re: RE: Lua 5 vs Lua 4

D Burgess-2
In reply to this post by Brian Weed-2
I dont think so. _ALERT correct me if I am wrong
is only called in Lua5 for lua_dostring, lua_do_buffer
and lua_dofile. Which means that your _ALERT function
wont get called when you use pcall().

DB
+++++++++++++++++++++++++++++++++
>Turns out that the correct answer to my question was:
>
>use "_ALERT" instead of "_ERRORMESSAGE"
>
>Brian.
>
>-----Original Message-----
>From: [hidden email]
>[[hidden email] Behalf Of D Burgess
>Sent: Monday, September 15, 2003 6:30 PM
>To: Lua list
>Subject: Re: Lua 5 vs Lua 4
>
>
>WHen you start everything off with pcall(), you can add
>your own error handler to the pcall() call.
>
>This means that you can  vector to your own error handler.
>
>lua.c is an example.
>
>
>
>+++++++++++++++++++++++++++++++++
>>Ok, so I have alternatives for all except LUA_ERRORMESSAGE.
>>
>>In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
>>function so that any errors detected by Lua would call my error handler
>>instead of it's own.  But now that function is gone, and I am wondering how
>>I can do this in v5.
>>
>>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
|

RE: RE: Lua 5 vs Lua 4

Brian Weed-2
I don't use pcall(), whatever that is.

All Lua code in my Game Engine is executed with lua_dostring.

Brian.

-----Original Message-----
From: [hidden email]
[[hidden email] Behalf Of D Burgess
Sent: Thursday, September 18, 2003 12:00 AM
To: Lua list
Subject: Re: RE: Lua 5 vs Lua 4


I dont think so. _ALERT correct me if I am wrong
is only called in Lua5 for lua_dostring, lua_do_buffer
and lua_dofile. Which means that your _ALERT function
wont get called when you use pcall().

DB
+++++++++++++++++++++++++++++++++
>Turns out that the correct answer to my question was:
>
>use "_ALERT" instead of "_ERRORMESSAGE"
>
>Brian.
>
>-----Original Message-----
>From: [hidden email]
>[[hidden email] Behalf Of D Burgess
>Sent: Monday, September 15, 2003 6:30 PM
>To: Lua list
>Subject: Re: Lua 5 vs Lua 4
>
>
>WHen you start everything off with pcall(), you can add
>your own error handler to the pcall() call.
>
>This means that you can  vector to your own error handler.
>
>lua.c is an example.
>
>
>
>+++++++++++++++++++++++++++++++++
>>Ok, so I have alternatives for all except LUA_ERRORMESSAGE.
>>
>>In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
>>function so that any errors detected by Lua would call my error handler
>>instead of it's own.  But now that function is gone, and I am wondering
how
>>I can do this in v5.
>>
>>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
|

Re: RE: RE: Lua 5 vs Lua 4

D Burgess-2
In reply to this post by Brian Weed-2
Fine
+++++++++++++++++++++++++++++++++
>I don't use pcall(), whatever that is.
>
>All Lua code in my Game Engine is executed with lua_dostring.
>
>Brian.
>
>-----Original Message-----
>From: [hidden email]
>[[hidden email] Behalf Of D Burgess
>Sent: Thursday, September 18, 2003 12:00 AM
>To: Lua list
>Subject: Re: RE: Lua 5 vs Lua 4
>
>
>I dont think so. _ALERT correct me if I am wrong
>is only called in Lua5 for lua_dostring, lua_do_buffer
>and lua_dofile. Which means that your _ALERT function
>wont get called when you use pcall().
>
>DB
>+++++++++++++++++++++++++++++++++
>>Turns out that the correct answer to my question was:
>>
>>use "_ALERT" instead of "_ERRORMESSAGE"
>>
>>Brian.
>>
>>-----Original Message-----
>>From: [hidden email]
>>[[hidden email] Behalf Of D Burgess
>>Sent: Monday, September 15, 2003 6:30 PM
>>To: Lua list
>>Subject: Re: Lua 5 vs Lua 4
>>
>>
>>WHen you start everything off with pcall(), you can add
>>your own error handler to the pcall() call.
>>
>>This means that you can  vector to your own error handler.
>>
>>lua.c is an example.
>>
>>
>>
>>+++++++++++++++++++++++++++++++++
>>>Ok, so I have alternatives for all except LUA_ERRORMESSAGE.
>>>
>>>In Lua v4.x  I overloaded the Lua "_ERRORMESSAGE" global error handler
>>>function so that any errors detected by Lua would call my error handler
>>>instead of it's own.  But now that function is gone, and I am wondering
>how
>>>I can do this in v5.
>>>
>>>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
|

RE: RE: Lua 5 vs Lua 4

Luiz Henrique de Figueiredo
In reply to this post by Brian Weed-2
>I don't use pcall(), whatever that is.
>
>All Lua code in my Game Engine is executed with lua_dostring.

lua_dostring is marked to be renamed luaL_dostring, as it is now in the auxlib.
Moreover, the _ALERT scheme is deprecated.

The correct way to handle your problem is to call luaL_loadbuffer, handle any
errors that it returns, and then call pcall() and handle any errors that it
returns.  See http://lua-users.org/lists/lua-l/2002-12/msg00046.html .
--lhf

12