With the shell in nounset mode, an error is emitted on referencing
`schemadir` as it is not initialized in all code paths.
Initialize to an empty string to fix.
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
The source language of GLib is technically en-US, so we should
consistently use en-US spellings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3269
Some applications, toolkits or languages may define an alternative stack
to use for traces. This is for example the case of go.
So, in case an application defines an alternate signal stack, GLib should
use that instead of the default one to receive signals otherwise it may
break the application expectations and write where it's not allowed to.
The python interpreter found by `/usr/bin/env python3` is not
necessarily the same installation as the one that's found by meson's
`pymod.find_installation('python')`. This means that even though meson
is checking that the python installation it found includes the
'packaging' module, the scripts might not have access to that module
when run.
For distribution packaging, it's usually desirable to have python script
interpreters be fully specified paths, rather than use `/usr/bin/env`,
to ensure the scripts run using the expected python installation (i.e.
the one where the python 'packaging' dependency is installed).
The easiest way to fix this is to set the script interpreter to the
`full_path()` of the python interpreter found by meson. The specific
python interpreter that will be used can be selected through the use of
a meson machine file by overriding the "python" program. Many
distributions already have this set up using meson packaging helpers.
This fixes an issue with the number getting very big due to
CPU_ISSET not returning exactly 0 or 1.
This also fixes scenarios where there are holes in the CPU
set. E.g. for a simple run like `taskset --cpu-list 1,2,4 ...`
the old code would return 2 instead of 3, due to iterating
until `ncores` (which is 3) and therefore not accounting for
CPUs further in the set.
Ref https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3784
There are a lot of links to the description of I/O priority in the GIO
docs, and they’re all currently broken since the docs build was ported
to gi-docgen.
Use a simple find and replace (see below) to fix them. This doesn’t port
any of the surrounding docs to gi-docgen format, but should still
improve things overall.
```sh
git search-replace --fix '\[I/O priority\]\[io-priority\]///[I/O priority](iface.AsyncResult.html#io-priority)'
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
This is put together through git archaeology:
```
git log -- glib/tests/dataset.c
```
The following commits were too trivial to have meaningful copyright:
- 1a2c5e155d
- ea06ec8063
- 0178402c6d
- e3d1869ee3
- c34cc2348c
- d15e6f7c9c
- de8672fe0b
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The dataset tests are using a subprocess to catch possible deadlocks
within the `test_datalist_clear()` test. However, that’s causing
occasional spurious test failures on the slower CI runners, where the
subprocess can take longer than 500ms to run due to the machine being
overloaded.
Remove the subprocess from the test, and allow the test to deadlock if
it fails. The Meson test harness has a timeout for catching things like
this.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
g_file_copy_async() and g_file_move_async() are written in a way that is
not bindable with gobject-introspection. The progress callback data can
be freed once the async callback has been called, which is convenient
for C, but in language bindings the progress callback closure is
currently just leaked.
There is no scope annotation that fits how the progress callback should
be treated:
- (scope call) is correct for the sync versions of the functions, but
incorrect for the async functions; the progress callback is called
after the async functions return.
- (scope notified) is incorrect because there is no GDestroyNotify
parameter, meaning the callback will always leak.
- (scope async) is incorrect because the callback is called more than
once.
- (scope forever) is incorrect because the callback closure could be
freed after the async callback runs.
This adds g_file_copy_async_with_closures() and
g_file_move_async_with_closures() for the benefit of language bindings.
See: GNOME/gjs#590
For those projects that cannot use `g_autoptr()`, GStrvBuilder's end
plus unref is not really convenient.
We can crib the "unref to data type" model from GBytes, and have an
additional unref function that also returns the just built GStrv.
If our GPollFunc is set to g_poll() then we can optionally use a poll()
alternative with higher precision. ppoll() provides poll() equivalence
but with timeouts in nanoseconds.
With more precise polling timouts, frame clocks and other timing sensitive
APIs are not restricted to a minimum of 1 millisecond timeout.
