Issues with Proc & GObject::Callback

[GeopJr]

Hi, I'm having some issues with JavaScriptCore bindings (https://github.com/GeopJr/JavaScriptCore.cr):

• Proc

For example, JavaScriptCore::ClassVTable#get_property= accepts JavaScriptCore::ClassGetPropertyFunction (which is an alias for Proc(JavaScriptCore::Class, JavaScriptCore::Context, Pointer(Void)?, JavaScriptCore::Value)) generates:

def get_property=(value : JavaScriptCore::ClassGetPropertyFunction)
      _var = (to_unsafe + 0).as(Pointer(Void*))
      _var.copy_from(value.to_unsafe, sizeof(LibJavaScriptCore::ClassVTable))
      value
end

but Proc#to_unsafe is not a method.

• GObject::Callback

Almost all callbacks are of type GObject::Callback which I'm unsure how to work with - even after some manual editing, I couldn't get past Error: argument 'getter' of 'LibJavaScriptCore#jsc_class_add_property' must be Pointer(Void) or invalid memory access.

Example code for the first issue:

require "javascriptcore"

JavaScriptCore::ClassVTable.new(
    get_property: JavaScriptCore::ClassGetPropertyFunction.new { |x, y, _| JavaScriptCore::Value.new_null(y) }
)

I understand if this is out of the scope of gi-crystal and I'll probably end up writing bindings manually if closed (as the api is not that big) 😅

Also surprised getter and setter work as method parameters

[hugopl]

Does JSCore have GIR information? GIR information for non-gobject based libraries are usually not good, maybe would be easier to try to use GJS instead?

[GeopJr]

It does have gir information (it's part of webkit2gtk / gobject based afaik), here's a copy of it https://gist.github.com/GeopJr/aae89878ad6b83f3c6233191a109e0eb

The shard works fine as per its readme, just some methods generated by gi-crystal dont. The crystal docs also turned out alright https://javascriptcore.geopjr.dev/JavaScriptCore/Context.html

[hugopl]

I didn't check this issue in detail yet, but maybe cccab764514634ac60e946fd2d9fd856e00f4e39 can help with it, it fixes callback signature generation.

[GeopJr]

Unfortunately both issues still exist from what I've gathered

[hugopl]

When passing a Proc to C libraries we usually need to put the Proc inside a Box, then store this Box object in the GICrystal::ClosureManager to avoid GC to delete it. Usually the problem is to know when to remove the Box from ClosureManager to let GC take care of the memory.

With the current implementation of signals we have a similar problem... if you connect an object to some signal and never disconnect this signal the object will never be collected by GC because there will always be a reference to it in the ClosureManager.