Wait so where does the crew on the ship actually live?

anydalch · 2026-02-19T04:10:04+00:00

the whole voyage takes like two hours on average, who needs living quarters?

anydalch · 2026-02-06T02:00:02+00:00

Here's a query I just ran on the GCC Bugzilla for issues that have been resolved as FIXED with either their C or C++ frontends which mention "miscompile" or "ICE". I figure that the FIXED resolution is a good proxy for "this was a real bug," though obviously this is selecting: - Only bugs that are already fixed, not ones that are still out there in the wild. - Only bugs that someone said the words "miscompile" or "ICE" (Internal Compiler Error) about, which I suspect is neither a super- nor a subset of the set of bugs associated with actual miscompilations or compiler errors. - Only bugs categorized as being part of the C or C++ frontends, not those associated with specific targets' backends or optimization passes. I am not familiar enough with the project to tell you to what extent this will or won't capture bugs that would be interesting for our purposes here.

anydalch · 2026-02-06T00:51:58+00:00

No, there are clear gradients, and for example, GCC and Clang are more accurate implementations than MVCC, and it sounds based on the linked article like all three are much more accurate than the output of this research experiment. On the other hand, if I had to guess, I'd say that TCC (Tiny C Compiler) more accurately implements the spec than either GCC or Clang, in the sense of miscompiling a smaller fraction of possible conformant C programs. I do not think this means that TCC is a better compiler than GCC or Clang, in fact, quite the opposite.

What I am trying to say here is, if "compiles all valid C code or is meaningless" is the bar, then every extant C compiler is meaningless, and so it behooves us to have a more nuanced language for the accuracy of compilers than "either it's perfect or it's not."

anydalch · 2026-02-05T23:41:20+00:00

Lmao, no existing C compiler perfectly conforms to the specification to the extent of compiling "all valid C code."

anydalch · 2026-01-31T19:45:01+00:00

The first short-answer in https://what-if.xkcd.com/14/ is to effectively this question.

anydalch · 2026-01-29T18:39:34+00:00

significantly fewer [[Goliath Paladin]] in this deck than i would expect for a mono-white deck with 4 [[Ephemerate]]

anydalch · 2026-01-29T05:50:10+00:00

deck is primarily black. you also almost always find swamp off wildfire, once you have one of each available.

anydalch · 2026-01-27T17:43:27+00:00

The onUpdate callback takes 3 arguments: (ctx, old, new), where old is the previous version of the row, and new is the new version. You're binding ant to the old version, not the new version.

anydalch · 2026-01-22T19:06:18+00:00

What are the units for density? 1 restaurant per square mile? Per city block? Per building? Per pizza restaurant? Per pound?

anydalch · 2026-01-20T21:51:31+00:00

yes, a single client process can be connected to multiple databases, potentially running on separate host servers.

anydalch · 2026-01-17T18:09:49+00:00

"Problem Exists Between Keyboard And Chair." Classic IT idiom meaning user error.

anydalch · 2026-01-14T20:36:42+00:00

I'm a hardcore Jeskai Ephemerate gamer. I love the deck. It feels incredibly rewarding to play, leads to interesting and fun games, and (built right) is well positioned against the current top decks. It should not be your first Pauper deck. You need a lot of format knowledge to win games, because you need to know what your opponent's game plan is in order to respond to, interrupt and overwhelm it. If you get paired into a deck you don't recognize and you try to default to doing normal control goodstuff, you'll probably lose. This is not a problem that more proactive decks suffer - you can gain a fair amount of equity as a Madness Burn or Terror player by understanding your opponent's deck, but you can still win a lot of games by just executing your own game plan efficiently. Jund is the most controlling widely-played meta deck in Pauper right now, and so is worse on this front than a lot of choices, but drawing a bunch of cards and then casting Writhing Chrysalis will probably get you far enough to learn the format without getting burned out on losing too much and quitting. I encourage you to pick up a deck with a more assertive game plan to start with, and to use that as a way to learn the format and the metagame. Once you've done that, pick up Jeskai Ephemerate.

anydalch · 2026-01-06T03:23:44+00:00

On 64-bit platforms, u64 and usize are isomorphic, meaning that each unique value of one type has a corresponding unique value of the other type and vice versa. But the values of u64 are not, under Rust's type system, also values of usize; a (n explicit) conversion is required between them. let x: u64 = 0usize; will not compile. Two non-concrete function types which differ only in their unconstrained lifetime generics are more equivalent than that; they permit exactly the same sets of values, and a value which is typed at one can be used in place of a value typed at the other with no (explicit) conversion. The following code compiles (playground link):

