• 5 Posts
  • 193 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • Plenty of self-driving trains around, generally metros where frequency and 24/7 operation is a great boon to overall service quality – you don’t want people to look at schedules, you want them to go to the station knowing there’s going to be a train in a couple of minutes, tops.

    It’s way different for long-haul service, freight, passenger, doesn’t matter. Longer and less frequent trains with way more passengers in them, and you probably need other staff too, like someone needs to run the bistro. The tracks they’re running on are also way less predictable, with a metro you can have station screen doors everywhere (which btw necessitate automatic driving, humans aren’t accurate enough) try that with an international train: Regions much less countries can’t even agree on uniform platform heights. Much less door locations: Automated long-haul would require dedicated platforms at every station and while those could be served by trains with drivers, trains nowadays are all smart enough that including a button “stop at exactly that location, to the half-centimetre” isn’t an issue, those trains would have to have doors at the right location. Now go ahead and convince Germany and France that they need to replace all TGVs and ICEs to have doors in the same location as your regional trains.

    Oh and none of that automation tech used with trains uses machine learning, btw. At least not at the basic level, when it comes to actually driving the train. I do remember watching a documentary about Singapore’s metro, where they have an ML algorithm scheduling track maintenance, minimising not service interruptions as such but impact on people’s commute. First the workers complained that none of the orders made any sense, then the developers made the computer spit out context and motivation alongside with the orders, workers changed their tune to “that’s fucking brilliant”.

    …which, actually, brings me to the conclusion: Also with automated systems we’re going to need maintenance which isn’t going to be automated any time soon. If you automate a metro that currently doesn’t run 24/7 you don’t have that many drivers in the first place, and probably have other jobs for them to do. Automating really is about making “a train max. every five minutes, 24/7” possible without breaking the bank.




  • I think you dont fully understand how c compilers ( gcc specifically ) work when using multi file projects

    They don’t. C compilers compile single files produced by the c preprocessor (resolving all #includes), they have no concept of multi-file projects. That’s a thing for the build system, such as make, and it needs dependency information from the preprocessor to do its job (cpp -M), and once it has that it has to act correctly on them which is often completely broken because people don’t understand make. Like using it recursively, bad idea. In the wild, a random C project at work you’ll come across needs a full rebuild to build cleanly. Things have gotten better with things like cmake getting more popular but the whole thing is still brittle. GNU autohell certainly makes nothing better, ever.

    Also, anything using IL will always have an abi,

    Everything will always have an ABI because ABI is just API in the target language, whatever that may be. If your program is compiled and can run it uses an ABI.

    Wasm is wasm, and you only need an exposed interface

    The core wasm abi is less capable than the C abi: You get scalar values and pointers, that’s it. No structs, no nothing, memory layout is completely unspecified. The component model allows compilers to say “so I’m laying out strings like this and structs like that” giving linkers a chance to say “yeah I can generate glue code between you two”.

    Again, i like the idea of rust, but it has a long way to go to be viable atm.

    C isn’t even close to being viable according to your standards people just have gotten used to the jank.

    And it has many pitfalls to avoid so it doesnt become the hot mess that is any framework based on node.js

    Rust doesn’t have portable dylibs precisely because it isn’t a hot mess. Because it’s actual work to do it properly. Unlike everyone else. Meanwhile It speaks the local C ABI fluently (they differ by architecture and operating system, btw), which isn’t a thing that can be said about many languages that aren’t C.


    Differently put: What, precisely, do you want to do? Have you any actual use-case for your doubts, or are they spooks?


  • It’s a lacking point yes but unless you want to use a closed-source library it’s also a non-issue, which is why it has never been given priority. It’s not like language semantics would prevent portable dylibs it’s that there’s more important fronts to improve Rust on. A proper solution would take quite some engineering effort, and do note that C doesn’t have a proper solution either it just lets you link stuff up willy-nilly and then crash. Rust is actually in a better position to implement a proper solution than C is.

    The “big project” thing is a red herring given that rust compiles incrementally. I know it is technically possible to not rebuild everything from scratch in C but the code has to specifically written to not break assumptions your build system makes while rust is happily re-using the compilation results for one function in a file while discarding those of another because actual dependencies are actually tracked. Out of the box.

    Speaking of large Rust projects and proper type-safe linking: The WebAssembly folks are hashing out their Component Model which isn’t really limited to compiling to wasm, in principle: Big picture it’s a way to programmatically specify ABIs and even derive ABI translation code. That might be a good option as a rust-specific solution would be, well, rust-specific and when you engineer something that can support multiple versions of a language you can just as well engineer a bit more and have something cross-language.



  • The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling. Option<T> vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.

    As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.


  • So you can find things by “that spicy chicken recipe” instead of having to remember what it was actually called, or slog through a gazillion chicken recipes in your history when you realise that “spicy” was nowhere in the name. Basically stemming/thesaurus search on steroids.

    It’s quite likely to be opt-in as I imagine ingesting the sites you’re looking at is a significant computational load. The translators are also opt-in, there’s enough stuff inbuilt to detect languages but not to translate, you have to download those models first. And they’re quite good btw.

    Another thing I could see them offering is stuff like tl;dr bot. It’s probably not for everyone, but I definitely can see that it can be a useful feature for many people.





  • ROMs back then got erased by UV light, EPROM. EEPROMs are a bit newer (though still ancient) and can be erased electronically, nowadays it’s a very sane idea to just throw flash storage at the problem. I think you can get modern replacement for pretty much any ancient form factor.

    The way those things are used are basically big logic tables: Instead of using a bunch of logic gates, you store the output that’s expected given a certain input. Completely ancient technique, the limiting factor is storage space and sensibility – storing all addition results of two 32 bit numbers uses a lot more transistors than a 32-bit adder, but if what you want to put in there isn’t a thing that can be implemented few standard TTL components throwing storage at the problem makes sense even if you never plan to reprogram it because burning a custom set of transistors onto silicon is expensive.


  • Some more technical info.

    It’s an legit 8-bit CPU implemented with TTL chips, what makes it a different beast than what they did back in the days is that its microcoding isn’t kneecapped. It would absolutely have been possible back in the days to build exactly such a thing, even from precisely those components. At least the TTL part, that is, I bet there’s wibbles around VGA etc. And because I already hear the detractors yes, 8-bit CPUs were microcoded: They decoded single external instructions into a stream of “load from memory, fetch from register so and so, switch on the ALU, put what’s in the ALU output somewhere”. They kept it as simple as possible and it wasn’t reprogrammable but that stuff there, that’s microcode.

    Implementing CPUs in TTL chips also isn’t a new idea, that’s how early minicomputers were made (later on they got some specialised chips). And those things also used ROMs for their microcode. So you could say that this is a minicomputer capable of pretending to be different 8-bit microcomputers.

    FPGAs are a completely different technology, those allow you to arrange logic in a (more or less) arbitrary topology. That is, looking at that board with all those TTL chips, it’d be the equivalent of being able to re-route all the board traces as you please.


  • Data after dst+n is unchanged.

    Sure but that means the part before that is garbage because you have a null terminated string without terminator.

    Or at least that’s how I see it. If your intention isn’t to start and end with a null-terminated string you should be using memcpy. Let us not talk about situations where CHAR_BIT != 8 that’s not POSIX anyway.

    Even better, just avoid doing string manipulation in C.



  • barsoap@lemm.eetoProgrammer Humor@programming.devA Guessing Game
    link
    fedilink
    arrow-up
    6
    arrow-down
    3
    ·
    edit-2
    2 months ago

    How on earth should a newcomer know that the letter “n” in that word stands for number without having to google it?

    By looking at the difference between strcpy and strncpy. Preferably, though, you should simply learn C before writing C.

    The gist of is is that strcpy takes a null-terminated string and copies it somewhere, while strncpy takes a zero-terminated string and copies it somewhere but will not write more than n bytes. strncpy literally has exactly one more parameter than strcpy, that being n, hence the name. If n is smaller than the string length (as in: distance to first null byte) then you’re bound to have garbage in your destination, and to check for that you have to dereference the pointer strncpy returns and check if it’s actually null. Yay C error handling.

    In retrospect null-terminated strings were a mistake, but so were many other things, at some point you just have to accept that there’s hysterical raisins everywhere.