| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We don't build with this option very often, so this has been broken for a
while.
Closes: #196
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When caching the properties param specs we get them from the class object, which
is currently owning them, however since we're caching them we should add a
reference to them in order to keep the ownership and clean them up properly
when the cache is destroyed
Fixes GNOME/gjs#213
|
| |
|
|
|
|
|
| |
Add an overloaded method to initialize a GjsAutoParam with with a reffed pspec.
This helps to ref param specs we're consuming.
Fixes GNOME/gjs#213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It happens sometimes in the case of an array out argument with a
separate length argument, that C code passess a NULL array pointer with
garbage as the length.
In the particular case that caused the crash in the associated bug
report, gtk_selection_data_get_targets() passed NULL as the array
pointer and -1 as the length, which later got interpreted as an unsigned
int and so caused a failure to allocate memory.
I doubt that the C code should be doing this, but in any case we should
not crash in this case. This adds a check for this situation to
gjs_array_from_carray_internal() as well as to all the shortcuts and
special cases called from there.
Closes: #201
|
| |
|
|
|
|
|
|
|
| |
With the switch to mozjs60, the sweeping happens in three phases insted of two:
JSFINALIZE_GROUP_PREPARE, JSFINALIZE_GROUP_START, and JSFINALIZE_GROUP_END.
Update the code to keep track of whether the runtime is currently doing GC
sweeping, and prevent calling JS code at that time.
Fixes: GNOME/gjs#212
|
| |
|
|
|
|
|
|
|
|
|
| |
Since the property refactor, write-only properties have not been working.
The problem was that a getter and setter function were not defined for
them, because is_gobject_property_name() did not consider them to be
properties. Now, the setter function works as normal while the getter
function just pretends a write-only property has the value of undefined.
The test is marked pending until a test is added to the
gobject-introspection test suite.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously, in the interactive interpreter, throwing a non-object
exception (for example, `throw 'foo';`) would crash when trying to print
the exception value in the console.
This changes AutoReportException so that exceptions are handled better
when they are not objects.
|
| |
|
|
|
|
|
|
| |
Not a big deal, but found this bug while investigating some
problems that arose from https://gitlab.gnome.org/GNOME/mutter/merge_requests/260.
We should check if the GType is valid before using it, not
after.
|
| |
|
| |
We can use lower granularity as we care about seconds anyway
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit e9e969553, forced GC runs get queued very often in some
cases. For example, during the gnome-shell icon spring animation around
60% of gnome-shell's CPU time was spent in `trigger_gc_if_needed`.
That's too much.
We now defer the forced GC runs by 10 seconds, which provides two
significant performance benefits:
1. Animations triggering garbage collection are unlikely to have their
performance adversely affected by the run because the animation
will be finished before it starts.
2. The total number of garbage collection runs is much lower because
they're more likely to have been batched into the same run.
This has the observed benefit, for example, of reducing the CPU usage
of the gnome-shell icon spring animation from 78% to 47% on an i7-7700
(a 40% relative reduction).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/582
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously there was code that would intentionally crash if more than 7
minutes elapsed, in case the tests got stuck on autobuilders. This code
is more harmful than helpful, see the following table:
Times it has killed a stuck test on GitLab: . . . . . . . . 0
Times it has killed a JS_GC_ZEAL test: . . . . . . . . . 34
Times it has killed my GDB session because I forgot
to add the stupid environment variable: . . . . . . . . 478
|
| |
|
|
|
| |
This was necessary because some test code used to use GUnixOutputStream,
but it no longer does.
|
| |
|
|
| |
A few bugs have been fixed upstream.
|
| |
|
|
|
|
| |
I noticed that this apostrophe causes a warning while compiling the
conftest program. The text of this error message really doesn't matter,
so just remove the apostrophe.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In MozJS 60, only using entry.label() is not enough to give
meaningful Sysprof entries, since it might be an empty string
in various cases. This gives many empty entries in Sysprof,
making the profiler not as useful.
As per upstream MozJS, in version 60, the final string is a
combination of entry.label() and entry.dynamicString(). In [1],
however, the dynamic string is conditionally added depending
on a privacy toggle - which is not really the case with GJS
since enabling the profiler isn't possible without a large
control over the software stack, and opting in.
Thus, use entry.dynamicLabel() as an additional source of
information when saving the profiling labels, with enough
care to not allocate new strings while there.
[1] https://hg.mozilla.org/releases/mozilla-esr60/rev/768e500ad190
|
| |
|
|
|
|
| |
This was a use of the old ByteArray API that hadn't been updated.
Closes: #202
|
| |
|
|
|
|
|
|
|
|
|
|
| |
JS classes accept names that aren't valid GType names. Usually this
is something the programmer can take into account, however sometimes
a parent class isn't under their control and can therefore change
unexpectedly (gnome-shell extensions are a primary example).
Handle this case gracefully by replacing any invalid characters with
underscores.
https://gitlab.gnome.org/GNOME/gjs/merge_requests/229
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
byteArray: Add compatibility toString property
See merge request GNOME/gjs!227
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This overrides, on each Uint8Array returned from an introspected function
or from ByteArray.fromString() or ByteArray.fromGBytes(), the toString()
property with a compatibility shim that preserves the old behaviour of
ByteArray.prototype.toString() while logging a compatibility warning
asking people to fix their code.
This ByteArray.toString() -> Uint8Array.toString() change has had more
fallout in application code than I expected, so it seems better to
preserve backwards compatibility. (The old behaviour was to decode the
byte array into a string with default encoding UTF-8, and the default
behaviour of Uint8Array is to return a string with the decimal digits of
each byte joined with commas. So the effect was that strings like
"97,98,99,100" would show up in UIs where previously "abcd" would have
been printed.
This is only on specific instances, so Uint8Array.prototype.toString()
remains untouched.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds a framework for deprecation warnings. It consists of an enum of
deprecated features, and the API _gjs_warn_deprecated_once_per_callsite()
which warns only once in each place the feature is used, even if that
code is executed more than once.
This is meant to be joined in the future by _gjs_warn_deprecated_once()
and _gjs_warn_deprecated_once_per_file(), since we have unconditional
deprecation warnings elsewhere in GJS that could very well use those
APIs.
|
| | | |
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The _promisify function is a new internal feature for GJS, providing
developers the option to write asynchronous operations with either
the original callbacks from GNOME's original C (using GObject)
libraries or to write them using async/await, a new modern way to
write asynchronous code in JavaScript. This feature hides all of the
original callbacks from developers in a Promise, allowing one to call
the _async function like a variable by calling it with await in an async
function. This is a backwards compatible feature, thus it will not
impact already existing code using callbacks.
Please note that if you use this feature, to be ready for the official
API version coming out in 3.32 where slight changes to your code will
be necessary (in a good way, you can remove an extra line or two of
your code)!
To use this feature, instead of nesting your _async and _finish function
in your code (e.g. load_contents_async, load_contents_finish), you can
update your program to an "async function", and call the _async function
with an await leading it. You will also need to call the feature in your
program, too, until the 3.32 release.
Example:
Gio._promisify(..., 'load_contents_async', 'load_contents_finish');
let [raw_content] = file.load_contents_async(cancellable);
|
| |\ \
| |/
|/|
| |
| | |
Temporary fix for Gio.File.prototype
See merge request GNOME/gjs!226
|
| |/
|
|
|
|
|
|
|
|
|
| |
Issue #189 details the current dilemma of being unable to add or
monkeypatch methods on a GObject interface. At this time developers
must add an additional line of code to their applications to use
Gio.File.prototype. This is a temporary fix faking it until such a
fix has been made for that issue.
Example:
promisify(Gio._LocalFilePrototype, load_contents_async, load_contents_finish);
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Fix --enable-installed-tests when built from a tarball
See merge request GNOME/gjs!224
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise running
make distcheck DISTCHECK_CONFIGURE_FLAGS=--enable-installed-tests
fails because installed-tests/debugger/*.test are still in present
in the $(builddir) after distclean.
These files are created by 'make', so they should be deleted by
'make clean', not by 'make distclean'.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
| |/
|
|
|
|
|
|
| |
Otherwise you can't build a dist tarball with --enable-installed-tests.
Reproducible with:
make distcheck DISTCHECK_CONFIGURE_FLAGS=--enable-installed-tests
Signed-off-by: Simon McVittie <smcv@debian.org>
|
| |\
| |
| |
| |
| | |
Fix more "lost" GInterface properties
See merge request GNOME/gjs!223
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit 12ace06a6, we lazily resolve interface properties of
non-introspected GObjects. However we also lazily resolve properties
on introspected GObjects we didn't create ourselves - we need to
take interface properties into account there as well.
https://gitlab.gnome.org/GNOME/gjs/merge_requests/223
|
| |/
|
|
|
|
|
|
|
|
|
| |
There's a difference between objects we create ourselves from JS
code and objects we receive from introspected C code. Test that
we still find all valid properties in that case, either from the
object itself, a parent or an interface.
The latter currently fails, a fix will follow.
https://gitlab.gnome.org/GNOME/gjs/merge_requests/223
|
| |\
| |
| |
| |
| | |
Fix example eslint errors
See merge request GNOME/gjs!207
|
| | |
| |
| |
| | |
As discussed in the code review of !207.
|
| | |
| |
| |
| |
| | |
Run `eslint --fix examples --format unix`. Examples don't have a real
history, so that is acceptable.
|
| |/
|
|
|
|
|
| |
Add some eslint rules, and disable the clang-format rules for JS as they
are getting too incompatible with eslint.
[skip eslint] as this will change the eslint outcome.
|
| |\
| |
| |
| |
| | |
CI: add webkit and gtk-app tests
See merge request GNOME/gjs!222
|
| |/ |
|
| | |
|
| | |
|
