CEGUI (Crazy Eddie's GUI) Forums

Hi,

I'd like to get some better debugging possibilities of lua, therefore this change request. If exceptions from lua would be forwarded, it would become much easier.



/G

Hi,

I have a recollection of something like this being bought up before - though can't remember any specifics (so it might just be something I thought of myself!). But in any event, I agree that exceptions would be useful if they were forwarded on.

Which version of the lib is this that you're using? I can't check anything at the moment since I have no CEGUI code on this machine

CE.

Oops , forgot to state which release we use...

We are using current SVN trunk rev 1831.

/G

Thanks for the info

I'll have a look into it soon.

One weekend soon I intend to clear up most of the outstanding bugs, issues and small-ish requests. (Was supposed to have been this past weekend, but it didn't happen ).

CE.

One thing that would be really nice to see would be the option to specify a lua function pointer which would be sent as the fourth argument in the lua_pcall function (i.e. an error handler).

Hi,

Thanks for the suggestion, I'll look into the possibilities.

I'll make a pass through some of these threads soon and pickup all the 'missed' suggestions and add the good ones to mantis

CE.

Ok, guys.

Forwarding of exceptions is now in branches/v0-6 at rev. 1843. It will hit trunk with the next merge (a few days).

The request to pass in an error handler function is added to mantis here: http://www.cegui.org.uk/mantis/view.php?id=239 - should be done soon

CE.

Great news!

Hi,

I've turned part of my attention to the passing of an error handler function to lua_pcall.

I have some ideas, though would like to maybe get some discussion about it so that hopefully I can provide the desired functionality - as opposed to "something else"

First, any modifications will have to be done in the Lua script module itself, rather than any of the higher level APIs (such as those ones in CEGUI::System). The reason for this is because script modules using other languages might not have the same kind of provision for an error handler - so it's best to keep that kind of thing in with the specific parts they apply to.

Anyway, there are a couple of possible approaches to this.

The first is to simply have get/set member functions to access a string that defines the name of the lua function to be used. Anywhere we use lua_pcall would then use this function, if specified, as the error handler.

The second approach is to extend the existing functions (executeScriptFile etc) to accept the name of an error handler and have those use the name passed as the error handler.

The second approach generally has a lot more flexibility, though I'm not certain if you were looking for something like that or more like the first approach

Thanks for any discussion, or even other alternatives

CE.

Why not both: the ability to set a default lua error handler in the module and then an overloaded executeScript method which can take an additional parameter? If no parameter is sent the lua handler method set in the module is used.

The question is then to use a string for the lua function or an int for a reference to any lua or c method. The former is probably easier for those new to the library, while the latter is more powerful. I would prefer the latter, but you perhaps also have some Lua functor class which might be useful?

On a completely unrelated note: I never get any mails sent whenever someone posts in a topic I've marked for notification. Is this something that's broken for all?

Thanks for the input, it's very much appreciated since you likely have a much better idea of what would and would not be useful out in the real world; sometimes I think that what seems like good ideas to us as library creators can turn out to be less than stellar ideas when people actually try and use them. I'll have a play around with a view to getting this in over next weekend. BTW, you're right that we do have a lua functor class, though currently it's just used internally for binding event handlers subscribed from within lua.

ErikHjortsberg wrote:On a completely unrelated note: I never get any mails sent whenever someone posts in a topic I've marked for notification. Is this something that's broken for all?

Yeah, this is broken for everyone at the moment; it's a sourceforge.net limitation issue, and I agree it's something of a pain. They have actually relaunched their shell offering - which we previously used to trigger sending of emails - so we might be able to restore emails shortly, though I do not want to be picked up for systems abuse or something Ideally, they'll restore their cron offering, and all will be well because we could use that.

CE.

Hi,

I have now added the new functionality making it possible to pass functions to be used as the error handler in lua_pcall calls (this is in branches/v0-6 at rev. 1864, trunk will get it as part of the next merge). There are multiple options for utilising this new ability, and hopefully I did not mess it up too badly

Generally you have two options for what to pass; you can pass a string that names the function to be called, or you can pass a lua registry reference.

You can specify a default / global error handler which will be used where nothing more specific is specified. This option is set using the 'setDefaultPCallErrorHandler' function, for example:


It is also possible to pass the error handler to any of the script execution and event subscription functions available in the LuaScriptModule class. An example of this might be:


Finally, it's also possible to specify a handler when you subscribe to a handler from within lua itself. Such as:


This kind of setup allows you to have specific handlers for specific cases. One minor thing with regards to the default function and event subscription is that it will use the default that was in force at the time of the subscription - it will not pick up a new function if you change it after the subscription has occurred (a minor limitation in order to save from having to look up the default error handler every time an event is fired).

Anyway, that's about it. Remember that although in the examples above I use a string for the error handler, it's also possible to pass a lua registry reference.

Hope this is useful. Let us know if there are any issues.

CE.

Cool, I'll try it out!

Hi,

Updating to the latest version has completely stalled my application. It seems that anywhere that is subscribing to the global events is crashing, which means with this version my application wont even finish initialisation.



I found the log message less than helpful . Especially considering that every thing was working fine before hand.

I haven't been able to pin point what is going on or what has caused the crashes, but i highly suspect that it is this fix.

One call that i can comment out to make it crash a little later is this.



I cant help much more as i get lost trying to under stand the c++ side of lua.

ER.

Hi,

Thanks for this. I'll look into it (we're supposed to be at code freeze, but we can't issue a "maintenance" release that's going to break everyone's code!)

To confirm:
Is this explicitly due to the fact the exception is thrown, or related to maybe a bug the lua_pcall error handler feature? Or put another way, previously were errors logged with the same message (but no exception)?

Apologies for introducing a load of issues into what should be the stable branch of the code

CE.

[Edit]
I've run a couple of tests and did not get any issues. What I did was to try and recreate something similar to what you posted, as follows:
Created a lua table with a function to be called, and a field (to test the 'self').
Subscribed to the "Window/WindowUpdate" event using the function from the table, and passing the table as the self parameter.

The subscription and subsequent firing of the handler all occur as I would expect - no errors logged and no exceptions thrown.

From the error you posted, it looks like "MessageTracker.DoUpdate" is not correctly initialised to a function (but rather a number), it's strange if it was working previously (this is why I asked about the possibility of the errors being logged before).

[Edit 2]
From some more tests, and re-reading the error, it seems the error is not coming from the subscription, but the subsequent firing of the event and calling of the handler. The only thing I could get to come close was to do something like this in the handler (contrived example):

Which results in:

attempt to call local 'failuare' (a number value)

It's odd that no name is mentioned in your own error log, since that would help narrow this down considerably.

Currently, I have to lean towards saying - if I might be so bold - that I believe there might be an issue in your lua code somewhere