benschulz · HackerTrans

benschulz

no profile record

comments

10 miesięcy temudiscuss

This seems like an uncharitable reading of the post.

> They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code

I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work.

> Also blaming the users of your language for your language not being able to meet their needs isn’t a good look.

Isn't that what the whole post is about though? They even say the following.

> Returning to earth: we may be academics, but we are trying to build a real programming language. That means listening to our users and that means we have to support print debugging. The question is how?

12 miesięcy temudiscuss

Most approaches, I assume, will leverage conditional compilation: When (deterministic simulation) testing, use the deterministic async runtime. Otherwise, use the default runtime. That means there's no (runtime) overhead at the cost of increased complexity.

I'm using DST in a personal project. My biggest issue is that significant parts of the ecosystem either require or prefer your runtime to be tokio. To deal with that, I re-implemented most of tokio's API on top of my DST runtime. Running my DST tests involves patching dependencies which can get messy.

w zeszłym rokudiscuss

Because the compiler optimizes based on the assumption that consecutive reads yield the same value. Reading from uninitialized memory may violate that assumption and lead to undefined behavior.

(This isn't the theoretical ivory tower kind of UB. Operating systems regularly remap a page that hasn't yet been written to.)

4 lata temudiscuss

IIRC integer literals are the blocking issue here. Bounds checking (and elision) happens anyway, but when `Index<T>` is implemented for multiple integer types, `foo[0]` becomes ambiguous.

5 lat temudiscuss

> It's difficult to escape the notion that FreeBSD is becoming an operating system by, and for, FreeBSD developers.

I'm curious: Why _shouldn't_ it be an OS primarily for its developers? Why should they focus on others when they're the one building it?

5 lat temudiscuss

Sorry, based on the replies I'm getting I did not make myself clear. I only want to use Either in cases like the following.

    fn some_func() -> impl SomeTrait {
        if some_condition {
            Either::Left(a)
        } else {
            Either::Right(b)
        }
    }

Both a and b will implement SomeTrait which is all callers care about. However, because they're structurally different they must be wrapped in an Either that delegates all methods from SomeTrait to a or b respectively.

5 lat temudiscuss

Can you expand on that? As long as the public type is opaque I don't see what there is to regret.

5 lat temudiscuss

I wish there was an `Either` type in std. I realize that there used to be one and we have `Result` now. However, now that we have `impl Trait` it's worth revisiting, I believe. If we don't we'll have the one from `itertools`, the one from `futures` etc.

In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.

5 lat temudiscuss

Lamport acknowledges the report, not the error. I'm still not convinced there even is an error.

The state after step 9 should be the same as after step 7, i.e. `A(-:-,100) B(100:b,100) C(100:b,-)` because C needs to retain the "highest-numbered proposal" it accepted, not the one it accepted last. That means the nine steps outlined in the post/on StackOverflow do not, by themselves, demonstrate any problem.

So what additional steps are missing/what alternative steps actually produce an inconsistency/divergence?

5 lat temudiscuss

Quoting from the paper's description of Phase 1:

> (b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.

It says an acceptor must respond with the highest-numbered proposal (if any) that it has accepted.

How is acceptor C going to do that after step 9? That's where the bug is introduced, I think, not anywhere in the paper.

5 lat temudiscuss

I believe this is mostly due to the switch to LLVM 13[1].

[1]: https://twitter.com/ryan_levick/status/1443202538099073027

5 lat temudiscuss

I don't know that artist in particular, but perhaps you can find them on The Mod Archive?

https://modarchive.org/index.php?request=search&query=axel+f...

5 lat temudiscuss

I always assumed it's the verb uring[1], but that might well be wrong.

[1]: https://en.wiktionary.org/wiki/uring

5 lat temudiscuss

My understanding is that it has been manually tested. I.e. it has produced correct results to previously intractable problems. I'm not sure how much automated testing would add at that point.

5 lat temudiscuss

> In spite of this, I am in the top 7% of accounts on the site, which is a nice reminder on the power of compound interest!

I'm also in the top 7%. That's down from 12% or so from five years ago. However, I haven't gained many points during the same interval. That leads me to believe it's not about compound interest but new users joining.

5 lat temudiscuss

> You forgot to disclose your […] affiliation, btw.

Um.. :D

5 lat temudiscuss

The whole book is available here: https://www.csee.umbc.edu/courses/331/resources/lisp/onLisp/

5 lat temudiscuss

> Data races are undefined behavior, and race conditions are a logic error. Yes, both are bugs, and both are important to fix. But they have (at least to me) different severities.

Some data races really are benign while some other race conditions can lead to data corruption or security vulnerabilities. Why then should data races be strictly more severe than data races? What am I missing?

5 lat temudiscuss

Actually "this context" was my previous reply. Much like I can nest a lexical scope inside a program and have it reach up and past the containing scope, I can create a new context in a discussion. Please at least try to understand my position before you reply.

5 lat temudiscuss

It's possible to have truly benign data races too, e.g. lazily computing a hash of immutable data.

One of the reasons that Rust's ownership model is necessary is most data races cannot otherwise be statically detected. The compiler will be unable to apply any of its theoretical UB optimizations. It will emit its native code and you get the defined behavior of the underlying hardware. There will be no undefined behavior. If that ever changes, the bigger news, I imagine, will be that we solved the halting problem.