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
|