A Gigglescore is a ratio score of price to performance for single-board-computers like the LattePanda or Raspberry Pi. A lower Gigglescore means a better value for the money. A higher one is worse. You can see more here: https://gigglescore.com/

My LattePanda:

sudo ./benchmark.sh 149
   Repository 'openSUSE-Leap-15.0-Non-Oss' is up to date.                                                                                                                                                               
   Repository 'openSUSE-Leap-15.0-Oss' is up to date.                                                                                                                                                                   
   Repository 'openSUSE-Leap-15.0-Update' is up to date.                                                                                                                                                                
   Repository 'openSUSE-Leap-15.0-Update-Non-Oss' is up to date.                                                                                                                                                        
   All repositories have been refreshed.
   Category5.TV SBC Benchmark v1.1
   Powered by sysbench 1.0.11
   Number of threads for this SBC: 4
   Performing CPU Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   576.760 events per second. Price: Ģ930.02 per unit.
   Performing RAM Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   3,625,781.466 events per second. Price: Ģ0.15 per unit.
   Performing Mutex Benchmark… WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
   6.873 events per second. Price: Ģ7.80 per unit.

Total Giggle cost of this board: Ģ1,397.58

Giggles (Ģ) are a cost comparison that takes cost and performance into account. While the figure itself is not a direct translation of a dollar value, it works the same way: A board with a lower Giggle value costs less for the performance.
 If a board has a high Giggle value, it means for its performance, it is expensive. Giggles help you determine if a board is better bang-for-the-buck, even if it has a different real-world dollar value. Total Giggle cost does not include I/O since that can be impacted by which SD card you choose. Lower Ģ is better.

Being that the suggested retail price is currently $149, we get a Gigglescore of 1,397.58. This is right between the Raspberry Pi 3 B+ and the ODROID XU4 in terms of value for the dollar.

Weblate 3.6 has been released today. It brings rewritten notifications, user data download and several other improvements. It also sets depreciation timeline for Python 2 installations - after April 2020 Weblate will only support Python 3.

Full list of changes:

• Add support for downloading user data.
• Addons are now automatically triggered upon installation.
• Improved instructions for resolving merge conflicts.
• Cleanup addon is now compatible with app store metadata translations.
• Configurable language code syntax when adding new translations.
• Warn about using Python 2 with planned termination of support in April 2020.
• Extract special chars from the source string for visual keyboard.
• Extended contributor stats to reflect both source and target counts.
• Admins and consistency addons can now add translations even if disabled for users.
• Fixed description of toggle disabling Language-Team header manipulation.
• Notify users mentioned in comments.
• Removed file format autodetection from component setup.
• Fixed generating MO file for monolingual PO files.
• Added digest notifications.
• Added support for muting component notifications.
• Added notifications for new alerts, whiteboard messages or components.
• Notifications for administered projects can now be configured.
• Improved handling of three letter language codes.

If you are upgrading from older version, please follow our upgrading instructions.

You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, FreedomBox, Weblate itself and many other projects.

Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.

Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.

Filed under: Debian English SUSE Weblate

Trois clichés openSUSE Tumbleweed de qualité ont été publiés depuis jeudi dernier avec des paquets mis à jour pour Curl, Salt, FFmpeg et plus.

Mozilla Firefox a publié une version mineure de la version 66.0.3 dans le dernier instantané Tumbleweed 20190415. Le navigateur a résolu certains problèmes de performances avec certains jeux HTML5 et fourni un plug-in de recherche Baidu destiné aux utilisateurs chinois et à l’espace Internet chinois. Curl 7.64.1, l'outil de ligne de commande permettant de transférer des données à l'aide de divers protocoles, a corrigé de nombreux bogues et ajouté des bibliothèques supplémentaires pour vérifier la prise en charge du protocole LDAP (Lightweight Directory Access Protocol). La mise à jour de libvirt 5.2.0 a supprimé quelques correctifs et ajouté plusieurs nouvelles fonctionnalités, telles que les capacités de pool de stockage, pour obtenir une liste de sortie XML plus détaillée pour l'interface de programmation d'application (API) virConnectGetStoragePoolCapabilites. Libvirt a également activé la sélection automatique du microprogramme pour l'émulateur open source QEMU. Le tout nouveau paquet salt 2019.2.0 de Tumbleweed a amélioré l'automatisation du réseau et étendu la prise en charge de divers systèmes d'exploitation via le réseau, ainsi que de fonctionnalités de manipulation de la configuration ou d'exécution de commandes opérationnelles. Salt a également ajouté l'exécution de playbooks à la version 2019.2.0 avec la fonction playbookset inclut un module pour les states ansible, qui peut être utilisé sur un hôte ciblé pour exécuter des playbooks, ou utilisé dans un orchestrateur de states. Selon l'évaluateur de Tumbleweed, l’instantané avait une cote de 95 au moment de la publication de cet article.

