gjs issueshttps://gitlab.gnome.org/GNOME/gjs/-/issues2024-03-13T03:42:24Zhttps://gitlab.gnome.org/GNOME/gjs/-/issues/606Strange warning messages in Uint8Array to guint8* marshalling2024-03-13T03:42:24ZPhilip ChimentoStrange warning messages in Uint8Array to guint8* marshallingIn the following example, the first call succeeds, while the other two log a critical (`g_output_stream_write: assertion 'buffer != NULL' failed`).
```js
import Gio from 'gi://Gio';
// Works
Gio.MemoryOutputStream.new_resizable().write(...In the following example, the first call succeeds, while the other two log a critical (`g_output_stream_write: assertion 'buffer != NULL' failed`).
```js
import Gio from 'gi://Gio';
// Works
Gio.MemoryOutputStream.new_resizable().write(new Uint8Array([0]), null)
// I can't think of a use-case, but should be valid?
Gio.MemoryOutputStream.new_resizable().write(new Uint8Array([]), null)
// Zero-length string, I think should equate to new Uint8Array([0])
Gio.MemoryOutputStream.new_resizable().write('', null)
```
It seems like if we explicitly pass a zero-length buffer in GJS, it should not translate to a null pointer in C.
The string conversion is maybe not so odd if you assume that the second call is already broken. It probably translates to a zero-length buffer, since JS strings are not zero-terminated.https://gitlab.gnome.org/GNOME/gjs/-/issues/603Support flat C array return values2024-03-11T03:59:45ZPhilip ChimentoSupport flat C array return valuesFollowing up from #601.
We support flat C arrays, but only of `GValue`. Trying to call a function that returns a flat C array of any other type, throws an exception referencing this issue.
Reproducer:
```js
import GTop from 'gi://GTop'...Following up from #601.
We support flat C arrays, but only of `GValue`. Trying to call a function that returns a flat C array of any other type, throws an exception referencing this issue.
Reproducer:
```js
import GTop from 'gi://GTop';
const buf = new GTop.glibtop_mountlist();
const mountlist = GTop.glibtop_get_mountlist(buf, 0);
```
(`glibtop_get_mountlist` seems like an awkward API with the in-out buffer, though, and requires an external dependency; so any better examples of an API like this inside e.g. Gio would be appreciated)
For reference, introspection data:
```xml
<return-value transfer-ownership="full">
<array c:type="glibtop_mountentry*">
<type name="glibtop_mountentry" c:type="glibtop_mountentry"/>
</array>
</return-value>
```
Probably the best way to implement this is to take the existing special-case support for GValue flat arrays and generalize it to any struct. The complication will be that by not special-casing a struct with a size known at compile time, the size of the struct will only be known at runtime.
The code for this is in `gjs_array_from_zero_terminated_c_array()` in the `glibtop_get_mountlist` case, but will also need to be supported elsewhere.
gobject-introspection contains tests for GValue flat arrays. Check if they cover all the kinds of array (zero-terminated, fixed-length, length-parameter) as well as transfer (full, none; container doesn't seem to apply here) and check that we support in and out parameters as well as return values (inout doesn't seem to apply here.)https://gitlab.gnome.org/GNOME/gjs/-/issues/574Constructing a typedef/alias fails2024-03-16T06:10:21ZBilal Elmoussaouibil.elmoussaoui@gmail.comConstructing a typedef/alias failsFor example Gtk exposes GtkAllocation as an alias to GdkRectangle; but trying to construct a GtkAllocation with
```js
new Gtk.Allocation();
```
would fail with `TypeError: Gtk.Allocation is not a constructor`
compared to
```js
new Gdk....For example Gtk exposes GtkAllocation as an alias to GdkRectangle; but trying to construct a GtkAllocation with
```js
new Gtk.Allocation();
```
would fail with `TypeError: Gtk.Allocation is not a constructor`
compared to
```js
new Gdk.Rectangle();
```
which works as expected.
I would expect that the constructor is mapped for the aliased type as well as any function the aliased type has.https://gitlab.gnome.org/GNOME/gjs/-/issues/557Connecting to signal of a GstElement errors with "too much recursion"2024-03-12T05:39:06ZRaihanConnecting to signal of a GstElement errors with "too much recursion"# System information #
OS = ArchLinux
gjs version = 1.76.2
# Bug information #
## Steps to reproduce ##
Run this code
```
const { Gst, GLib } = imports.gi;
Gst.init(null);
const pipelineStr = 'pulsesrc ! audioconvert ! audio/x-raw,form...# System information #
OS = ArchLinux
gjs version = 1.76.2
# Bug information #
## Steps to reproduce ##
Run this code
```
const { Gst, GLib } = imports.gi;
Gst.init(null);
const pipelineStr = 'pulsesrc ! audioconvert ! audio/x-raw,format=S16LE,rate=44100,channels=2 ! appsink name=analysis_sink caps=audio/x-raw,format=S16LE,rate=44100,channels=2 emit-signals=true';
const pipeline = Gst.parse_launch(pipelineStr);
const analysisSink = pipeline.get_child_by_name('analysis_sink');
function analyzeAudio(appsink, data) {
console.log('trying to pull buffer');
return Gst.FlowReturn.OK;
}
analysisSink.connect('new-sample', analyzeAudio);
pipeline.set_state(Gst.State.PLAYING);
const mainLoop = GLib.MainLoop.new(null, false);
mainLoop.run();
pipeline.set_state(Gst.State.NULL);
```
## Current behaviour ##
```
(gjs:4083): Gjs-CRITICAL **: 16:13:57.039: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.049: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.059: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.069: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.079: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.089: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.099: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.109: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.119: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.129: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.139: JS ERROR: too much recursion
@test.js:13:10
(gjs:4083): Gjs-CRITICAL **: 16:13:57.149: JS ERROR: too much recursion
@test.js:13:10
```
## Expected behaviour ##
The callback function should be called.https://gitlab.gnome.org/GNOME/gjs/-/issues/501Implement overrides for functions that accept mutable buffers2024-03-12T04:55:44ZAndy HolmesImplement overrides for functions that accept mutable buffersAs discussed on !787, it may be possible to implement overrides for functions that accept mutable buffers, whereas this was not possible with the older custom `ByteArray` implementation.
An example of a function is [`Gio.InputStream.rea...As discussed on !787, it may be possible to implement overrides for functions that accept mutable buffers, whereas this was not possible with the older custom `ByteArray` implementation.
An example of a function is [`Gio.InputStream.read_all_async()`](https://gjs-docs.gnome.org/gio20/gio.inputstream#method-read_all_async), which has a signature of:
```js
/**
* @param {Number} count - max bytes to read
* @param {Number} priority - e.g. GLib.PRIORITY_DEFAULT
* @param {Gio.Cancellable} cancellable - ...
* @param (Gio.AsyncReadyCallback} callback - ...
* @returns {Uint8Array}
*/
```
> Note that our DevDocs scraper doesn't properly document the above arguments, but that's another issue.
Assuming that signature is correct, there's a couple assumptions to make:
* `count` can be used to create a large enough `ArrayBuffer`
* For async functions like this, the user will not attempt to use the `Uint8Array` while it's being used in another thread
* The resulting `Uint8Array` is still usable if `count` is not reached, resulting in trailing NULL-bytes
* The caller of the function knows...
* if the result may have embedded NULL-bytes, and not be treated as a NULL-terminated string, etc
* if it is a string, that the buffer is large enough that the result *does* have a trailing NULL-byte (or our conversion functions can deal with that)
If this were implemented per-function, each override could be examined for "gotchas" like the above. If this were implemented as part of the "automatic" bindings, there may be some instances where the annotations are open-ended or ambiguous about `gchar *` vs `guint8 *`, for example.
I'm generally familiar with using such APIs in C, and working around the unintrospectable functions in GJS, but I don't have much hands-on experience with GObject-Introspection itself. So comments and corrections welcome :)https://gitlab.gnome.org/GNOME/gjs/-/issues/495Make GListModel iterable2024-03-12T04:50:32ZSonny Pierssonnyp@gnome.orgMake GListModel iterableGListModel is not iterable, so it's not possible to do
```js
const stack = new Gtk.Stack();
for (const page of stack.pages) {
}
```
It's been reported at least twice recently on the Matrix room
* https://matrix.to/#/!pOGgkAueAsusiyFCT...GListModel is not iterable, so it's not possible to do
```js
const stack = new Gtk.Stack();
for (const page of stack.pages) {
}
```
It's been reported at least twice recently on the Matrix room
* https://matrix.to/#/!pOGgkAueAsusiyFCTb:matrix.org/$16513227972738tLzPn:gnome.org?via=gnome.org&via=matrix.org&via=envs.net
* https://matrix.to/#/!pOGgkAueAsusiyFCTb:matrix.org/$1659596277176394Lcgiq:matrix.org?via=gnome.org&via=matrix.org&via=envs.net
I'd like to fix it, but given how inheritance works in GJS it's unclear to me how we can even do that, and this serves as reference as well.
An alternative would be to make `Gtk.SelectionModel` iterable at least for the use case of iterating `GtkStack`.
I did try the following as suggested by Philip but it doesn't work
```js
imports.gi.versions.Gtk = '4.0';
const {GLib, Gio, GObject, Gtk} = imports.gi;
Gtk.init()
// Copied from overries/Gio.js
// currently used for ListStore
function* _listModelIterator() {
let _index = 0;
const _len = this.get_n_items();
while (_index < _len)
yield this.get_item(_index++);
}
Gio.ListModel.prototype[Symbol.iterator] = _listModelIterator;
const stack = new Gtk.Stack();
log(stack.pages instanceof Gio.ListModel); // true
// TypeError: stack.pages is not iterable
for (let f of stack.pages) {
log(f)
}
```https://gitlab.gnome.org/GNOME/gjs/-/issues/480Gdk.ContentProvider.get_value() no longer accepts a GValue2022-07-07T22:12:03ZRomain VigierGdk.ContentProvider.get_value() no longer accepts a GValue# System information #
What is your operating system and version? GNOME Flatpak Platform 42
What is your version of GJS? 1.72.0
# Bug information #
## Steps to reproduce ##
```js
import Gdk from 'gi://Gdk?version=4.0';
import GObject ...# System information #
What is your operating system and version? GNOME Flatpak Platform 42
What is your version of GJS? 1.72.0
# Bug information #
## Steps to reproduce ##
```js
import Gdk from 'gi://Gdk?version=4.0';
import GObject from 'gi://GObject';
const value = new GObject.Value();
value.init(GObject.TYPE_STRING);
value.set_string('OK');
const provider = Gdk.ContentProvider.new_for_value(value);
const [ok, newValue] = provider.get_value();
console.log(newValue.get_string());
```
## Current behaviour ##
Trying to retrieve the value of a `Gtk.ContentProvider` throws several criticals:
```sh
$ flatpak run --command=gjs --filesystem=home org.gnome.Platform//42 -m test.js
(gjs:2): Gdk-CRITICAL **: 16:55:42.490: gdk_content_provider_get_value: assertion 'G_IS_VALUE (value)' failed
(gjs:2): GLib-GObject-CRITICAL **: 16:55:42.490: g_value_type_transformable: assertion 'src_type' failed
(gjs:2): GLib-GObject-CRITICAL **: 16:55:42.490: g_value_type_transformable: assertion 'src_type' failed
(gjs:2): Gjs-CRITICAL **: 16:55:42.490: JS ERROR: Error: Don't know how to convert GType (null) to JavaScript object
@file:///test.js:12:33
(gjs:2): Gjs-CRITICAL **: 16:55:42.490: Module file:///test.js threw an exception
```
## Expected behaviour ##
We should be able to tell the type of the GValue that should be returned, for example with `provider.get_value(GObject.TYPE_STRING`).
Interestingly, with GJS 1.70.2, the function signature is different, and we can pass it an already initialized GValue:
```js
import Gdk from 'gi://Gdk?version=4.0';
import GObject from 'gi://GObject';
const value = new GObject.Value();
value.init(GObject.TYPE_STRING);
value.set_string('OK');
const provider = Gdk.ContentProvider.new_for_value(value);
const newValue = new GObject.Value();
newValue.init(GObject.TYPE_STRING)
const _ok = provider.get_value(newValue);
console.log(newValue.get_string());
```
And that works as expected:
```sh
$ flatpak run --command=gjs --filesystem=home org.gnome.Platform//41 -m test.js
Gjs-Console-Message: 17:00:24.319: OK
```https://gitlab.gnome.org/GNOME/gjs/-/issues/478Warning when a custom widget with a layout manager is finalized, except when ...2024-03-12T04:34:04ZRomain VigierWarning when a custom widget with a layout manager is finalized, except when instantiated in a UI template# System information #
What is your operating system and version? GNOME 42 flatpak runtime
What is your version of GJS? 1.72.0
# Bug information #
## Steps to reproduce ##
- Create a custom GTK widget with a layout manager
- Instantiat...# System information #
What is your operating system and version? GNOME 42 flatpak runtime
What is your version of GJS? 1.72.0
# Bug information #
## Steps to reproduce ##
- Create a custom GTK widget with a layout manager
- Instantiate it in code
- Then instantiate it in a UI file
## Current behaviour ##
When instantiating the widget from code like this:
```js
import Gtk from 'gi://Gtk?version=4.0';
import GObject from 'gi://GObject';
const Widget = GObject.registerClass({
GTypeName: 'Widget',
Template: new TextEncoder().encode(
`<interface>
<template class="Widget">
<property name="layout-manager">
<object class="GtkBinLayout"/>
</property>
<child>
<object class="GtkLabel">
<property name="label">TEST</property>
</object>
</child>
</template>
</interface>`),
}, class extends Gtk.Widget {});
const Application = GObject.registerClass(
class extends Gtk.Application {
vfunc_activate() {
new Gtk.ApplicationWindow({
application: this,
child: new Widget()
}).present();
}
}
);
new Application().run(ARGV);
```
GTK prints these warnings:
```
(gjs:385324): Gtk-WARNING **: 22:14:04.695: Finalizing Widget 0x5613897f7150, but it still has children left:
(gjs:385324): Gtk-WARNING **: 22:14:04.695: - GtkLabel 0x5613897be330
```
However, when the same widget is instantiated in a UI template, like this:
```js
import Gtk from 'gi://Gtk?version=4.0';
import GObject from 'gi://GObject';
const Widget = GObject.registerClass({
GTypeName: 'Widget',
Template: new TextEncoder().encode(
`<interface>
<template class="Widget">
<property name="layout-manager">
<object class="GtkBinLayout"/>
</property>
<child>
<object class="GtkLabel">
<property name="label">TEST</property>
</object>
</child>
</template>
</interface>`),
}, class extends Gtk.Widget {});
const Window = GObject.registerClass({
GTypeName: 'Window',
Template: new TextEncoder().encode(`
<interface>
<template class="Window">
<property name="child">
<object class="Widget"/>
</property>
</template>
</interface>`)
}, class extends Gtk.ApplicationWindow {});
const Application = GObject.registerClass(
class extends Gtk.Application {
vfunc_activate() {
new Window({ application: this }).present();
}
}
);
new Application().run(ARGV);
```
No warnings are printed.
The difference really lies in the instantiation, as even when the widget is only instantiated and not added as the child of the window in the first example, warnings are still printed:
```js
vfunc_activate() {
new Widget();
new Gtk.ApplicationWindow({ application: this }).present();
}
```
## Expected behaviour ##
The warnings don't happen, or happen in both cases.
---
It might not be specific to GJS, as it happens as well in Python:
<details><summary>Python scripts</summary>
Warnings:
```python
import gi
import sys
gi.require_version("Gtk", "4.0")
from gi.repository import GObject, Gtk
@Gtk.Template(string="""
<interface>
<template class="Widget">
<property name="layout-manager">
<object class="GtkBinLayout"/>
</property>
<child>
<object class="GtkLabel">
<property name="label">TEST</property>
</object>
</child>
</template>
</interface>
""")
class Widget(Gtk.Widget):
__gtype_name__ = "Widget"
class Application(Gtk.Application):
def do_activate(self):
win = Gtk.ApplicationWindow(
application=self,
child=Widget()
)
win.present()
if __name__ == "__main__":
app = Application()
sys.exit(app.run(sys.argv))
```
No warnings:
```python
import gi
import sys
gi.require_version("Gtk", "4.0")
from gi.repository import GObject, Gtk
@Gtk.Template(string="""
<interface>
<template class="Widget">
<property name="layout-manager">
<object class="GtkBinLayout"/>
</property>
<child>
<object class="GtkLabel">
<property name="label">TEST</property>
</object>
</child>
</template>
</interface>
""")
class Widget(Gtk.Widget):
__gtype_name__ = "Widget"
@Gtk.Template(string="""
<interface>
<template class="Window">
<property name="child">
<object class="Widget"/>
</property>
</template>
</interface>
""")
class Window(Gtk.ApplicationWindow):
__gtype_name__ = "Window"
class Application(Gtk.Application):
def do_activate(self):
win = Window(application=self)
win.present()
if __name__ == "__main__":
app = Application()
sys.exit(app.run(sys.argv))
```
</details>
The only different thing is that when instantiating the widget without adding to the window, the warning are immediately printed while in GJS they are only printed when the window is closed:
```python
def do_activate(self):
Widget()
win = Window(application=self)
win.present()
```https://gitlab.gnome.org/GNOME/gjs/-/issues/409Use Typed arrays for all the numeric types2021-05-06T00:08:28ZMarco Trevisanmail@3v1n0.netUse Typed arrays for all the numeric typesI think we could optimize things a bit by using typed arrays for all the supported numeric types.
And at least:
- [ ] When a typed array is used to call a C function, we could use `JS_GetObjectAs*Array` facility functions (or if more o...I think we could optimize things a bit by using typed arrays for all the supported numeric types.
And at least:
- [ ] When a typed array is used to call a C function, we could use `JS_GetObjectAs*Array` facility functions (or if more optimized using array buffers)
- [ ] C functions returned values should be exposed to JS using typed arrays created from buffers (should reduce copies).
- [ ] This may cause some API breaks though, as the object is not anymore `Array.isArray()` and functions like `map()` are returning a typed array as well, so not sure if this side should be only done when we'll do an API break.https://gitlab.gnome.org/GNOME/gjs/-/issues/402Creating a GObject.Value with a boxed type doesn't work2024-03-11T05:49:52ZMarco Trevisanmail@3v1n0.netCreating a GObject.Value with a boxed type doesn't workIt seems we end up in creating an empty GValue, so doing:
```js
const v = new GObject.Value();
v.init(GIMarshallingTests.BoxedStruct.$gtype);
v.set_boxed(new GIMarshallingTests.BoxedStruct()); // g_value_set_boxed is called with NULL bo...It seems we end up in creating an empty GValue, so doing:
```js
const v = new GObject.Value();
v.init(GIMarshallingTests.BoxedStruct.$gtype);
v.set_boxed(new GIMarshallingTests.BoxedStruct()); // g_value_set_boxed is called with NULL boxed parameter
v.get_boxed() // returned value is undefined!
```
While we've a crash (while we should probably fail earlier) with
```js
const v = new GObject.Value();
v.init_from_instance(new GIMarshallingTests.BoxedStruct());
```https://gitlab.gnome.org/GNOME/gjs/-/issues/392GTK4 accessible API has to be overridden2024-03-11T05:46:45ZabakGTK4 accessible API has to be overridden# Description #
It is required for attributes whose value is a list.
`widget.update_property([Gtk.AccessibleProperty.LABEL], ['a label'])` works but
`widget.update_relation([Gtk.AccessibleRelation.LABELLED_BY], [[labelWidget1, labelWidg...# Description #
It is required for attributes whose value is a list.
`widget.update_property([Gtk.AccessibleProperty.LABEL], ['a label'])` works but
`widget.update_relation([Gtk.AccessibleRelation.LABELLED_BY], [[labelWidget1, labelWidget2]]` is not possible.
Note that there is a bunch of `gtk_accessible_..._init_value` to initialize the GValue with the type associated with an attribute.GNOME 47Evan Welshcontact@evanwelsh.comEvan Welshcontact@evanwelsh.comhttps://gitlab.gnome.org/GNOME/gjs/-/issues/323Can't use Gtk.Window.propagate_key_event(), etc.2020-05-31T19:51:04ZJohn FactotumCan't use Gtk.Window.propagate_key_event(), etc.# System information #
What is your operating system and version? Arch Linux
What is your version of GJS? 1.64.2
# Bug information #
## Steps to reproduce ##
```js
imports.gi.versions.Gtk = '3.0'
const { Gtk } = imports.gi
Gtk.init(nul...# System information #
What is your operating system and version? Arch Linux
What is your version of GJS? 1.64.2
# Bug information #
## Steps to reproduce ##
```js
imports.gi.versions.Gtk = '3.0'
const { Gtk } = imports.gi
Gtk.init(null)
const win = new Gtk.Window()
win.connect('key-press-event', (win, event) => {
win.propagate_key_event(event)
})
win.show_all()
Gtk.main()
```
Then press any key.
Also happens with `Gtk.Window.activate_key()` and `Gtk.bindings_activate_event()`.
## Current behaviour ##
```
(gjs:4487): Gjs-WARNING **: 11:44:27.236: JS ERROR: TypeError: Object 0x14e7de388e50 is not a subclass of GObject_Boxed, it's a GObject_Union
```
## Expected behaviour ##
Should be able to pass the event without errors.https://gitlab.gnome.org/GNOME/gjs/-/issues/311Follow-up from "Don't crash if a callback doesn't return an expected array of...2020-03-28T04:02:38ZPhilip ChimentoFollow-up from "Don't crash if a callback doesn't return an expected array of values"The following discussion from !405 should be addressed:
- [ ] @ptomato started a [discussion](https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/405#note_746534): (+2 comments)
> Well, I figured out why this is. The result of `JS...The following discussion from !405 should be addressed:
- [ ] @ptomato started a [discussion](https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/405#note_746534): (+2 comments)
> Well, I figured out why this is. The result of `JS::ToNumber()` on `undefined` is NaN. The return type of this vfunc is `glong` whereas the other vfuncs that return NaN are all `gfloat`, so that's why we get NaNs returned from all the other functions but not here. I suspect (from testing on godbolt) that the compiler is converting NaN to 64-bit int with `cvttsd2si` on x86-64, and that's where the value of –9223372036854775808 (0x8000000000000000) is coming from.
>
> Since this vfunc returns a glong, there's no way we can ever get a NaN from it. So I think it's sufficient to change this expectation to `.toBeDefined()` or something like that.
>
> This was pre-existing, however, with this merge request we are now introducing an inconsistency: we get 0x8000000000000000 if we return undefined as a lone integer return value, and 0 if we return undefined as one of multiple integer return values, as in `vfunc_return_value_and_multiple_out_parameters`. I think it's probably worth fixing this. Alternatively, I could be convinced that not returning the correct type from your vfunc is undefined behaviour as far as GJS is concerned, in that case we can just un-pend the test and expect the log message about the value being outside the range of a JS Number.
- @3v1n0:
> Ok, I've changed it to use `.toBeDefined()`, however you're right that this MR exposes an inconsistency (more than introducing it I think), given that this was already the behavior.
>
> So, I'm not sure how to fix that though, so given the MR was to focus on non-crashing mostly, maybe we can leave the two "simple `return undefined`" cases as `pend` in case we know how to make them behave the same way, and address it somewhere else.https://gitlab.gnome.org/GNOME/gjs/-/issues/275Fix bad memory management in vfunc marshalling2020-09-03T21:04:25ZPhilip ChimentoFix bad memory management in vfunc marshallingThe gobject-introspection test suite contains some tests that test memory management of values that are passed into or returned from vfuncs: https://gitlab.gnome.org/GNOME/gobject-introspection/blob/a62855702c3bc0b10370ef25d622a32e227283...The gobject-introspection test suite contains some tests that test memory management of values that are passed into or returned from vfuncs: https://gitlab.gnome.org/GNOME/gobject-introspection/blob/a62855702c3bc0b10370ef25d622a32e227283bd/tests/gimarshallingtests.c#L4713-4864
We have some memory problems with two of the six cases:
- [x] return value, transfer-none
- [x] return value, transfer-full
- [x] out parameter, transfer-none
- [x] out parameter, transfer-full: ~~the object is unrefed when it's not supposed to be, and crashes at the next GC with a double free~~
- [x] in parameter, transfer-none
- [ ] in parameter, transfer-full: ~~crashes~~ leaks the argument
Verify the fix by un-disabling the tests in testGIMarshalling.js and checking that it passes correctly.https://gitlab.gnome.org/GNOME/gjs/-/issues/273Support accessing fields of unions2024-03-11T05:28:53ZPhilip ChimentoSupport accessing fields of unionsIt seems like it should be feasible to allow accessing the fields of unions, at least for reading. It's a reasonably common question (at least, I've seen it a few times) from beginners why the fields of [`Gdk.Event`](https://gjs-docs.gno...It seems like it should be feasible to allow accessing the fields of unions, at least for reading. It's a reasonably common question (at least, I've seen it a few times) from beginners why the fields of [`Gdk.Event`](https://gjs-docs.gnome.org/gdk30~3.24.8/gdk.event) aren't accessible in JS.Marco Trevisanmail@3v1n0.netMarco Trevisanmail@3v1n0.nethttps://gitlab.gnome.org/GNOME/gjs/-/issues/272Fix GValue roundtripping2022-06-29T05:23:35ZPhilip ChimentoFix GValue roundtrippingIn the gobject-introspection test suite we have this test:
```c
/**
* gi_marshalling_tests_gvalue_flat_array_round_trip:
* @one: The first GValue
* @two: The second GValue
* @three: The third GValue
*
* Returns: (array fixed-size=3...In the gobject-introspection test suite we have this test:
```c
/**
* gi_marshalling_tests_gvalue_flat_array_round_trip:
* @one: The first GValue
* @two: The second GValue
* @three: The third GValue
*
* Returns: (array fixed-size=3) (transfer full): a flat array of [@one, @two, @three]
*/
GValue* gi_marshalling_tests_gvalue_flat_array_round_trip (const GValue one, const GValue two, const GValue three);
```
When executed in JS,
```js
const out = GIMarshallingTests.gvalue_flat_array_round_trip(42, '42', true);
```
We get the following exception thrown:
> Don't know how to convert gtype gchar to Javascript object
It seems like we should adjust the type-guessing when we convert JS values to GValues so that at least the same JS value can later be extracted from the GValue.
Verify the fix by un-disabling the test in testGIMarshalling.js and making sure it passes correctly.https://gitlab.gnome.org/GNOME/gjs/-/issues/271Fix introspected (u)int64 types to use BigInt2024-03-11T05:27:16ZPhilip ChimentoFix introspected (u)int64 types to use BigIntOne long-standing problem with GJS is that 64-bit integers can be exposed by gobject-introspection, but JS Numbers only support integers up to 53 bits (the largest integers that can be stored losslessly in a double). Since some time ago ...One long-standing problem with GJS is that 64-bit integers can be exposed by gobject-introspection, but JS Numbers only support integers up to 53 bits (the largest integers that can be stored losslessly in a double). Since some time ago we have logged a warning whenever an integer larger than `Number.MAX_SAFE_INTEGER` is received from C. For example:
```
gjs> imports.gi.GLib.MAXINT64
(gjs:1408): Gjs-WARNING **: 14:40:01.550: Value 9223372036854775807 cannot be safely stored in a JS Number and may be rounded
9223372036854776000
```
In SpiderMonkey 68 we are getting BigInt, which could be used to solve this problem. We will have to figure out how to expose this to GJS code in a backwards-compatible way, though.
For input arguments it's simple: accept both Numbers and BigInts for a 64-bit int parameter. For output arguments, though, you have to choose which one to return. All options have drawbacks:
- Always return Numbers (current behaviour): retains the current problems.
- Always return BigInts: it will be backwards incompatible, as `2n + 2` will throw an exception.
- Return Number if the value is safe, and BigInt if it isn't: it is arguably backwards compatible, if we consider the case where you get the wrong value to be broken, sometimes returning one type and sometimes another type seems like a nightmare for API consumers.
Blocked by:
- #270GNOME 41Marco Trevisanmail@3v1n0.netMarco Trevisanmail@3v1n0.nethttps://gitlab.gnome.org/GNOME/gjs/-/issues/210Strange behavior in GObject.param_values_cmp and GObject.param_value_validate2024-03-11T05:20:28ZMartin Abente LahayeStrange behavior in GObject.param_values_cmp and GObject.param_value_validateSee the example below:
```javascript
const {GObject, Gtk} = imports.gi;
Gtk.init(null);
const w = new Gtk.Box();
const pspec = GObject.Object.find_property.call(w.constructor.$gtype, 'visible');
print(pspec);
print(pspec.default_value...See the example below:
```javascript
const {GObject, Gtk} = imports.gi;
Gtk.init(null);
const w = new Gtk.Box();
const pspec = GObject.Object.find_property.call(w.constructor.$gtype, 'visible');
print(pspec);
print(pspec.default_value);
print(GObject.param_value_validate(pspec, pspec.default_value)); // false, which is not correct
print(GObject.param_values_cmp(pspec, pspec.default_value, true)); // -1 , which is correct
print(GObject.param_values_cmp(pspec, pspec.default_value, false)); // 0, which is correct
print(GObject.param_values_cmp(pspec, pspec.default_value, 'true')); // 0, which is not correct
```
`GObject.param_values_cmp` will behave strangely if the given values types are not strictly the same type as the one defined in the pspec. E.g. in the code above, false (boolean) returns zero, but 'true' (string) also returns zero.
Even if I try to mix it with `GObject.param_value_validate`, this function always return 'false', even for the pspec default value.https://gitlab.gnome.org/GNOME/gjs/-/issues/184Allow using async functions as signal handlers2024-03-11T05:14:16ZPhilip ChimentoAllow using async functions as signal handlersUsing an async function as a signal handler works, but logs a (mostly harmless) warning.
Here's a minimal script to illustrate the problem:
```js
const {GObject} = imports.gi;
const MyClass = GObject.registerClass({
Signals: {
...Using an async function as a signal handler works, but logs a (mostly harmless) warning.
Here's a minimal script to illustrate the problem:
```js
const {GObject} = imports.gi;
const MyClass = GObject.registerClass({
Signals: {
signal: {},
},
}, class MyClass extends GObject.Object {
go() {
this.emit('signal');
}
});
const obj = new MyClass();
obj.connect('signal', async function (obj) {});
obj.go();
```
This prints:
```
(gjs:340): Gjs-WARNING **: 16:11:40.962: JS ERROR: Error: Could not guess unspecified GValue type
go@bug.js:9:9
@bug.js:15:1
```
although it does execute normally.
It's because the async function returns a Promise under the hood, which GJS tries to convert to the signal's return type of `GObject.TYPE_NONE`, which causes the warning. (If you comment out the `async` keyword, everything works normally.)
I think we should detect this particular case (signal with "none" return type, handler returns a Promise) and silently discard the return value, which would allow async functions to be used as handlers for signals that don't expect a return value. The Promise will just continue executing and eventually reach any code after an `await` expression in the handler.
We should not allow this for signals with return types, because an async function can _only_ return a Promise, and not any other return type that the signal expects.https://gitlab.gnome.org/GNOME/gjs/-/issues/109Boxed types with pointers cannot be created: "no way to copy"2022-07-27T17:37:35ZBugzillaBoxed types with pointers cannot be created: "no way to copy"## Submitted by Lester Carballo Pérez `@lestcape`
**[Link to original bug (#786863)](https://bugzilla.gnome.org/show_bug.cgi?id=786863)**
## Description
Is really annoying to see that we can not access to a function using introspect...## Submitted by Lester Carballo Pérez `@lestcape`
**[Link to original bug (#786863)](https://bugzilla.gnome.org/show_bug.cgi?id=786863)**
## Description
Is really annoying to see that we can not access to a function using introspection inside Gjs in some context, while we can access using python. I think, if in python this is possible, probably there are a way to handled this types of problems inside Gjs.
An example also inside a gnome library can be found here:
https://bugzilla.gnome.org/show_bug.cgi?id=783578
Not matter who cause it, or if it is the right or the wrong way to provide the introspection to a library, because in Python there are not a problem to access the opaque structure.
I think then this is a problem in both sides then