Why need to call "priming lua_pcall()" before running function in Lua script

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

Why need to call "priming lua_pcall()" before running function in Lua script

Nan Xiao
Hi all,

After reading "Calling Lua From a C Program", I see it's need to call "priming lua_pcall()" or
"priming lua_dofilel()" before using "lua_getglobal()" to get a function and run it successfully.
Or the program will complain "attempt to call a nil value".

But after googling and going through "Programming in Lua", I can't find what is under the
hood. Could anyone can explain why need the the magical "priming lua_pcall"?

Thanks very much in advance!

Best Regards
Nan Xiao
Reply | Threaded
Open this post in threaded view
|

Re: Why need to call "priming lua_pcall()" before running function in Lua script

Coda Highland
On Thu, Jul 2, 2015 at 11:39 PM, Nan Xiao <[hidden email]> wrote:

> Hi all,
>
> After reading "Calling Lua From a C Program", I see it's need to call
> "priming lua_pcall()" or
> "priming lua_dofilel()" before using "lua_getglobal()" to get a function and
> run it successfully.
> Or the program will complain "attempt to call a nil value".
>
> But after googling and going through "Programming in Lua", I can't find what
> is under the
> hood. Could anyone can explain why need the the magical "priming lua_pcall"?
>
> Thanks very much in advance!
>
> Best Regards
> Nan Xiao

It's sort of a weird term. I've never seen it used before. But from
the context of the page you linked, I can figure it out.

What it's actually saying is that you PROBABLY want to run some Lua
code when you first create the state, so that you can do things like
create global variables and define Lua functions that you want to
offer to the other Lua code that you will be running later.

This author seems to have invented the term because he didn't realize
that the examples in the documentation were just simple examples of
how things might look in use, and not intended as standalone code that
you can use directly. So for example, when he got an error saying
"attempt to call a nil value" it's because he never did anything to
create the function that he was trying to call.

Honestly I would suggest avoiding this document and looking for
something better to work from.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Why need to call "priming lua_pcall()" before running function in Lua script

Ignacio Burgueño-2

On Fri, Jul 3, 2015 at 3:45 AM, Coda Highland <[hidden email]> wrote:
On Thu, Jul 2, 2015 at 11:39 PM, Nan Xiao <[hidden email]> wrote:

Honestly I would suggest avoiding this document and looking for
something better to work from.


I think this course is better.


In particular, I think that parts 12 and 13 are relevant to what you are doing:



 

Reply | Threaded
Open this post in threaded view
|

Re: Why need to call "priming lua_pcall()" before running function in Lua script

Tim Hill
In reply to this post by Nan Xiao

On Jul 2, 2015, at 11:39 PM, Nan Xiao <[hidden email]> wrote:

Hi all,

After reading "Calling Lua From a C Program", I see it's need to call "priming lua_pcall()" or
"priming lua_dofilel()" before using "lua_getglobal()" to get a function and run it successfully.
Or the program will complain "attempt to call a nil value".

But after googling and going through "Programming in Lua", I can't find what is under the
hood. Could anyone can explain why need the the magical "priming lua_pcall"?

Thanks very much in advance!

Best Regards
Nan Xiao

There is no need for this “priming” process, as others have noted. The author seems to be using this as a way to pass state from C code into Lua (via global variables), but this is pretty crude; you are better off passing arguments on the stack as I previously outlined. Of course, if the Lua code expects a global “foo” and there isn’t one, yes it will get nil when it tries to read it, but the fix there is probably not to expect a “foo” global in the first place :)

Think about the stand-alone “lua” command that you can use to run any Lua script from the command line. This utility is just a very thin wrapper that creates a Lua state (and loads the standard libraries) reads the Lua script from a file, compiles it using lua_load(), and then calls it using lua_call(). (I’m simplifying a lot here, technically it uses slightly different APIs, but the basic model is the same).

—Tim

Reply | Threaded
Open this post in threaded view
|

Re: Why need to call "priming lua_pcall()" before running function in Lua script

Nan Xiao
Hi Coda, Ignacio, Tim,

Thanks very much for all your kind help and time!

Best Regards
Nan Xiao

On Sat, Jul 4, 2015 at 2:11 AM, Tim Hill <[hidden email]> wrote:

On Jul 2, 2015, at 11:39 PM, Nan Xiao <[hidden email]> wrote:

Hi all,

After reading "Calling Lua From a C Program", I see it's need to call "priming lua_pcall()" or
"priming lua_dofilel()" before using "lua_getglobal()" to get a function and run it successfully.
Or the program will complain "attempt to call a nil value".

But after googling and going through "Programming in Lua", I can't find what is under the
hood. Could anyone can explain why need the the magical "priming lua_pcall"?

Thanks very much in advance!

Best Regards
Nan Xiao

There is no need for this “priming” process, as others have noted. The author seems to be using this as a way to pass state from C code into Lua (via global variables), but this is pretty crude; you are better off passing arguments on the stack as I previously outlined. Of course, if the Lua code expects a global “foo” and there isn’t one, yes it will get nil when it tries to read it, but the fix there is probably not to expect a “foo” global in the first place :)

Think about the stand-alone “lua” command that you can use to run any Lua script from the command line. This utility is just a very thin wrapper that creates a Lua state (and loads the standard libraries) reads the Lua script from a file, compiles it using lua_load(), and then calls it using lua_call(). (I’m simplifying a lot here, technically it uses slightly different APIs, but the basic model is the same).

—Tim