Le cliché 20190412 a obtenu une note de 94 et a apporté une mise à jour à Ceph qui a ajouté une option distincte permettant de configurer un port SSL (Secure Sockets Layer). Le paquet cifs-utils 6.9, qui fait partie du projet Samba, a ajouté des correctifs pour Azure et supprimé plusieurs bogues. Le paquet libssh2_org 1.8.2 a rectifié un correctif mal appliqué qui cassait sa version précédente. Quelques paquets YaST comportaient des mises à jour, comme le paquet yast2-storage-ng 4.2.5, qui permet un nouveau format pour importer/exporter des lecteurs NFS (Network File System).

L’instantané 20190411 a démarré la semaine et affichait un score modérément stable de 89. Cet instantané apportait le noyau Linux 5.0.7 et offrait un potentiel d’atténuation pour un appel système ptrace pour PowerPC. Il y avait quelques corrections de bugs pour les codecs, les filtres et les formats dans la mise à jour 4.1.3 de ffmpeg. Le connecteur JavaScript pour GNOME, gjs 1.56.0, contenaient des modifications très importantes par rapport à la version précédente 1.54.3 de Tumbleweed. Les changelog précédents ont identifié un bogue GNU Compiler Collection 9 et ajouté des règles ESLint. La nouvelle version était une version stable. Le paquet python-kiwi 9.17.35 a corrigé les régressions pour le module kiwi-repart dracut. Le package wget 1.20.3 a corrigé la vulnérabilité de débordement de la mémoire tampon trouvée dans le Common Vulnerabilities and Exposures (CVE) 2019-5953. L’éditeur de texte vim 8.1.1137 a corrigé plusieurs bogues, dont un test Python qui n’effaçait pas le tampon caché et une espace dans la colonne de numérotation de ligne qui se trouvait du mauvais côté lorsque le paramètre rightleft était activé.

Traditionally, GObject implementations in C are mutable: you instantiate a GObject and then change its state via method calls. Sometimes this is expected and desired; a GtkCheckButton widget certainly can change its internal state from pressed to not pressed, for example.

Other times, objects are mutable while they are being "assembled" or "configured", and only yield a final immutable result until later. This is the case for RsvgHandle from librsvg.

Please bear with me while I write about the history of the RsvgHandle API and why it ended up with different ways of doing the same thing.

The traditional RsvgHandle API

The final purpose of an RsvgHandle is to represent an SVG document loaded in memory. Once it is loaded, the SVG document does not change, as librsvg does not support animation or creating/removing SVG elements; it is a static renderer.

However, before an RsvgHandle achieves its immutable state, it has to be loaded first. Loading can be done in two ways:

• The historical/deprecated way, using the rsvg_handle_write() and rsvg_handle_close() APIs. Plenty of code in GNOME used this write/close idiom before GLib got a good abstraction for streams; you can see another example in GdkPixbufLoader. The idea is that applications do this:

file = open a file...;
handle = rsvg_handle_new ();

while (file has more data) {
   rsvg_handle_write(handle, a bit of data);
}

rsvg_handle_close (handle);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);

• The streaming way, with rsvg_handle_read_stream_sync(), which takes a GInputStream, or one of the convenience functions which take a GFile and produce a stream from it.

file = g_file_new_for_path ("/foo/bar.svg");
stream = g_file_read (file, ...);
handle = rsvg_handle_new ();

