Green is in the center of the visible spectrum of light (notice the G in the middle of ROYGBIV), so evolution should theoretically optimize for green light absorption. An interesting article on why plants typically reflect that wavelength and absorb the others: https://en.wikipedia.org/wiki/Purple_Earth_hypothesis
Green is the highest energy light emitted by our sun, from any part of the entire light spectrum, which is why green appears in the middle of the visible spectrum. The visible spectrum basically exists because we "grew up" with a sun that blasts that frequency range more than any other part of the light spectrum.
I have to wonder what our planet would look like if the spectrum shifts over time. Would plants also shift their reflected light? Would eyes subtly change across species? Of course, there would probably be larger issues at play around having a survivable environment … but still, fun to ponder.
That comment does not make sense. Do you mean the sun emits it's peak intensity at green (I don't believe that is true either, but at least it would make a physically sensical statement). To clarify why the statement does not make sense, the energy of light is directly proportional to its frequency so saying that green is the highest energy light the sun emits is saying the sun does not emit any light at frequency higher than green, i.e. no blue light no UV... That's obviously not true.
> Do you mean the sun emits it's peak intensity at green (I don't believe that is true either, but at least it would make a physically sensical statement).
Yes, that's what I meant, as I was sloppy with my language, and it's definitely true.
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.
> you have to turn off strict aliasing because inheritance is implemented by the old "common meta struct as first member" idiom
You shouldn't have to turn off strict aliasing for that, struct pointers are allowed to alias pointers to their first member. Unless I'm missing some awkward compatibility rule that mruby breaks.
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.
Oof, I get it now. I was expecting RHash to start with an actual RObject, not just the same members. I too read the "compatible first member" rule as not applying here, so I agree it breaks strict aliasing.
I think it's fatigue. His stuff appears on the front page very often, and there's often tons of LLM stuff on the front page, too. Even as an LLM user, it's getting tedious and repetitive.
I don't think it's implying that at all. Especially with the accompanying sentence. The implication is that hyper focusing on news is distorting our perception of normal.
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.
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.
> mostly web developers who care about this in the first place.
I’m not sure what you mean by this. We care about our users and how they use our websites. JavaScript is everywhere and has been the de facto frontend standard for the past few years. Supporting no-JS is starting to feel like supporting a new browser. As much as I’d like to, from a business and product point of view, the numbers are just too small for us to even consider it.
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.
I can understand the aspiration to have the system that can be run from the lowest level out of box tools, but then, I am doing frontend for almost a decade and this is porbably the first time I'm seeing such attention to this specific 'no js' use case, as in this thread.
Maybe I'm not reading enough webdev forums. I agree though that things that don't required js should be written in no js way.
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.
No. Aliasing is a single idea, an alias is another name for the same thing. The concept translates well from its usual English meaning.
The C "strict aliasing" rule is that with important exceptions the name for a thing of type T cannot also be an alias to a thing of type S, and char is an important exception. Linux deliberately switches off this rule.
Rust's rule is that there mustn't be mutable aliases. We will see why that's important in a moment.
Aliasing is an impediment to compiler optimisation. If you've been watching Matt's "Advent of Compiler Optimisation" videos (or reading the accompanying text) it's been covered a little bit in that, Matt uses C and C++ in those videos, so if you're scared of Rust you needn't fear that in the AoCO
But why mutation? Well, the optimisations concern modification. The optimiser does its job by rewriting what you asked for as something (possibly not something you could have expressed at all in your chosen language) that has the same effect but is faster or smaller. Rewrites which avoid "spilling" a register (writing its value to memory) often improve both size and speed of the software, but if there is aliasing then spilling will be essential because the other aliases are referring to the same memory. If there's no modification it doesn't matter, copies are all identical anyway.
Fair enough, I meant in terms of what rules and restrictions exist around aliasing, which are different between the two, but my wording was indeed off.
