dthul

I tried getting an interview for one of those LinkedIn posts and even though I had a really good starting point (successful internship within the last few months plus an internal referral from someone working in the group I applied for plus being a good fit based on my skills and education) I wasn't even invited for a first interview, only got a generic rejection by email. So I don't think these postings are all real.

To chime in with my personal experience, I did actually lose almost two days on hunting down an unintended copy constructor call. The method expected a "const B&" but was called with a "const A&". It also happened to be called a lot. The actual type names were longer and very similar, and looking at the code it was hard to see they were different. Type B had a copy/conversion constructor from type A so every time the method was called all of the data contained in A would be cloned. I was very relieved when I finally found the issue but also wished that C++ wouldn't call (possibly expensive) constructors so hiddenly, even going so far as to not only do that for value types but even for reference types.

That's a great point! If you can guarantee that the threads don't outlive the Mutex an Arc is not even necessary.

It's very cool that mutexes on Linux don't require an allocation anymore! A very common pattern is to use an Arc<Mutex<T>> for sharing ownership across threads and as far as I can tell this will now only require one allocation instead of two.

Thanks for the explanation, I will definitely check out the docs on algebraic effects!

Looks very cool! Can somebody enlighten me what's happening in the Algebraic Effects example? Specifically this part:

    handle f ()
    | flip () -> (resume true + resume false) / 2.0

Does `handle f ()` call `calculation` and the `| ...` part "injects" the `flip` effect? I am also quite confused by the part following `| flip ()`. It somehow returns true or false with a probability of 50%? And why does this give you the expected value of the whole calculation function in the end?

OT: sqlx tip: you can compile without a DB connection by either using the non-macro version of the queries (at the cost of losing compile time query checking) or you "bake" the query checks using sqlx-cli which produces files that you can check into your repo and allow the macros to compile offline. In that case you only need to re-connect to the DB when the SQL queries change.

> please read at least your article

Please refrain from accusations of someone not having read the article, it's unconstructive and against site guidelines.

I don't know how you come up with a different reading of the nau.ch article. It states (even though it's an inaccuracy as there are still some 1st generation vaccines available as we figured out):

"Der Pockenimpfstoff gilt als erster der Geschichte. Nur nützt das die Schweiz in der aktuellen Situation mit immer mehr Fällen von Affenpocken nicht. Denn hierzulande ist kein Impfstoff zugelassen."