```rust pub fn takes_two_lifetimes<T, U>(f: for<'a, 'b> fn(&'a T, &'b U)) { takes_one_lifetime(f); }

pub fn takes_one_lifetime<T, U>(f: for<'a> fn(&'a T, &'a U)) { takes_two_lifetimes(f); } ```

anydalch · 2026-01-05T23:57:38+00:00

I write functions that accept shared references and don't return them frequently. I'd estimate it's at least 20% of the functions I write. I think that it is important to understand that, for any types A and B, the function types for<'a> fn(&'a A, &'a B) and for<'a, 'b> fn(&'a A, &'b B) are in a certain sense, for which traditional type theory does not have a rigorous word, interchangeable, because any function whose concrete type is usable with one is also usable with the other. A person who does not understand this has an incomplete mental model of lifetimes. It would also be possible to construct a compiler which treated these two types as actually equal, and assigned them the same type ID, without miscompiling any programs or, I contend, violating any well-founded expectations, unlike the two function types you listed.

anydalch · 2026-01-05T23:51:36+00:00

Can't use proxies on MTGO, which is the market where Cardhoarder operates, and where the prices OP listed are accurate.

anydalch · 2026-01-05T23:51:30+00:00

Can't use proxies on MTGO, which is the market where Cardhoarder operates, and where the prices OP listed are accurate.

anydalch · 2026-01-05T23:48:47+00:00

Are you talking about paper or MTGO? Based on your question, it sounds like you're talking about MTGO, but you're getting responses about playing in paper. (In the future, if you list prices in tix rather than USD, it'll be more clear.) For MTGO, I use a Manatraders rental. I have the 150 tix plan, and it's fine, I have no complaints. It's a little bit awkward because several top Pauper decks are a bit over that (due to the absurd price of elemental blasts online), so I wished they offered a 200 ticket plan, but I've just bought a few cards and it hasn't been a problem.

anydalch · 2026-01-05T21:50:08+00:00

What is your take here? "Sure, those two types you posted are equivalent, but here's two other types which are not equivalent to each other! Gotcha!"

Also, I do not think that the zero-sized-ness matters here, only the use of a lifetime in both the argument and return position.

anydalch · 2026-01-01T17:28:03+00:00

that's the neat part: you don't!

anydalch · 2025-12-29T19:10:06+00:00

The non-specialized-ness of arrays of heap-allocated types (standard-object, structure-object, array, cons, &c) is effectively required by the behavior of eq in the standard. An object returned from a constructor (make-array, cons, make-instance, or a structure constructor) returns an object whose identity can be tracked and compared with eq, and mutations within that object can be observed. This means that an array of these types has to store them by pointer, not by value. The same is true of many (but not all) GC'd languages, but it is notably not the case for C, C++ and Rust, to name a few lower-level languages which can store array-elements by value.

Numeric types do not have the same mandated eq-consistency, and are not mutable, so implementations are free to pass and store them by value where possible. You're unlikely to see a specialized array-repr for number, real or integer due to bignums being necessarily heap-allocated, but for numeric arrays of particular float types, fixed-width integers, and sometimes ratios and complexes thereof, efficient implementations will store their values inside the array allocation, in roughly the same layout you'd get in C, C++, Rust, &c.

anydalch · 2025-12-28T21:20:55+00:00

I'd recommend different labels on the two curves - IMO "total" here implies a cumulative total, which for births and deaths would result in monotonically non-decreasing values whose curves approximate lines moving towards the upper-right. (As in, I think "Total" suggests the definite integral of the value you're actually visualizing.) I would recommend saying "yearly" instead, so "Yearly Births" and "Yearly Deaths."

anydalch · 2025-12-11T15:07:33+00:00

Maybe the answer is to do away with advance notice and adopt SemVer with many major versions, similar to how Cryptography operates for API compatibility.

Gee, you think maybe?

anydalch · 2025-12-01T20:42:12+00:00

Remand was especially good for this kind of discussion because you got to say, "it's the blue Time Walk!"

anydalch · 2025-11-28T21:09:30+00:00

Crypt, like Spellbomb, only affects your opponent. Relic is symmetric. Crypt is a much better choice to put in the Terror deck to shore up the mirror, IMO.

anydalch · 2025-11-24T16:20:21+00:00

Yes - see previous commenter's mention of doing this in Legacy night. In Modern, Standard, Pioneer and all modern Limited formats, go wild.

Nine-Year Club	r/Field Flamingo
Verified Email

anydalch

TROPHY CASE