HN user

MyOutfitIsVague

919 karma
Posts0
Comments299
View on HN
No posts found.

You do need to turn off strict aliasing for that, because mruby uses `struct RObject { RB_OBJECT_HEADER; ... }` and `struct RHash { MRB_OBJECT_HEADER; ... }` (where MRB_OBJECT_HEADER begins with `RClass `). You can alias objects of both types as an `RClass `, but you can't alias them as one-another, converting RHash to RObject. According to my reading of the strict aliasing rules[0], the aliasing would be legal if one of the types literally contained the other, or if they were being accessed through a union. The "compatible types"[0] section requires the types to be exactly the same in layout, not just starting as the same. It's not safe to cast incompatible structs to one another just because they have the same initial members, unless you are accessing them through a union (C11 6.5.2.3p6). Optimization can cause UB when working with mruby if strict aliasing is enabled.

[0] https://en.cppreference.com/w/c/language/object.html#Strict_... [1] https://en.cppreference.com/w/c/language/compatible_type.htm...

There is plenty of room in science for research that is just to examine and collect data. I don't understand your argument that science should only be to demonstrate claims and "completing" theories. Is science not about experimenting to slowly form a more complete understanding about how our world works? Research that does little more than collect novel data and show probable correlations is still extremely valuable.

The MRuby embedding API isn't a whole lot like Lua's. Lua is a fantastic experience to embed. You might have to futz with the registry to store Lua objects in a C struct, but the abstraction allows you to almost never have to actually worry about the VM internals or the GC directly. Mruby is a lot more like MRI Ruby's API. Raw objects are exposed to you, you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom, you have to manually trigger VM collecting in long-running C code ( https://github.com/mruby/mruby/blob/master/doc/guides/gc-are... ), getting args in a C function involves a variadic scanf-style function. The most striking difference is documentation. The documentation of the mruby C API is actually "read the headers". There are many seemingly redundant functions that look like they do the same thing, completely without explanatory comments, or minimal inscrutable comments:

    /* mrb_gc_protect() leaves the object in the arena */
    MRB_API void mrb_gc_protect(mrb_state *mrb, mrb_value obj);
    /* mrb_gc_register() keeps the object from GC. */
    MRB_API void mrb_gc_register(mrb_state *mrb, mrb_value obj);
    /* mrb_gc_unregister() removes the object from GC root. */
    MRB_API void mrb_gc_unregister(mrb_state *mrb, mrb_value obj);
I'd rather work with Ruby as a language than Lua, but I'd much rather work with Lua than Mruby for the documentation and API alone. If mruby had anything close to the Lua reference documentation, I'd be all over it. As-is, embedding mruby kind of sucks, which is a real shame.

If your friend then believes that work, sleep, and hygiene are not things you did at all because you don't talk about them, then your analogy would be comparable. People believe homicide and terrorism are significantly more common than they are, and vote accordingly. It's affecting all of our lives. Let me know when your vacation stories change public policy, and then I'll start complaining about those.

I didn't imply that all web developers care about it, but that most of the people who care about it are web developers. I won't deny that it's still a minority.

It's a common philosophy for developers with standards of robustness and accessibility to not hard depend on js for things that don't need js to function.

Why the target audience of the ruby, probably primary web developers, whould do that?

In my experience, it's mostly web developers who care about this in the first place.

It's worth noting that "aliasing" in Rust and C typically mean completely unrelated things.

Strict aliasing in C roughly means that if you initialize memory as a particular type, you can only access it as that type or one of a list of aliasable types look like char. Rust has no such restriction, and has no concept of strict aliasing like this. In Rust, "type aliasing" is allowed, so long as you respect size, alignment, and representability rules.

Aliasing safety in Rust roughly means that you can not have an exclusive reference to an object if any other reference is active for that reference (reality is a little bit more involved than that, but not a lot). C has no such rule.

It's very unfortunate that such similar names were given to these different concepts.

The accusations aren't "towards anyone who dares question her", they're towards people who assume that she had come in after the fact and unfairly got into somebody else's role, which is ignorant (and easily cleared up by glancing at a Wikipedia article) and also a common refrain aimed at any woman in any position of authority.

I'm not a fan of Baker for many reasons, but "how did she even get that role?" always pings my shithead radar, and isn't a question I hear for incompetent male CEOs, who are assumed to be just incompetent, while the women are assumed to be incompetent infiltrators who were hired on the basis of their sex.

GPT-5.2 7 months ago

