Re: [luabind] set_pcall_callback()

[Arvid N. <c9...@cs...>]

On Jan 9, 2006, at 19:55, Alexander Gladysh wrote:

> Hi, all!
>
> The pcall_callback_fun() callback function prototype is documented
> incorrectly as
>     typedef void(*pcall_callback_fun)(lua_State*);
>
> it should be
>
>     typedef int(*pcall_callback_fun)(lua_State*);
>
> with int return type instead of void.
>
> I think it worth mentioning what Luabind would do with the returned  
> value.

Thanks for spotting. I've updated the docs in the release branch. Now  
it also makes more explicit references to the lua manual for more  
information. luabind doesn't do anything with the return value, it  
doesn't do anything with any error message returned from lua. It is  
just left on the stack for the library user to inspect.

> Also, symmetrical function get_pcall_callback() is not documented.

This is kindof intentional. It's purpose is just to be used  
internally really anyway, and I don't think the use cases for  
actually having a pcall_callback have any use for it either.

We added this on a request from a guy who was writing a lua debugger,  
and wanted to be able to get more debug information from lua.

> By the way, I think, documentation can include some 'recommended
> practice' code sample on retrieving of that 'more information' for
> protected call failure (by using lua_getstack() => lua_getinfo(), I
> guess). It seems to be a common question to blame Luabind for lack of
> file and line numbers in error messages.

I've added more references to the lua manual. I want to avoid turning  
the luabind docs into a lua tutorial. But you're right, references  
may be a good help, especially for people who go directly to luabind  
without learning lua first.

> However, it seems to me that it would require some hacking from user
> to append such info to the error message string, returned by Luabind.
> If that information is available somehow to Luabind at the time error
> message is generated, it would be great to have Luabind errors to be
> formatted in the same way as Lua errors are. If there are some
> performance issues for that, then availability of such feature can be
> configured, say, with some macro.

This is probably a good idea. I will look into it.

> With best regards,
> Alexander.
>
> P.S. Nitpicking: Some 'devstudio' is mentioned in the docs couple of
> times. I think that it worth to either define it is as supported
> versions of Visual Studio, or to replace that term with more official
> one, like MSVC.

Thanks. Will update.

--
Arvid Norberg