GitLab

Dockerfile: Install Turkish locale in CI for UTF-8 locale too

See merge request !743

This is the actual recipe that has been used to generate the current
image, but I forgot to update the branch that got merged earlier.

gi: fix the usage of closure in CallbackIn::release

Closes #479

See merge request !740

jsapi-util-strings: Ignore locale to compute the upper case of a char (i.e. fix implicit properties on Turkish locale)

See merge request !742

We used to compute camel-case name of properties using toupper(),
however this is locale-dependent, while in this case we want to be sure
that we're only using ASCII values.

This is particularly problematic in Turkish (and maybe other locales)
because there 'i'.toLocaleUpperCase() is 'İ', that is definitely not an
ASCII char, causing problems to with our generated properties.

See: https://github.com/micheleg/dash-to-dock/issues/1687

We were getting closure pointer from in_arg.  Unfortunately, in_arg
contains the native closure pointer, which does not equals to of the
pointer to ffi_closure if libffi is built without
`--disable-exec-static-tramp`.

I guess gjs has never been really tested with such a libffi build :).

Add support for JS async calls in DBusProxyWrapper

See merge request GNOME/gjs!731

Currently, DBusProxyWrapper dynamically creates two methods for
each method available in the DBus interface: one with the suffix
Sync (which blocks the calling thread until the call returns),
and another with the suffix Remote (which accepts a callback,
called when the DBus calls returns).

Since GJS has support for async/await, it is a good idea to use
them for DBus. Unfortunately, that means creating some plumbing
using Promises. It is not complex, but it is a repetitive task.

This MR fixes this by adding a third method, suffixed with
Async, that returns a Promise that calls the DBus method and
returns the result with `resolve` (or `reject` if an error
occurs). This allows to call a DBus method from an async
function and wait for the result using `await`.

Handle reference cycles in pretty print function

Closes #469

See merge request !739

value: Fix compilation error on Darwin

Closes #473

See merge request GNOME/gjs!738

Evan Miller authored Mar 18, 2022 and Philip Chimento committed Mar 18, 2022

Same gint64/int64_t type mismatch on Darwin (long vs long long) as the
previous commit.

Evan Miller authored Mar 18, 2022 and Philip Chimento committed Mar 18, 2022

It looks like this is due to a gint64/int64_t type mismatch on Darwin
(long vs long long), at least using GLib 2.66. This patch seems to fix
the immediate issue.

Closes: #473

gi: Use new GObject Introspection callable API

Closes #428

See merge request GNOME/gjs!737

This avoids misusing the closure pointer by creating a clear
separation between the native closure pointer and the pointer
to the libffi closure.

Fixes #428

Unreviewed, pushing to fix build.

Verbose object print output

Closes #107

See merge request GNOME/gjs!587

March maintenance

See merge request GNOME/gjs!736

February maintenance

See merge request GNOME/gjs!735

package: Reverse order of running-from-source checks

See merge request GNOME/gjs!734

Only the type tag information is used here, so there's no need to require
the type info pointer. This allows refactoring to call this function from
places where we don't have the type info pointer available.

This function doesn't need the whole GITypeInfo, just the type tag. This
refactor allows reusing it in a separate code path for basic types that
are only identified by their type tag.

This function doesn't need the whole GITypeInfo, just the type tag. This
refactor allows reusing it in a separate code path for basic types that
are only identified by their type tag.

This g_return_val_if_fail() was incorrect because if
value_to_ghashtable_key() returns false, an exception must be pending.

However, the condition never fails because object property keys can only
be int32, string, or symbol; and JS_Enumerate() iterates over all
enumerable non-symbol property keys. At this point it's only possible to
have an int32 or string key, so change the check to an assertion, and add
a marshalling test ensuring that symbol keys are ignored.

If JS_HasPropertyById fails, then it's likely because of an exception
thrown in a proxy trap or something weird like that. Don't try to throw
another exception over top of that; it would be confusing if the user
received an exception that seemed to suggest the property wasn't there.

Clutter as a standalone library is being retired.
https://discourse.gnome.org/t/retiring-clutter-and-friends/8949

Per https://github.com/cpplint/cpplint/issues/190 cpplint is not intended
for that.

Bizarrely, if we construct ostringstream with a string already in it, the
default behaviour is to start overwriting characters at the start when
later inserting more text into the stream. If we don't want that, we have
to construct it with the 'advance to end' flag.

This is designed for this purpose, use it for conciseness instead of
Number.isNaN().