Crash when accessing 'window.child' with gtk2 about lgi HOT 6 CLOSED

Thanks for the report. Fixed in master. However, I recommend to switch to Gtk-3, if possible. .gir support for gtk-2 is really crude...

from lgi.

Yup, works great; thank you.

While gtk3 hasn't completely replaced gtk2, there is interest in supporting both; we'll see how much of a hassle will that be.

from lgi.

Commit 1a9d493 introduced a regression, unfortunately. The Lua function tonumber is implemented using strtod, and is therefore locale-dependent. It returns nil for strings like "3.0" in locales in which the decimal separator is not ..

The version number should be probably parsed using the string library. Especially since it probably isn't guaranteed to be a simple decimal number.

from lgi.

I don't think that avoiding tonumber at all is good idea. I think that putting Lua into the state that it is not able to parse canonical (non-localized) representation of numbers is the core bug, and working around it by manually parsing numbers is just crude workaround I'd like to avoid.

During lgi development, we already dealt with this situation a few times. The culprit was always wrapped library calling setlocale() (which is IMHO wrong to do in library, it should be the decision of application to call this function). Workaround were introduced into Gtk and Gstreamer overrides.

Do you have any idea where the offending setlocale() call originates in your case? If it is from lgi-wrapped library, I'd like to know about it and introduce some workaround for it into overrides. If it comes from elsewhere, I'm inclining to declare that it is your responsibility to somehow 'fix' tonumber (e.g. by monkeypatching) to be able to parse 'C' locale numbers again.

Please let me know your opinion about this.

from lgi.

The library is GTK itself, actually. I use Lua embedded in SciTE, which initialises GTK (calling setlocale() along the way) before running any Lua scripts. Most of the time LGI works quite well, as long as I remember to avoid (or be very careful with) asynchronous I/O, and to load the same version of GTK that SciTE uses. (And by the way, great job. I find these bindings are of better quality than the JavaScript bindings produced by GLib/GTK developers themselves. Though given their recent creations, it shouldn't be very surprising…)

I do agree that this is a bug in Lua, and ought to be fixed there, but the sad reality is that in the meantime we still have to use the existing buggy 5.1 and 5.2 implementations, and will probably keep using them for quite some time. You never know how your code is going to be called, so you cannot take every exceptional situation into account; better to just make as few assumptions about the execution environment as you can. Just don't parse it as a number. It probably isn't just a number anyway. What if someone installs, say, a development snapshot of GStreamer and tells it to brand itself as "2.0-git" in the bindings? I think there's a reason the version field is a string at all.

from lgi.

AFAIK, repository version number is pretty fixed, it is not something you can change while building the package (it is the version of interface, not the version of the package implementation). So you definitely should not end up with something like '2.0-git'. I don't know if there are some non-numeric version numbers in existing packages, I doubt that, but you are right, I haven't found any documentation on the version format.

So I pushed a simple change which tests for '2.0' string equality, since there is no other Gtk package than 2.0 and 3.0 and no older-than-3.0 and not being 2.0 should ever appear.

However, this is just hack, workaround. I definitely do not commit myself to avoid using tonumber() at all in lgi codebase. So I'd suggest you to fix tonumber() in your environment, because I'm not sure what else can break (now or in the future).

from lgi.