It’s not that universal, but we have named a few things “Engines”, for example Balancing Engine. We also use services, but they are actually independent programs that performs jobs. Engine are used in other places, such as the ViewModels, or in the services.

We put them in the DomainModel project which most things reference though. That’s were most basic functionality and shared resources end up if they are used across Client/Service/Backend projects. So Domain / DomainModel might be a thing to use as well, if you want a specific namespace for that kind of use.

Why wait and hope for C++ to get where modern languages are now? I know there’s value in the shared experience in C++ that if adapted would make it stronger, but I can only see a development of C++ having to force a drop of a lot of outdated stuff to even get started on being more suitable.

But the language is just not comfortable to me. From large amounts of anything creating undefined behavior, the god awful header files which I hate with a passion, tough error messages and such. I also met a fun collision of C++ in Visual Studio and using it with CMake in CLion.

I’ve just started looking at rust for fun, and outside not understanding all the errors messages with the bounded stuff yet, figuring out what type of string I should use or pass, and the slow climb up the skill curve, it’s pretty nice. Installing stuff is as easy as copy pasting the name into the cargo file!

Rust is just the prospective replacement of C++ though, people act like the White house said that C++ should be replaced by rust now. But the just recommend it and other languages, C# will do for a lot of people that does not need the performance and detail that the aforementioned languages target. Python is targeting a whole different use, but often combined with the faster ones.

C++ will live a long time, and if the popularity dies down it will surely be very profitable to be a developer on the critical systems that use it many years from now. I just don’t think an evolution of C++ is going to bring what the world needs, particularly because of the large amount of existing memory related security vulnerabilities. If things were good as they are now, this recommendation would not be made to begin with.

Just learning Rust for fun, but decided I wanted to make a simple website. I don’t like web stuff that much, but seen htmx, so I gave that a shot. Found popular actix for the server side, and set out to make a simple blog.

Making a page is simple, using htmx is also simple. Setting out to create an blog that is all in a single evolving page? Not so much. Either you don’t get the essential back and forward navigation, or you add that but a site refresh will call just the partial endpoint and screw things up. There’s some quite nice work arounds, but at the end result is that sometimes going back will leave me on a blank site in one step.

I’m probably going to settle for each blog entry being a seperate page if I make the site public. Or just let the small flaws be there, because I hate sites these days being slow. So loading literally only the text/html that’s supposed to change is very cool.

Next steps is going to remove chances of path traversal and reading literally any file on disk by modifying urls…, some markdown to html crate, and see how image loading works. If I ever get around to any of it.

I’m not too much of a fan of the SQL equivalent of SELECT not being at the top. Granted I’m fairly sure there are some arguments for it. Since select is optional there’s a higher mental load trying to figure out where and what is actually being returned imo. At least from looking at this for the first time.

On the other hand, i’d kill for f-strings, the top N in group (which is nigh unreadable in SQL), and null handling that doesn’t require me to write either COALSECE or NVL too often. The joins were a little less pretty though, I’m quite fond of normal SQL joins since they are very reasonable unless chained beyond the line count your screen can show.

No dice there either…

Here’s how it looks when ran from Powershell:

PS C:\Users\Username\RustProjects\Av1an> cargo run --release -- -i .\test.webm
    Finished release [optimized] target(s) in 0.31s
     Running `target\release\av1an.exe -i .\test.webm`
INFO [av1an_core::context] Input: 2560x1440 @ 60.000 fps, YUV420P, SDR
Scene detection
00:00:02 ▐████████████████████████▒                                                   ▌  32% 226/697 (89.17 fps, eta 5s)
error: process didn't exit successfully: `target\release\av1an.exe -i .\test.webm` (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)
PS C:\Users\Username\RustProjects\Av1an> .\target\release\av1an.exe -i .\test.webm
PS C:\Users\Username\RustProjects\Av1an> cd .\target\release\
PS C:\Users\Username\RustProjects\Av1an\target\release> .\av1an.exe -i ..\..\test.webm

Running from the very same Powershell window. Take note that there is nothing for the normal lines because it’s instant death, not even a split second stutter before powershell is ready for a new command. The cargo run works, so why doesn’t a release compiled executable do the same, when it’s using the same file? What difference does cargo run make?

From command line yes.

I’ll have a look and see if I can figure anything out. Thanks!

It’s definitely a clue, but I got both system wide python, and a embedded one hooked up to vapoursynth (another dependency). Still doesn’t explain why debugger doesn’t work but running it does. As far as I see it, they should be the same.

Not sure if there is a solution, but I’m somewhat perplexed that the top level program can’t handle crashes for a dependency it is either trying to load or use.

Thanks for the effort however, much appreciated.

I can show you something after work, if I remember to. The gist of my issue is, a compiled executable doesn’t give any error at all or anything else. It’s because of missing dlls, and I want to find out what and how to prevent it so that the program does tell you why it is not working. If that is even possible.

I can compile the source, and it magically works with cargo run, but otherwise not. Debugging is completely silent, doesn’t seem like it even notices the process.

Thanks you for looking into it, if they are statically linked can something be done about it? Aka, same as other case, how do you detect missing required library to actually throw an error?

The issues where I learned most of it is here: https://github.com/master-of-zen/Av1an/issues/676

Having to build and find a ton of dlls is cumbersome. While I’m fairly sure I’m missing some ffmpeg ones, I’m somewhat taken aback by how running it with cargo run works just fine. But trying to run the very same executable built doesn’t. And debugging also doesn’t do anything. That doesn’t make much sense to me, since the access to said dlls should be the same either way?? Either none of them works, or both does. Or there is some big difference between Cargo Run and the compiled executive when it comes to static or dynamic dlls loading.