| 17 Oct 2026 | |||
| MasterDuke | 60746 $?CLASS - find_method | 18:38 | |
| 5209060 $?CLASS - !cursor_start | |||
| ^^^ from building part of rakudo | |||
| oops, no, that's from my log parsing example | |||
| 181164 $?CLASS - type_check | |||
| 194585 $?CLASS - | |||
| 464446 $?CLASS - list | |||
| 553309 $?CLASS - visit_children | |||
| 590099 $?CLASS - EXPR | |||
| ^^^ *that's* from building part of rakudo | 18:39 | ||
| !cursor_start used to be 11m before my PR was merged. but i don't know why it isn't even less now... | 18:40 | ||
| there are no explicit references to $?CLASS in any EXPR, or visit_children, or a bunch of the others | 18:44 | ||
| i wondered if it was inlining, but i tried with MVM_SPESH_INLINE_DISABLE=1 and also with --optimize=0 (for rakudo), but no difference | 18:49 | ||
| japhb | Something checking that a method is being invoked on an expected class? Perhaps as part of a method cache? | 18:59 | |
| lizmat | .tell MasterDuke did you see github.com/Raku/nqp/commit/e5e5a905f1 ? | 19:48 | |
| tellable6 | lizmat, I'll pass your message to MasterDuke | ||
| 23 Oct 2026 | |||
| lizmat | so nqp::cmp_n has slightly different semantics to infix:<cmp>(Num,Num) | 14:27 | |
| the latter places NaN as higher than any Num value, the former assumes NaN is the same as any num value | |||
| the fix: nqp::cmp_n($a,$b) || nqp::iseq_s($a,"NaN") - nqp::iseq_s($b,"NaN") | 14:28 | ||
| I wonder how difficult it would be to incorporate this into the nqp::cmp_n op at the MoarVM level | |||
| feels like it should just be a few extra lines in interp.c at line 851 | 14:30 | ||
| (and possibly some JIT changes?) | 14:31 | ||
| japhb | NaN should *not* be higher (or lower) than any Num. In particular, it is *not comparable* in the mathematical sense, and in the IEEE sense it should return false for any comparison. | 18:47 | |
| So the current cmp implementation is incorrect if it claims NaN is More than anything else. | 18:48 | ||
| lizmat | There's a spectest expecting NaN,-Inf,Inf to sort as -Inf,Inf,NaN | ||
| m: dd (NaN,Inf,-Inf).sort | 18:49 | ||
| camelia | (-Inf, Inf, NaN).Seq | ||
| lizmat | so how should that be sorted ? | 18:50 | |
| [Coke] | I think expecting NaN to sort a certain way is probably wrong unless that's part of a standard. | 19:16 | |
| (I think making sure at least the two Inf's are sorted correctly is correct, of course) | |||
| ShimmerFairy | Unless the IEEE standard says something about it, for sorting purposes you need NaN to come out True for *something*, or else the sorting algorithm can't end (right?). But since infix:<cmp> is more general than sorting, that's not the right place to add any special sorting behavior. | 19:19 | |
| lizmat | m: dd NaN cmp Inf | 19:21 | |
| camelia | Order::More | ||
| lizmat | that's the underlying reason for the behaviour fwiw | ||
| ShimmerFairy | After a bit of digging, IEEE-754 apparently defines a totalOrder() operation that's exactly what you'd want for sorting floats: en.wikipedia.org/wiki/IEEE_754#Tot..._predicate | 19:29 | |
| So infix:<cmp> for Nums ought to be changed (as much as possible) to match that, since our cmp isn't designed to signal unordered results. | 19:30 | ||
| [Coke] | +1 | 19:31 | |
| lizmat | so that's basically what the HLL cmp does | 19:38 | |
| japhb | That's ... rather odd. I mean, I get why they went there, but I was not expecting this. I sit corrected. | 21:16 | |
| Turns out my knowledge there was just out of date. | 21:21 | ||
| Normally at this point I would go read the spec changelogs, but ... I'm a bit busy at the moment for that. | 21:22 | ||
| 24 Oct 2026 | |||
| Geth | MoarVM: MasterDuke17++ created pull request #2057: Use (some of?) IEEE 754 total ordering rules for cmp_n |
02:39 | |
| taraz | not that I care so much, but standard libraries implement totalOrder that is even part of C23 standard | 12:15 | |
| there are several NaNs by the way | |||
| it’s incredible how the human race developed all these marvelous things, and now we are moving to the future where artificial intelligence will take care of all of that | 12:20 | ||
| [Coke] | "take care" | 14:30 | |
| lizmat | would be such a pity if something happened to it | 14:32 | |
| please someone remind me what: | 17:20 | ||
| EXISTS-POS BB(6969, 270 bytes) -> BB(1): | |||
| target has a :noinline instruction - ins: param_rp_o | |||
| what is causing the failure to inline here | 17:21 | ||
| looks like the uint param is the reason | 18:29 | ||