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
rakudo/lizmat-anonymous-params: 2b7a767e18 | (Elizabeth Mattijsen)++ | src/core.c/Exception.rakumod
Make positional parameters anonymous in candidate list

when throwing an dispatch exception. Because the actual names ofi positional parameters is not important and can be distracting.
Inspired by github.com/rakudo/rakudo/issues/4273
11:49
rakudo: lizmat++ created pull request #5663:
Make positional parameters anonymous in candidate list
rakudo/lizmat-objhash-no-failure: 1ff8e531b1 | (Elizabeth Mattijsen)++ | src/core.c/Hash/Object.rakumod
Throw coercion failures on object hashes

If an object hash is defined with a coercion type (e.g. Int(Str)) the Failure of the coercion would be stored as the key. Only to thrown whenever that key would be accessed in the hash, e.g. with
  .keys.
... (7 more lines)
12:39
rakudo: lizmat++ created pull request #5664:
Throw coercion failures on object hashes
rakudo/main: 817c9ae17d | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix "handles" and "will" traits

With regards to .raku and deparsing
13:39
rakudo/main: 49005b54d6 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #4351
14:34
14:43 ab5tract joined
ab5tract Clearly there are some opts that want very badly to init :) 14:44
15:09 El_Che left
Geth roast: a9808b7896 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | spectest.data
Disable test file that hogs up all memory

At least for now
17:18
roast: 792ffe2547 | (Elizabeth Mattijsen)++ | S04-declarations/will.t
Add test for #4403
17:20
roast: 9178a972fc | (Elizabeth Mattijsen)++ | S04-statements/label.t
Add test for #4456
17:38
roast: 6e2925bb4b | (Elizabeth Mattijsen)++ | S32-list/reduce.t
Add test for #4458
17:42
roast: 3eba8ecf34 | (Elizabeth Mattijsen)++ | S15-string-types/Uni.t
Add tests for #4464
17:45
18:09 ab5tract left
Geth rakudo/main: 98fdf95a28 | (Elizabeth Mattijsen)++ | src/core.c/allomorphs.rakumod
Add support for Unicode vulgars to val()

This effectively makes <⅓> the same as <1/3>.
Fixes #4475
18:41
timo huh. i "make install", copy away the stuff, "make clean; make install", compare the two folders, and the position of an infix:<**> frame as well as an unnamed frame moves up by one in the core.c.setting file 19:09
Geth roast: 6896f2f2f3 | (Elizabeth Mattijsen)++ | S32-str/val.t
Whip val() tests into shape

A lot of tests are questionable, moved the failing ones to a "todo" hash, or commented whole ranges out.
19:22
bartolin lizmat: may I ask a question? I noticed that something like "flat (42, [], 7)" doesn't remove the empty array on the JVM backend. (Which leads to problems when testing with "is-run".) Does the usage of -1 here rely on the usage of "uint" and the conversion to a very large number in class Flat? github.com/rakudo/rakudo/blob/98fd...umod#L1877
(which doesn't seem to work on the JVM backend) 19:23
but it also feels like it doesn't work for plain classes created outside of the core. (but maybe I'm doing something wrong here) 19:24
m: use nqp; class Foo { has uint $!levels; method new(uint $levels) { my $self := nqp::create(self); nqp::bindattr_i($self,Foo,"\$!levels",$levels); $self }; method levels() { nqp::getattr_i(self,Foo,"\$!levels") } }; say Foo.new(-1).levels
camelia -1
lizmat possibly... could try changing it to uint.Range.max
bartolin (I tried to simulate the code from class Flat)
lizmat m: uint.Range.max 19:25
camelia ( no output )
lizmat m: say uint.Range.max
camelia 18446744073709551615
bartolin thanks, I'll play with that a bit. (but I'm still a bit confused, why my example above still gives back -1) 19:26
lizmat afk& 19:36
bartolin o/ 19:37
timo ha! 20:12
we have a version of RegexCaptures in rakudo's bootstrap.c where we don't use sorted_keys on the capnames hash 20:22
bartolin uint.Range.max also doesn't work. but int.Range.max seems to avoid all underflow/overflow problems and still looks like a safe value for the levels of flattening
timo now for some reason i can't call sorted_keys there, not even after putting a copy of it above the regexcaptures class 20:23
always fun to be poking around in the bootstrap bits :| 20:27
bartolin *g*
timo hahaha 20:30
i'm now encountering the exact same error that you found here: github.com/Raku/nqp/issues/808
bartolin oopsie 20:31
timo except on moarvm
bootstraps is one hell of a drug
Geth rakudo: usev6++ created pull request #5666:
[JVM] Flatten without overflow/underflow issues
20:40
timo OK, now I have a hacky version that sorts the cap names. somehow there still remains the issue where it's compiling these two frames in different orders
and/or a frame there has its lexicals in different order, maybe? or that's a symptom of the/a frame moving around? 20:42
bartolin has no clue 20:43
timo ah the order is the same, there's just some stuff in between that causes them to move, and since every line has a line number in this part of the output, diff aligns them by the line number 20:44
so it's not obvious to the eye
i kind of hate that in order to make this specialized output that also shows some information from serialized data, i had to copy so so much code from other moarvm source files 20:45
storage.aperture-labs.org/s/mWjzQgJ5Wriw6tb have a look (but you'll need to download and open it with a browser off your disk for it to work unfortunately, ugh) 20:48
there's the traditional "moar --dump" output at he top, the "new" dump format in the middle, and a raw diff of xxd's output at he bottom 20:49
patrickb Is it expected, that Rakudos utf8 decoder will hold back one char (i.e. output is always offset by one char wrt the input)? 21:28
[Coke] has to check if there's a combiner, so that tracks. 21:35
patrickb And combiners can be trailing? 21:36
Ugh...
That majorly sucks for things like terminal emulators. Should I just assume that I always have complete input and don't do streaming decoding? 21:37
Thanks for explaining! 21:41
[Coke] Yah, I can see where that sucks for streaming - how do you know that you should render the n and you're not waiting for an ñ
(well, an n and a ˜ combiner, an ñ would be easier. :) 21:42
unicode is the worst. (except for everything else we've tried)
timo patrickb: there are characters that can't combine, like newline and actually probably all the low unprintable ascii chars 21:45
patrickb Yeah. But I need insta response for all chars that show up on the screen. 21:46
timo with a terminal emulator, you can probably expect after a short timeout if there's nothing more, there won't be any combiners, since if the user types something like ä
they would be using a dead key or a compose sequence
and if they are typing something more complicated, the IME would have done everything before you get anything, right? i've never worked with IME tbh 21:47
patrickb Given that programs typically don't stop sending output in the midst of a sequence, I'll try to get away with just assuming that I always receive chunks of complete input for now.
[Coke] good first approx.
timo hopefully the user can just backspace whenever something goes wrong 21:48
patrickb paste.pics/fe66950d7c6550e0b6bb7eff7e90384f 21:52
paste.pics/c2062c36e3f861fb3ec08a7db7ed63ad
vim would be almost usable if I'd manage to send ESC :-P 21:53
timo do you know asciinema?
patrickb I think I'm soon at the point where it's good enough for now
did and forgot
timo can't blame you :D 21:54
23:11 |Tux| left 23:26 ab5tract joined 23:50 |Tux| joined