My gitea instance was only ~6 DB migrations beyond where Forgejo was at when I decided to switch, so I just undo‘d those and upgraded anyways. Works just fine, but I was really lucky that they weren‘t any big migrations. I guess isn‘t really as feasible anymore.
Had the same experience, but the import feature works really well (with `ALLOWED_DOMAINS = *` in app.ini). Bad news is i had to do this individually for each repo. Good news is it went great and fast, even for private repos.
I bought the same adapter and use it with Bazzite, which has a `toggle-cec-sleep` you can run that just set it up. Now when I press a button on my keyboard, the PC starts up and the TV turns on. It's magical.
I'm working on JRECC, a Java remotely executing caching compiler.
It's designed to integrate with Maven projects, to bring in the benefits of tools like Gradle and Bazel, where local and remote builds and tests share the same cache, and builds and tests are distributed over many machines. Cache hits greatly speed up large project builds, while also making it more reliable, since you're not potentially getting flaky test failures in your otherwise identical builds.
I'm working on JRECC, a Java remotely executing caching compiler.
It's designed to integrate with Maven projects, to bring in the benefits of tools like Gradle and Bazel, where local and remote builds and tests share the same cache, and builds and tests are distributed over many machines. Cache hits greatly speed up large project builds, while also making it more reliable, since you're not potentially getting flaky test failures in your otherwise identical builds.
This is a somewhat simplistic view of ownership and borrowing for modern programming languages.
Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names.
An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers.
This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)
struct resource {
resource(ctx *c, ...) {index = c->store(...); ...;}
size_t index;
ctx *c;
~resource() {c->free(index);}
// copy constructor+op creates new handle
// move constructor+op copies the handle, maybe zeroes the current one
};
With this you can rely on RAII, smart pointers, upcoming lifetime checks and annotations, etc. The core idea is that you treat objects of classes like this as values and everything works out seamlessly. Even if they are 'pointers' in all but name. You can also overload the dereference operator for it to have pointer-like syntax, but that is discouraged.
When you have just once resource this might be overkill but for large projects with tangled webs of resources, this sort of setup really makes the code simpler and easier to design.
That's C++ for you, simple things look complex but once you get into big hairy projects things stay at the same level of complexity instead of becoming an unmanageable mess.
D almost supports RAII, and the compiler seems to do some automated copy to move conversion, but this is the sort of thing that really, really needs a large number of users and compiler implementers to iron out issues and corner cases. Nothing against D, the language is pretty neat!
But if I'm not mistaken, this is just handling index allocation, release and avoiding dangling manually. The programmer is still responsible, right? And I don't think Rust can do better for indices, since indices are normal, "eternal" values.
> this is just handling index allocation, release and avoiding dangling manually
No, it is abstracted away. You just have to follow best practices when writing a library.
resource foo(...); // This gets freed at the end of scope. See RAII.
auto x = make_unique<resource>(...); // can be moved, freed when owner is.
auto y = make_shared<resource>(...); // freed on zero reference count
I don't know D so I'm probably missing some basic syntax. If pointers cannot be copied how do you have multiple objects referencing the same shared object?
I'm working on JRECC, a Java remotely executing caching compiler.
It's designed to integrate with Maven projects, to bring in the benefits of tools like Gradle and Bazel, where local and remote builds and tests share the same cache, and builds and tests are distributed over many machines. Cache hits greatly speed up large project builds, while also making it more reliable, since you're not potentially getting flaky test failures in your otherwise identical builds.
You can use ListenBrainz to discover new music based on your listening activity from your self-hosted library. I've started doing this recently with Navidrome and I'm happy with the results. This is the plugin I've been using: https://github.com/kgarner7/navidrome-listenbrainz-daily-pla....
There is also Troi[1], a tool provided by ListenBrainz to generate playlists and radios from your local music collection.
If you don't mind self-hosting, I've recently started using ListenBrainz in combination with Navidrome. You can upload your Spotify listen history to seed it, and scrobble your ongoing listening to keep it up to date with what you listen to. You can use a plugin[1] to automatically generate daily, weekly, and discovery playlists based on your listen history, and what you have available in your library. You can generate even more playlists using ListenBrainz data via their tool, Troi[2].
In my org they count both the number of pull requests, and the number of comments you add to reviews. Easily gamed, but that's the performance metric they use to compare every engineer now.
