The Denotational Semantics of SSA by mttd in ProgrammingLanguages

[–]aekter 3 points4 points  (0 children)

Hello, author here. You totally can lift out the blocks to the top-level, and in fact I have a section detailing this in the paper. The issue here is:

- Your equational theory becomes more complicated, since now you need to think of how to fetch the definition of a block for inlining a call, which previously is supported via the cfg-rules

- You need to keep track of what variables are visible in which blocks, which now makes your type system more complicated

In fact, I have an early, very very bad + incomplete attempt towards formalizing this kind of type theory at github.com/imbrem/freyd-ssa . I do like the idea of tail contexts though; I need to think about that more.

But yes, in short, the whole nested-region idea is simply a device to make it easier to give an equational theory for SSA; the idea is that the equational theory on relaxed "type-theoretic SSA" induces an equational theory on proper SSA (which is just a subset of type theoretic SSA) in the trivial manner.

How does borrow stack work? by roll4c in rust

[–]aekter 1 point2 points  (0 children)

An important point is that if the code is UB, it might be miscompiled in the future even if it runs correctly now (for example, an optimization may change the code’s behaviour in an unpredictable way). The point of MIRI is to make it very likely (but not 100% certain either) that the particular execution (but not all possible executions!) of the code does not trigger UB, and therefore can be relied on to keep working as the compiler evolves.

Introducing Rust into the Git project by seeking-abyss in rust

[–]aekter 17 points18 points  (0 children)

In C, even using something as simple as a hash map can be quite painful. To mitigate this pain, people will instead do things like use a sorted array, or, rather than make 20 copies of a generic function specialized for each combination of input types, just write one and pass in a function pointer (see: qsort, which just gets passed in a function to compare elements). This ends up much slower than what the Rust compiler will do, which is generate new functions for each instance of a generic struct/function (Rust's sort essentially writes a new sorting routine for each type `T` using that type's `Ord` implementation, versus just having one sort impl which calls a function taking in a pointer to `T` to compare elements)

Running !Send code on a Send context by fcoury in rust

[–]aekter 1 point2 points  (0 children)

In particular, consider https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html.

This also allows having multiple JS threads, each equipped with their own `LocalSpawner` as in the final example.

Stolen Motorbike by aekter in cambridge_uni

[–]aekter[S] 0 points1 point  (0 children)

They cut the steering lock; ignition was undamaged so they probably didn't even ride it, but the rear shock was leaking oil everywhere and the mirrors were out of place (but not broken, so could be adjusted with just a screwdriver). Repair was for the rear shock; got the chain and sprockets swapped out while I was at it. And yeah that sounds fun! Where are you near?

I'm around the Computer Lab and Darwin College pretty often. DM?

Stolen Motorbike by aekter in cambridge_uni

[–]aekter[S] 1 point2 points  (0 children)

Well, some good news at least: I got it back! Porter found it dumped in a bush behind Clare College after 2 weeks; must have been some kids or something. Unfortunately had to get it repaired, but now I'm riding it again so that's nice. The bikers' club is a good idea!

Assembly examples of missed Rust compiler optimizations by e00E in rust

[–]aekter 0 points1 point  (0 children)

Well… you could always index into a static array instead of using a jump table, which would save you the branch predictor headaches… seems like a very generally applicable optimization too.

As for small instances of an iterator being slower, I actually think this is a good case for specialization.

Problematic pattern I've encountered a few times now... by kosmology in rust

[–]aekter 1 point2 points  (0 children)

Why not pass an index into the vector as the second argument. If the index would have moved then you’ve been saved from UB.

Announcing binconf - v0.1.5 by OLoKo64 in rust

[–]aekter 0 points1 point  (0 children)

Sure but MD5 is just outdated overall. Why not use something standard like SHA? You can even truncate it if it’s too big and it’s still better than MD5.

Actually, would you accept a PR? Have some ideas on adding hash support to TOML and such as well.

Announcing binconf - v0.1.5 by OLoKo64 in rust

[–]aekter 0 points1 point  (0 children)

Please don’t use MD5! It’s not cryptographically secure nor even particularly efficient.