Do you have a better word that describes "things that look correct without definitely being so"? I think "plausible" is the perfect word for that. It's not a sleight of hand to use a word that is exactly defined as the intention.

I'm certain it wouldn't, and you're certain it would, and we have the same amount of evidence (and probably roughly the same means for running such an expensive experiment). I think they're more likely to go slowly mad, degrading their reasoning to nothing useful rather than building something real, but that could be different if they weren't detached from sensory input. Human minds looping for generations without senses, a world, or bodies might also go the same way.

Also, I think there is a very high chance that given an existing LLM architecture there exists a set of weights that would manifest a true intelligence immediately upon instantiation (with anterograde amnesia).

I don't see why that would be the case at all, and I regularly use the latest and most expensive LLMs and am aware enough of how they work to implement them on the simplest level myself, so it's not just me being uninformed or ignorant.

These discussions often end up resembling religious arguments. "We don't know how any of this works, but we can fathom an intelligent god doing it, therefore an intelligent god did it."

"We don't really know how human consciousness works, but the LLM resembles things we associate with thought, therefore it is thought."

I think most people would agree that the functioning of an LLM resembles human thought, but I think most people, even the ones who think that LLMs can think, would agree that LLMs don't think in the exact same way that a human brain does. At best, you can argue that whatever they are doing could be classified as "thought" because we barely have a good definition for the word in the first place.

Could an LLM trained on nothing and looped upon itself eventually develop language, more complex concepts, and everything else, based on nothing? If you loop LLMs on each other, training them so they "learn" over time, will they eventually form and develop new concepts, cultures, and languages organically over time? I don't have an answer to that question, but I strongly doubt it.

There's clearly more going on in the human mind than just token prediction.

Everyone is out here acting like "predicting the next thing" is somehow fundamentally irrelevant to "human thinking" and it is simply not the case.

Nobody is. What people are doing is claiming that "predicting the next thing" does not define the entirety of human thinking, and something that is ONLY predicting the next thing is not, fundamentally, thinking.

In our advent-style calendar below, find our top pick of what lies in store for 2026. Each day, as we move through December, we’ll open a new window to reveal our highlights! By public domain day on January 1st they will all be unveiled — look out for a special blogpost from us on that day. (And, of course, if you want to dive straight in and explore the vast swathe of new entrants for yourself, just visit the links above).

It's not forced if you were getting it all for free anyway and can walk away at any time. "They've stopped giving away old thing for free and are now only doing new thing" doesn't put you in the position of a captive who has no freedom. You can complain, you can develop your own solutions, you can leave, but I find it over the line the number of people in the X11/Wayland conversation whose position amounts to looking at people who are working for free, and demanding that they do a specific kind of free work without compensation or help. It's all people working on their free time, or companies sponsoring the developments they need. It's hard to make demands as an end user who isn't paying or even helping.

X11 is not really fixable, architecturally. This wasn't some authority saying "X11 is over, stop working on it." It was the X11 developers and DE and WM developers who work directly with the protocol deciding that it's untenable to fix, and something new is actually the right call. That's the important thing that many people are missing: the X11 developers ARE the Wayland developers, and they actually have good reasons.

Nobody is stopping you from pulling together a group and working on all this free software, forging forth on Xorg, and forking or maintaining the DEs to work with X11 as long as you want to maintain it. I think the group of people who wants to do that will be quite small, because I've really only seen the sentiment from people who have never actually hacked on an X11 codebase and worked with the protocols themselves. You can want X11 to stay alive, but you can't really demand the people who don't want to work on it anymore to keep working on it.

C++ is far better than C in very many ways. It's also far worse than C in very many other ways. Given a choice between the two, I'd still choose C++ every day just for RAII. There's only so much that we can blame programmers for memory leaks, use-after-free, buffer overflows, and other things that are still common in new C code. At some point, it is the language itself that is unsuitable and insufficient.

When you already work 40+ hours a week and big companies suddenly start an AI snowblower that shoots a dozen extra hours of work every week at you without doing anything to balance that (like, for instance, also opening PRs with patches that fix the bugs), the relationship starts feeling like being an unpaid employee of their project.

What's the point of just showering these things with bug reports when the same tool (or a similar one) can also apparently fix the problem too?

There's a helpful crate that abstracts that away: https://docs.rs/ordered-float/latest/ordered_float/

You have a strongly ordered `NotNan` struct that wraps a float that's guaranteed to not be NaN, and an `OrderedFloat` that consideres all NaN equal, and greater than non-NaN values.

These are basically the special-cases you'd need to handle yourself anyway, and probably one of the approaches you'd end up taking.