rsvg_handle_read_stream_sync (handle, stream, ...);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);

A bit of history

Let's consider a few of RsvgHandle's functions.

Constructors:

• rsvg_handle_new()
• rsvg_handle_new_with_flags()

Configure the handle for loading:

• rsvg_handle_set_base_uri()
• rsvg_handle_set_base_gfile()

Deprecated loading API:

• rsvg_handle_write()
• rsvg_handle_close()

Streaming API:

• rsvg_handle_read_stream_sync()

When librsvg first acquired the concept of an RsvgHandle, it just had rsvg_handle_new() with no arguments. About 9 years later, it got rsvg_handle_new_with_flags() to allow more options, but it took another 2 years to actually add some usable flags — the first one was to configure the parsing limits in the underlying calls to libxml2.

About 3 years after RsvgHandle appeared, it got rsvg_handle_set_base_uri() to configure the "base URI" against which relative references in the SVG document get resolved. For example, if you are reading /foo/bar.svg and it contains an element like <image xlink:ref="smiley.png"/>, then librsvg needs to be able to produce the path /foo/smiley.png and that is done relative to the base URI. (The base URI is implicit when reading from a specific SVG file, but it needs to be provided when reading from an arbitrary stream that may not even come from a file.)

Initially RsvgHandle had the write/close APIs, and 8 years later it got the streaming functions once GIO appeared. Eventually the streaming API would be the preferred one, instead of just being a convenience for those brave new apps that started using GIO.

A summary of librsvg's API may be something like:

• librsvg gets written initially; it doesn't even have an RsvgHandle, and just provides a single function which takes a FILE * and renders it to a GdkPixbuf.

• That gets replaced with RsvgHandle, its single rsvg_handle_new() constructor, and the write/close API to feed it data progressively.

• GIO appears, we get the first widespread streaming APIs in GNOME, and RsvgHandle gets the ability to read from streams.

• RsvgHandle gets rsvg_handle_new_with_flags() because now apps may want to configure extra stuff for libxml2.

• When Cairo appears and librsvg is ported to it, RsvgHandle gets an extra flag so that SVGs rendered to PDF can embed image data efficiently.

It's a convoluted history, but git log -- rsvg.h makes it accessible.

Where is the mutability?

An RsvgHandle gets created, with flags or without. It's empty, and doesn't know if it will be given data with the write/close API or with the streaming API. Also, someone may call set_base_uri() on it. So, the handle must remain mutable while it is being populated with data. After that, it can say, "no more changes, I'm done".

In C, this doesn't even have a name. Everything is mutable by default all the time. This monster was the private data of RsvgHandle before it got ported to Rust:

struct RsvgHandlePrivate {
    // set during construction
    RsvgHandleFlags flags;

    // GObject-ism
    gboolean is_disposed;

    // Extra crap for a deprecated API
    RsvgSizeFunc size_func;
    gpointer user_data;
    GDestroyNotify user_data_destroy;

    // Data only used while parsing an SVG
    RsvgHandleState state;
    RsvgDefs *defs;
    guint nest_level;
    RsvgNode *currentnode;
    RsvgNode *treebase;
    GHashTable *css_props;
    RsvgSaxHandler *handler;
    int handler_nest;
    GHashTable *entities;
    xmlParserCtxtPtr ctxt;
    GError **error;
    GCancellable *cancellable;
    GInputStream *compressed_input_stream;

    // Data only used while rendering
    double dpi_x;
    double dpi_y;

    // The famous base URI, set before loading
    gchar *base_uri;
    GFile *base_gfile;

    // Some internal stuff
    gboolean in_loop;
    gboolean is_testing;
};

"Single responsibility principle"? This is a horror show. That RsvgHandlePrivate struct has all of these:

• Data only settable during construction (flags)
• Data set after construction, but which may only be set before loading (base URI)
• Highly mutable data used only during the loading stage: state machines, XML parsers, a stack of XML elements, CSS properties...
• The DPI (dots per inch) values only used during rendering.
• Assorted fields used at various stages of the handle's life.

