What is the difference between GMutex and GChecksum

This is a difficult language bindings question mostly for the experts Droege and Bassi.

https://developer.gnome.org/glib/stable/glib-Data-Checksums.html

https://developer.gnome.org/glib/stable/glib-Threads.html

For the “heavy” entities like Widgets, other GObject based objects or structs like GChecksum we are using proxy objects in Nim. For the gobject based ones we use the toggle-ref stuff, others are processed as gtk-boxed types. All that seems to work fine with automatic memory handling.

But then there are the simple structs like GCond, GMutex, Rectangle, TextIter and many more which are generally allocated on the stack in C code. These types need no special initialization, filling with plain binary zero is sufficient. For these types we do not really need proxy objects in Nim. Nim can allocate them on the stack in the same way as C can, so no need for advanced memory management. And even when these types are embedded in Nim’s objects it works the same, no proxy needed.

All fine, but how can we differ these two classes by querying gobject-introspection?

Currently we have a list of the light stack allocated objects, see below. Works OK, but I recently noticed that GCond and GMutex was missing, which resulted in the fact that simple translating a C code example to Nim did not work out of the box. I added both to the list, regenerated bindings and it was working.

So the question is how I can find the light stack allocated objects automatically? Well, for the heavy symbols there may exist generator functions like gtk_button_new() which may not exist for the light entities. But is that a good way to differentiate the two classes, or is there a better way?

const callerAlloc: HashSet[string] = """
gobject.Value
gobject.ValueDataUnion
atk.Rectangle
pango.Color
gtk.PageRange
gdk.KeymapKey
glib.Error
glib.MarkupParser
glib.TimeVal
gtk.TextIter
gdk.Rectangle
gobject.SignalQuery
gobject.TypeQuery
gtk.TreeIter
gtk.StockItem
glib.String
rsvg.PositionData
rsvg.DimensionData
gdk.Color
gdk.Geometry
gtk.Border
atk.TextRectangle
gdk.RGBA
pango.Rectangle
gtk.Requisition
graphene.Size
graphene.Point
graphene.Point3D
graphene.Rect
graphene.Box
graphene.Sphere
graphene.Vec2
graphene.Vec3
graphene.Vec4
graphene.Quaternion
graphene.Quad
graphene.Matrix
graphene.Plane
graphene.Ray
graphene.Euler
#cairo.Matrix
cairo.Rectangle
cairo.RectangleInt
gsk.RoundedRect
glib.Mutex # we should try to detect these stack based types automatically!
glib.Cond
""".split.toHashSet

I wouldn’t bother adding bindings for GMutex and GCond and things like that. I’m sure you have API for exactly that as part of the Nim standard library already.

For detecting these, I guess you could notice that there is no constructor for them and also no get_type() function, but only _init() and _clear() functions.

You also usually see them as caller-allocates function parameters in the other API.

The fact is that people want to do sometimes low level stuff and that they expect that conversion of C code examples to Nim just works. We have the tool c2nim for that which does it mostly automatically. For example recently someone asked for libnice, which is really a low level lib. I converted a small C example for him, and that example contained GMutex and GCond, so I noticed the issue. See

Yes I have noticed that often caller-allocates attribute is used for the light entities. I also intended to look for non existing free() functions or constructors. get_type() is an interesting idea, I will investigate that. _init() and _clear() also. I was hoping for a more simple and exact way, had the hope that I simple missed it somehow, but OK then I will fallback to your solutions.

But wouldn’t it be better to use the Nim mutex/condition variables there instead? Sure, you can use the ones from GLib but that doesn’t seem very idiomatic :slight_smile:

In the Rust bindings we decide such things based on the existence of new()/free(), ref()/unref() and init()/clear() functions. Nothing based on get_type(), other than requiring it to exist for putting such values into GValues.

Yes.

But I have to admit that I do not know for what he intents to use libnice at all, and why for Windows 8.1. I just hope he will get something working.

I got similar requests for gstreamer support and for libvte, and I had no idea what the intent was. So I provided a minimal example based on C code. Unfortunately the people vanished soon. But at least for vte we have someone from France who still uses it.