| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
T22301
|
|/
|
|
|
|
|
|
|
| |
Adding a new license for every app that a uses
a different one from our list, it simply does
not scale. Therefore, always display the code
instead of the "Unknown license" text.
https://phabricator.endlessm.com/T22301
|
|\
| |
| | |
Fix broken tests
|
| |
| |
| |
| |
| |
| |
| |
| | |
This was sample code from the very beginning of this repository, I'm not
sure why it has persisted this long. In any case it uses the deprecated
g_test_trap_fork() so we may as well delete it.
https://phabricator.endlessm.com/T22827
|
|/
|
|
|
|
|
|
|
| |
g_test_trap_fork() is deprecated, and in some recent release it stopped
working with gtester --tap. We could track this down but an easy fix is
to switch to its replacement, g_test_trap_subprocess(). This fixes the
unit tests.
https://phabricator.endlessm.com/T22827
|
| |
|
|
|
|
|
|
|
|
|
| |
Nothing is using this. (The last users were eos-programming, stuck on an
old runtime; and eos-typing, defunct.)
As long as I'm removing SearchBox, may as well remove this too.
https://phabricator.endlessm.com/T20353
|
|
|
|
|
|
|
|
|
| |
This was used nowhere except in eos-knowledge-lib. We are going to make
many eos-knowledge-lib specific changes to it, so it's going to be
forked into there. After nothing uses it, it doesn't make sense to keep
it here given that we intend to slowly move away from using eos-sdk.
https://phabricator.endlessm.com/T20353
|
|
|
|
|
|
|
|
| |
Setting the width here can mean that the popup gets a different width
from the search box. Instead, we want it to match the search box's width
and ellipsize the label if there's not enough space.
https://phabricator.endlessm.com/T20352
|
| |
|
|
|
|
|
| |
If the output temporary file cannot be atomically renamed to its final
destination, we need to copy its contents.
|
|
|
|
|
|
|
|
| |
We don't depend on any specific Endless SDK symbols, and if we link
against the SDK library itself we end up enabling the profiling probes;
this means we may end up overwriting the profiling data we're trying to
open, if by any chance we have `EOS_PROFILE=capture:` in our environment
pointing to the profile data we're opening.
|
|
|
|
|
|
|
|
|
|
| |
If we're using eos-profile-diff in a CI infrastructure then we should
not be printing out data in a human readable format, as we may want to
interpret the output using scripts at a later point.
We can use JSON, instead, and allow redirecting the output to a file;
this way, we can store the output as an artifact, collect it, and parse
it later.
|
|
|
|
| |
Documenting CLI tools that we ship should be part of the API reference.
|
|
|
|
|
| |
Compares N probe data files and prints a quick overview with the average
timings of all the probes.
|
|
|
|
|
| |
Now that we have it, we can cut some common code from the convert and
show sub-commands.
|
|
|
|
|
|
|
| |
Both the convert and the show sub-commands for eos-profile have code to
turn a GVariant into a profile probe for the v1 of the format.
Let's move it out into its own internal utility function.
|
|
|
|
|
|
|
|
|
|
| |
If we want to perform additional analysis on a profile capture file it's
generally going to be easier to have it in a different format than a
GVDB binary blob, especially if we want to use tools that are written in
high level languages that may not have access to the GVDB API.
The simplest format we can convert to is JSON, which is structured and
easy to parse with other languages.
|
|
|
|
| |
This avoids having each command handle it differently.
|
|\
| |
| | |
T21027
|
|/
|
|
|
|
|
|
|
|
|
|
| |
When clicking on a result from the autocomplete popup, we should select
the first index of the tree path. (The list is a flat list, so there is
always only one index.)
This prevents a warning about a missing property of
[Symbol.toPrimitive], because we were indexing this._items with the
indices array (which is not a primitive) instead of its first item.
https://phabricator.endlessm.com/T21027
|
|\
| |
| | |
T20694
|
| |
| |
| |
| | |
The spacing makes it look like a typo.
|
| |
| |
| |
| |
| | |
There is no ordering guaranteed in the GVDB key names; while this is
okay for the probes, the metadata section should be clustered together.
|
| | |
|
| |
| |
| |
| | |
We need to check all meta data keys.
|
| |
| |
| |
| | |
We use the fields in the profile state singleton.
|
| |
| |
| |
| | |
Add more Unicode art.
|
| |
| |
| |
| |
| | |
The `show` command loads a list of profile capture files and prints the
metadata and sample summary.
|
| |
| |
| |
| | |
We are going to re-use them in the profile CLI tool.
|
| |
| |
| |
| |
| |
| | |
Captures of profiling data are saved in a binary format, and we need a
tool that can load them and turn them into user readable (or machine
readable) data.
|
| |
| |
| |
| |
| |
| |
| | |
We want to have access to more metadata, including the application id,
when capturing profiling data for later review, as the immediate
association between a process and its profiling data is not available in
that case.
|
| |
| |
| |
| |
| | |
We only remove probes when unloading state, so we don't need to remove
the probe from the state itself.
|
| |
| |
| |
| | |
Leftovers from an earlier iteration.
|
|/
|
|
|
|
| |
g_timeout_add() takes miliseconds instead of microseconds
https://phabricator.endlessm.com/T20677
|
|\
| |
| | |
T20769
|
| |
| |
| |
| |
| |
| | |
Always print out the number of samples and the total time, regardless of
the number of samples; in case we have more than one sample, be more
specific and add the average, minimum, maximum, and standard deviation.
|
| |
| |
| |
| |
| |
| | |
We should only give up if we didn't have any samples.
https://phabricator.endlessm.com/T20769
|
|\ \
| |/
|/| |
EosWindow: add in-resize css class
|
| |
| |
| |
| |
| |
| |
| | |
Add class while window is being resized to change image scaling method in CSS
This would speed up resizing windows with background images.
https://phabricator.endlessm.com/T20677
|
| |
| |
| |
| |
| |
| | |
The C API has a convenience macro to initialise the location of the
probe in the source file. We should use an override for the start()
method in order to let GJS fill out the same data for us.
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EosProfileProbe API allows defining profiling probes that can be
used to efficiently measure the time spent in a critical section.
The Profiling API is meant to collect samples and generate a report
at the end of the lifetime of the process, either by printing out the
results once the process terminates; or by saving the raw data in a
binary file that can be loaded at a later date.
This profiling API is meant to be as close as possible to a zero cost
abstraction:
- probes are only allocated if profiling is enabled
- all profiling API is a no-op if profiling isn't enabled
- the C API is meant to be easily tied to a scope, through the
use of auto-cleanup macros provided by GLib
This allows projects using the Endless SDK to keep the profiling probes
in place, instead of conditionally compile them in.
https://phabricator.endlessm.com/T18514
|
| |
|