It took a lot of refactoring to get the code to a point where it was clear that an RsvgHandle in fact has distinct stages during its lifetime, and that some of that data should only live during a particular stage. Before, everything seemed a jumble of fields, used at various unclear points in the code (for the struct listing above, I've grouped related fields together — they were somewhat shuffled in the original code!).

What would a better separation look like?

In the master branch, now librsvg has this:

/// Contains all the interior mutability for a RsvgHandle to be called
/// from the C API.
pub struct CHandle {
    dpi: Cell<Dpi>,
    load_flags: Cell<LoadFlags>,

    base_url: RefCell<Option<Url>>,
    // needed because the C api returns *const char
    base_url_cstring: RefCell<Option<CString>>,

    size_callback: RefCell<SizeCallback>,
    is_testing: Cell<bool>,
    load_state: RefCell<LoadState>,
}

Internally, that CHandle struct is now the private data of the public RsvgHandle object. Note that all of CHandle's fields are a Cell<> or RefCell<>: in Rust terms, this means that those fields allow for "interior mutability" in the CHandle struct: they can be modified after intialization.

The last field's cell, load_state, contains this type:

enum LoadState {
    Start,

    // Being loaded using the legacy write()/close() API
    Loading { buffer: Vec<u8> },

    // Fully loaded, with a Handle to an SVG document
    ClosedOk { handle: Handle },

    ClosedError,
}

A CHandle starts in the Start state, where it doesn't know if it will be loaded with a stream, or with the legacy write/close API.

If the caller uses the write/close API, the handle moves to the Loading state, which has a buffer where it accumulates the data being fed to it.

But if the caller uses the stream API, the handle tries to parse an SVG document from the stream, and it moves either to the ClosedOk state, or to the ClosedError state if there is a parse error.

Correspondingly, when using the write/close API, when the caller finally calls rsvg_handle_close(), the handle creates a stream for the buffer, parses it, and also gets either into the ClosedOk or ClosedError state.

If you look at the variant ClosedOk { handle: Handle }, it contains a fully loaded Handle inside, which right now is just a wrapper around a reference-counted Svg object:

pub struct Handle {
    svg: Rc<Svg>,
}

The reason why LoadState::ClosedOk does not contain an Rc<Svg> directly, and instead wraps it with a Handle, is that this is just the first pass at refactoring. Also, Handle contains some API-level logic which I'm not completely sure makes sense as a lower-level Svg object. We'll see.

Couldn't you move more of CHandle's fields into LoadState?

Sort of, kind of, but the public API still lets one do things like call rsvg_handle_get_base_uri() after the handle is fully loaded, even though its result will be of little value. So, the fields that hold the base_uri information are kept in the longer-lived CHandle, not in the individual variants of LoadState.

How does this look from the Rust API?

CHandle implements the public C API of librsvg. Internally, Handle implements the basic "load from stream", "get the geometry of an SVG element", and "render to a Cairo context" functionality.

This basic functionality gets exported in a cleaner way through the Rust API, discussed previously. There is no interior mutability in there at all; that API uses a builder pattern to gradually configure an SVG loader, which returns a fully loaded SvgHandle, out of which you can create a CairoRenderer.

In fact, it may be possible to refactor all of this a bit and implement CHandle directly in terms of the new Rust API: in effect, use CHandle as the "holding space" while the SVG loader gets configured, and later turned into a fully loaded SvgHandle internally.

Conclusion

The C version of RsvgHandle's private structure used to have a bunch of fields. Without knowing the code, it was hard to know that they belonged in groups, and each group corresponded roughtly to a stage in the handle's lifetime.

It took plenty of refactoring to get the fields split up cleanly in librsvg's internals. The process of refactoring RsvgHandle's fields, and ensuring that the various states of a handle are consistent, in fact exposed a few bugs where the state was not being checked appropriately. The public C API remains the same as always, but has better internal checks now.

GObject APIs tend to allow for a lot of mutability via methods that change the internal state of objects. For RsvgHandle, it was possible to change this into a single CHandle that maintains the mutable data in a contained fashion, and later translates it internally into an immutable Handle that represents a fully-loaded SVG document. This scheme ties in well with the new Rust API for librsvg, which keeps everything immutable after creation.