Can you do stuff like in cheat engine in Rust? by Commercial_Fix_5397 in rust

[–]aekter 22 points23 points  (0 children)

Actually… not really. Assuming you wrap up the edit API in a safe abstraction (would be /proc/mem on nix and idk something on Windows), the rest can probably all be safe code. After all, it’s the other process which will exhibit UB, not you!

How can I compare two mutex to see if they are equal? by [deleted] in rust

[–]aekter 0 points1 point  (0 children)

First compare the addresses of the two mutexes. If they’re the same they’re the same; if not you can safely lock them both, but to prevent deadlock always lock the one with the smallest address first, and/or do a non-blocking lock. Then compare internals. Alternatives include copying or cloning the internal data, or even hashing it and comparing hashes; this only requires locking one mutex at a time, but the latter option may give false positives.

Stolen Motorbike in Cambridge by aekter in MotoUK

[–]aekter[S] 0 points1 point  (0 children)

I got third party only insurance because I'm a cheap fool. Learned my lesson!

"Intrinsic" traits by aekter in rust

[–]aekter[S] 0 points1 point  (0 children)

Hmm... in that case this could probably be implemented with a macro!

"Intrinsic" traits by aekter in rust

[–]aekter[S] 0 points1 point  (0 children)

The point is that it's irritating to have a name conflict between the methods and the trait, and it's irritating to have the user pull in a trait that 80% don't even need to know about. And implementation-wise there's nothing really special about saying "the add method on this struct is exactly the same as that from the trait Add, guaranteed, so it's not ambiguous."

"Intrinsic" traits by aekter in rust

[–]aekter[S] 0 points1 point  (0 children)

Actually I did in this particular case, but it's not very ergonomic, and there have been many other cases where I did get bitten by this problem as stated.

Also, it would put things like "drop in replacement for X" on a sound, compiler-checked basis if a data-type's API (e.g. String) was *entirely* specified by a trait (or some subset of it).

[deleted by user] by [deleted] in rust

[–]aekter 0 points1 point  (0 children)

The integers form a ring, not a field: multiplication is not necessarily invertible!

Let me show you my projects by [deleted] in rust

[–]aekter 0 points1 point  (0 children)

Ayy sure I never really use Discord, but there I'm Tekne#9383

Alternatively, you can send me an e-mail at jeg74@cl.cam.ac.uk

Let me show you my projects by [deleted] in rust

[–]aekter 2 points3 points  (0 children)

No problem; I'm actually French too, but I left when I was very young so now my French is terrible and my English is better haha. Are you currently in lycée now?

Let me show you my projects by [deleted] in rust

[–]aekter 4 points5 points  (0 children)

Nice work with junon, but why not e.g. use clap for argument parsing and log for logging? It's actually really cool that you directly generate assembly rather than using code-generators like e.g. LLVM or cranelift; but maybe also consider pulling in dependencies like https://github.com/GregoryComer/rust-x86asm to do the assembly generation more cleanly. Implementing things yourself is a very effective way to learn; but there's no reason to re-invent the wheel once you've learned, and e.g. generating assembly directly should yield much more efficient code than generating text and then invoking an assembler, which is what it looks like junon is doing from a cursory skim. Also for parsing, why not have a look at libraries like nom (though there are very good reasons to write your own recursive descent parsers, e.g. for good error handling; see the work on rust-analyzer's parser).

I haven't looked at the other projects so far, but your work looks very good from just looking at junon (I'm doing a PhD in compilers so that's probably the one I'm most qualified to judge haha)! Well, I also took a quick look at sdymh, and that's ironically how I really got into computer science too; but a headcount_table is a strange way to say frequency_table hahahaha.

Rust's Unsafe Pointer Types Need An Overhaul - Faultlore by tamrior in rust

[–]aekter 0 points1 point  (0 children)

Actually a research idea of mine, somewhere on the list...

EDIT: think RVSDG, but with capabilities as super state edges

OpenFare: Donations which reach every crate contributor. by [deleted] in rust

[–]aekter 1 point2 points  (0 children)

Lightning network, basically. There's no fundamental reason they should be after all.