So what it boils down to: The old (1st generation) vaccine is still being held in storage but currently not available to the general public (says https://www.bag.admin.ch/bag/de/home/krankheiten/krankheiten..., FAQ number 10). It could be made available in case of an outbreak. There is no approval for any of the more modern vaccines.

Because the article talks about the theoretical effectiveness of smallpox vaccines against monkeypox but that no vaccine (smallpox or monkeypox) is currently approved in Switzerland (the smallpox vaccine was approved in the past but is not anymore since its eradication)

afaik no smallpox vaccine is currently approved in Switzerland (according to https://www.nau.ch/politik/bundeshaus/affenpocken-swissmedic...)

Yes, I think it boils down to whether creating a derived pointer from a restrict pointer and then using both is allowed. I just had a look at the C standard and I think it is allowed if the derived pointer is (what the standard calls) "based" on the restrict pointer (page 89, 6.7.3.1 paragraph 3: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf). The standard language is very dense but it makes it sound like the program presented in the article would not uphold this "based" property and so might be UB as you suspected.

But it's never modified using y?

> and then promptly uses pointer arithmetic to create an alias. It violated the promise.

afaik not creating aliased pointers is not a promise you make when marking a pointer as restrict. Only when using that aliased pointer for accesses (in the presence of modifications) can you actually break the promise. To quote cppreference:

"During each execution of a block in which a restricted pointer P is declared (typically each execution of a function body in which P is a function parameter), if some object that is accessible through P (directly or indirectly) is modified, by any means, then all accesses to that object (both reads and writes) in that block must occur through P (directly or indirectly), otherwise the behavior is undefined"

> The author clearly states that restrict is a promise, and then immediately violates that promise

Which part of the program do you believe violates the restrict promise?

I think it's not obvious that it is violated. The question is whether a pointer obtained through an integer round trip is considered to be derived from the original pointer. The author assumes that it is.

Indeed I don't think C cares about how the pointers you mark as "restrict" were constructed, it just cares about how you actually use the pointers and in the example code they are never used in an "overlapping" way.

I just checked cppreference and it says: "if some object that is accessible through P [marked restrict] (directly or indirectly) is modified, by any means, then all accesses to that object (both reads and writes) in that block must occur through P (directly or indirectly), otherwise the behavior is undefined"

The only accesses I can see are "*x = 0;", "*ptr = 1;" and "return *x;". "*ptr" is an indirect access through "x" by way of an integer round trip. If the orignal program is indeed UB that would mean that pointers built from an integer round trip are not considered (indirect) accesses through the original pointer.

The author assumes that it is an indirect access: "However, the only possibly suspicious part of the original program is a pointer-integer-pointer round-trip – and if casting integers to pointers is allowed, surely that must work. I will, for the rest of this post, assume that replacing x by (int*)(uintptr_t)x is always allowed."

Such non-constructive comments are not appreciated here.

This document describes the smart contract for an NFT: https://eips.ethereum.org/EIPS/eip-721

The base contract does not contain any info about the asset the NFT applies to and the metadata extension only allows you to store a name and a URI (which hopefully still works and still points to the object in the future). There is no object hash as far as I can tell.

Afaik there can be several NFTs for the same object (URI) and none of them is inherently more legitimate than the other. You'd need some kind of endorsement by tha artist to know which NFT is the "real" one. But I'm not an expert so please correct my if I'm wrong.

Just want to mention that Cargo (don't know about others like NPM) handles it a bit differently.

You are quite flexible in specifying the versions of your direct dependencies and you can fix major, minor or patch versions or do even more complex stuff with version ranges (even though I see the latter rarely used in practice).

In addition, different versions of the same crate can coexist (but their types are considered distinct). So if I directly use libparser 1.1.1 but one of my dependencies uses libparser 1.2.3 that's totally fine. The version of my direct dependency won't silently be upgraded (assuming you fixed the minor or even the patch version when specifying that dependency).

It looks like Namecheap has 1700 employees in Ukraine and an office in Kharkiv: https://www.namecheap.com/careers/ukraine

I was wondering whether the Rust compiler could treat Result enums specially and implement them as panics under the hood. But I guess such optimizations are not really feasible because they might change behavior when unwinding through FFI for example. Not even speaking of the possibility that each stack frame is able to convert the error type, unlike exceptions.

Thanks! I didn't realize that it required curly braces and only went off of the red squiggly line my IDE put there instead of reading the helpful compiler output.

Really looking forward to const generics becoming more and more useful in the future! A current limitation I hit yesterday is that you can't use a (non-literal) expression as a const generic parameter yet. I wanted to specify 32KiB as "32 * 1024" but had to write "32768" instead.

Does anybody know what happens when the bid is not equal to but higher than the ask? What is the price that will be used? Or will this not lead to a transaction at all?

I went with a hybrid approach in university: I didn't take any notes in class so I could actually focus on the lecture and actively think along. Later, in preparation for the exam, I would go through all slides again and turn them into notes, compressing a whole lecture down to 20 pages or so.

I wonder if this mechanism could also be used for bounds checking when accessing dynamically sized collections. That would be a boon for C/C++ as well as safe languages.

But I guess it can not because while the underlying allocation may have space for 100 objects, the high-level container might only have initialized the first 10 objects for example.

Did that behavior change at some point? I'm on Big Sur and clicking on an unfocused window will focus it and trigger whatever button your mouse landed on.

Edit: it seems to depend on the kind of button(?)

I guess it would depend on how that NFT was marketed at the time of purchase. If a piece of digital artwork was displayed on the NFT's web page and the buyer believed that they would get ownership of that artwork in return for their money a court might side with the buyer.

Good to know! I don't know much about the blockchain space and have only looked more closely at Ethereum so far.

The views on centralized services such as Infura really resonate with me. A few months ago I looked into how Ethereum and smart contracts work and got excited that there is basically this shared "virtual machine" with persistent, public state that can only be altered by interacting with those smart contracts.

But soon after it became clear that it is not really possible for me (or any regular "client" as the article calls it) to look at the state of the virtual machine and evaluate view functions myself. The block chain is so large already that we need to rely on big servers which are operated by other people to do this.