• 0 Posts
  • 61 Comments
Joined 1 year ago
cake
Cake day: June 2nd, 2023

help-circle





  • ugo@feddit.ittoLinux@lemmy.mlGoldilocks distro?
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    10 days ago

    +1. Arch is super easy to install, just open the install guide on the wiki and do what it says.

    It’s also really stable nowadays, I can’t actually remember the last time something broke.

    As a counterpoint, on ubuntu I constantly had weird issues where the system would change something apparently on its own. Like the key repeat resetting every so often (I mean multiple times an hour), weirdness with graphic drivers, and so on.

    That said, I also appreciate debian for server usage. Getting security updates only can be desirable for something that should be little more than an appliance. Doing a dist upgrade scares the shit out of me though, while on arch that’s not even close to a concern.


  • What “it” is configurable? If the code is indented with 4 spaces, it is indented with 4 spaces. You can configure your editor to indent with 1 space if you want, but then your code is not going to respect the 4 spaces of indentation used by the rest of the code.

    I repeat, the only accessible indentation option is using tabs. This is not an opinion because every other option forces extra painful steps for those with vision issues (including, but not limited to, having to reformat the source files to tabs so they can work on them and then reformat them back to using spaces in order to commit them)


  • ugo@feddit.ittoProgramming@programming.devWhy YAML sucks?
    link
    fedilink
    arrow-up
    10
    arrow-down
    2
    ·
    13 days ago

    Hard tabs are the only accessible option though. If you care about developers with a different vision capability than yours, the only correct indentation choice is tabs.

    If, because of bad vision, someone needs to crank the font size way up, it’s very possible that they might need to work with a tabstop of 3, 2, or even just 1 space.

    With tabs, this is user configurable. With spaces it isn’t.



  • We use null objects at work, and as another person said they are a safety feature. Here’s how they work: they are wrappers around another type. They provide the same interface as the wrapped type. They store one global instance of the wrapped type, default initialized, in a memory page marked read-only.

    Here’s why they are considered a safety feature (note: most of this is specific to c++).

    Suppose you have a collection, and you want to write a function that finds an item in the collection. Find can fail, of course. What do you return in that case? Reasonable options would be a null pointer, or std::nullopt. Having find return a std::optional would be perfect, because that’s the exact use case for it. You either found the item or you did not.

    Now, the problem is that in most cases you don’t want to copy the item that was found in the collection when you return it, so you want to return a pointer or a reference. Well, std::optional<T&> is illegal. After all, an optional reference has the same semantics as a pointer, no? This means your find function cannot return an optional, it has to return a pointer with the special sentinel value of nullptr meaning “not found”.

    But returning nullptr is dangerous, because if you forget to check the return value and you accidentally dereference it you invoke undefined behavior which in this case will usually crash the program.

    Here’s where the null object comes in. You make find just return a reference. If the item is not found, you return a reference to the null object of the relevant type. Because the null object always exists, it’s not UB to access it. And because it is default initialized, trying to get a value from it will just give you the default value for that data member.

    Basically it’s a pattern to avoid crashing if tou forget to check for nullptr



  • Meh. Been developing professionally with C++ for 10 years at this point. I’m one of the weird people that kinda likes C++ and its pragmatism despite all its warts.

    I’d like C++ better if it didn’t have inheritance. There are better solutions to model interfaces, and without inheritance people can’t write class hierarchies that are 10 levels deep with a different set of virtual functions overridden (and new virtual functions added) at each level.

    And yes, that is not hypothetical. Real codebases in the real world shipping working products do that, and it’s about as nice as you can imagine.


  • You do have a terminology mismatch. In C++, an abstract class is a class with at least one pure virtual method.

    Such classes cannot be instantiated, so they are useful only as base classes.

    An interface is more of a concept than a thing.

    Sure you can say that Iterable is an interface that provides the Next() and Prev() methods and you can say that Array is an Iterable because it inherits from Iterable (and then you override those methods to do the correct thing), and that’s one way to implement an interface in C++.

    But you can also say that Iterable<T> is a class template that provides a Next() and Prev() methods that call the methods of the same name on the type that they wrap (CRTP aka static polymorphism).

    Or you can say that an algorithm that scans a collection T forward requires the collection to have a Next() method by calling Next() on it.

    And I can think of at least 2 other ways to define an interface that isn’t using abstract classes.

    And even if using abstract classes, inheriting from them is definitely the least flexible way to use them to define an interface, because it doesn’t allow one to do something like mocking functionality in tests, because it’s not possible to redefine the class to be tested to inherit from the test interface implementation with mocked functionality, so one still needs something to the effect of dependency injection anyway.

    So yeah, abstract class is very different from inheritance, and it’s also very different from interface, even though it relates to both.


  • Looks to me like the ruling is saying that the output of a model trained on copyrighted data is not copyrighted in itself.

    By that logic, if I train a model on marvel movies and get something that is exactly the same as an existing movie, that output is not copyrighted.

    It’s a stretch, for sure, and the judge did say that he didn’t consider the output to be similar enough to the source copyrighted material, but it’s unclear what “close enough” is.

    What if my model is trained on star wars and outputs a story that is novel, with different characters with different voices. That’s not copyrighted then, despite the model being trained exclusively on copyrighted data?



  • I think it’s possible that the filesystem ran out of inodes, so even though there is space on disk, there is no space in the filesystem metadata to store new files.

    Now, I don’t know off the top of my head how to check this, but I assume the answer is on the internet somewhere (am on phone and can’t help much more than this, sorry)





  • Reread the OP. They say:

    not on GNOME, because you have a panel at the top

    And

    when usign GTK apps on those [non-GNOME] desktops

    So you would not “access the controls above the app”, because having controls above the app is not covered by this scenario.

    The scenario is:

    1. You don’t have a top panel
    2. You have a maximized GTK app

    Which makes the close button be in the corner of the screen, but without actually extending to it.

    On topic: never knew this was a problem, guess I got spoiled by the Qt environment