|
01:34
ab5tract left
06:54
ab5tract joined
|
|||
| timo | gist.github.com/timo/4f9d318dae901...eb0fb897f2 ????? %) | 09:00 | |
|
09:03
ab5tract left
|
|||
| lizmat | that feels rather repetitive ? | 09:19 | |
| timo | kinda | 09:24 | |
| ok so, what has both "$!bstack" and "HOW", as well as 1 and 1? where the order of "$!bstack" and "HOW" may be in reverse | 09:25 | ||
| lizmat | isn't the repeating of Callsite_74 also a bit weird? | 09:28 | |
| timo | and something else or similar might have "$!uid", "gid=", "96", "$!gid", also with an 1 to go with each? | 09:31 | |
| don't think that's weird, why? that's obj, str, obj, str | 09:32 | ||
| i'm not sure i'm looking at it correctly. this could be a Metamodel::GenericHOW? maybe a Perl6::Metamodel::AttributeContainer? it could conceivably also be refering to a Metamodel::ModuleHOW? | 09:36 | ||
| those are objects in core.c.setting that change from one run of compiling rakudo to another | 09:37 | ||
| lizmat | why would they change? | 09:40 | |
| timo | could be related to hash randomization | 09:42 | |
| lizmat | well, it feels it shouldn't? given a set of source files, shouldn't the bytecode always be *exactly* the same, especially for Debian? | 09:44 | |
| timo | they would certainly like that | ||
| well, the reprotest twiddles a bunch of things around to ensure builds are reproducible not just from doing it twice in a row. for example, they also change the locale to french | 09:45 | ||
| and there's a thing that reprotest activates that gives you files in directories in random order | |||
| and the path where the build is done is also randomized | |||
| and it's built from a clean beginning, too, with moar and nqp installed from the same packages though | 09:46 | ||
| and yet, the results are different | |||
| i mean, the bytecode is the same, but serialized objects are different | |||
| lizmat | so: in memory the same, but different on disk ? | 09:47 | |
| timo | not sure about "in memory" | ||
| lizmat | then what do you mean with "bytecode" as opposed to serialized objects? | 09:48 | |
| timo | our serialization code has something in it to prevent hash randomization from shuffling things around AIUI | ||
| bytecode would be the frames that you see in moar --dump or in the spesh log | |||
| whereas serialized objects are all the type objects and constants and whatnot that we have | |||
| lizmat | which usually live in a file, no? | 09:50 | |
| timo | i'm not sure i'm following | 09:53 | |
| lizmat | a .moarvm file consists of serialized objects that become objects in memory when they're read from the file | 09:54 | |
| timo | right | 09:55 | |
| ok i don't know what SC 5 IDX 21 is exactly, but there is a whole boatload of 'em in the serialized blob, and just two have their order shuffled from one to the next | 10:00 | ||
| i am relatively certain that sc 5 is metamodel.moarvm | 10:02 | ||
| or could i be off-by-one here? | |||
| ok i really need to go to sleep, this has rabbitholed me something fierce | 10:03 | ||
| lizmat | sleep! | ||
| thanks for all the rabbitholing you've done so far! | 10:04 | ||
| Geth | ¦ problem-solving: tbrowder assigned to rba Issue Raku's Github list of popular repositories is outdated and needs a new listk github.com/Raku/problem-solving/issues/448 | 10:10 | |
| ¦ problem-solving: lizmat unassigned from rba Issue Raku's Github list of popular repositories is outdated and needs a new list github.com/Raku/problem-solving/issues/448 | 10:29 | ||
| roast: 950d347c8c | (Elizabeth Mattijsen)++ | S04-declarations/smiley.t Add tests for #4255 |
10:41 | ||