• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: July 14th, 2023

help-circle




  • The C compiler or third party libraries can provide support for parallel execution and SIMD. That article is just used by people in an attempt to argue that C's strength in being a good low level abstraction is false, which it isn't. C is the best portable abstraction over a generic CPU that I know of. If you start adding parallel features and SIMD like the article suggest, you'll end up with something that's not a portable low level abstraction. To be portable those featues would have to be implemented in slow fake variants for platforms that doesn't support it. We can always argue where to draw the line, but I think C nailed it pretty good on what to include in the language and what to leave up to extensions and libaries.

    C is not a perfect abstraction, because it is portable. Non portable features for specific architectures are accessed through libraries or compiler extensions and many compilers even include memory safe features. It's a big advantage though to know Assembly for your target platform when developing in C, such that you become aware fx. that x86 actually detects integer overflow and sets an overflow flag, even though that's not directly accessible from C. Compilers often implement extensions for such features, but you can yourself extend C with small functions for architecture specific features using Assembly.





  • Just to clarify. The gi:// resources are GObject Introspection modules which are used for multilanguage bindings to native libraries. On my system, GI modules are found in /usr/share/gir-1.0/ . They're just imported by name and sometimes version using gi:// (there are examples in the link in my first comment).

    As I don't have Gnome installed I can't be sure of the path to gnome shell modules imported using resource://, but it's probably the path I wrote, but without js/.




  • GNOME Shell 45 moved to ESM (ECMAScript modules). That means you MUST use the standard import declaration instead of relying on the previous imports.* approach.

    https://gjs.guide/extensions/upgrading/gnome-shell-45.html

    So the imports in your extensions is changed from:

    const Clutter = imports.gi.Clutter;
    const Gio = imports.gi.Gio;
    const Main = imports.ui.main;
    const Volume = imports.ui.status.volume;
    

    to

    import Clutter from 'gi://Clutter';
    import Gio from 'gi://Gio';
    import * as Main from 'resource:///org/gnome/shell/ui/main.js'
    import * as Volume from 'resource:///org/gnome/shell/ui/status/volume.js';
    








  • I build a lot of tools like that and the first thing I do is to go to the developer tool in my browser and observe the network traffic. When you find the resource you're after you scroll back and see what requests resulted in that URL. Going from those requests you figure out in the original static HTML document and resource, which parameters are used for the construction of the URL, that might require reversing some javascript, but that's rare. After that you'll have a pretty good idea how you obtain the video resource from the original URL. Beware of cookie set by the requests, they might be needed to access the next requests. For building my tools I use Perl or sometimes just Bash or a GreaseMonkey userscript to fetch and parse the urls and construct the desired output.