github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:45 ZzZombo_ joined 00:48 ZzZombo left, ZzZombo_ is now known as ZzZombo 00:53 ggoebel joined 02:10 ggoebel left
AlexDaniel btw, I added a label here thinking that moarvm doesn't build on someone's setup 02:16
github.com/MoarVM/MoarVM/issues/1149
but I'm not entirely convinced it's an issue on our side?
any thoughts?
vrurg: ↑ :)
vrurg AlexDaniel: I'm not familiar with moar's build. But similar issue was handled long ago in rakdo. 02:18
Can't quickly find what it was and how we dealt with it eventually... 02:22
Hm, it was moar, after all. Interesting... 02:27
02:43 ZzZombo_ joined 02:46 ZzZombo left, ZzZombo_ is now known as ZzZombo 03:35 AlexDani` joined 03:42 ZzZombo_ joined 03:44 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined, ZzZombo left 03:45 ZzZombo_ is now known as ZzZombo 03:52 ZzZombo_ joined 03:54 ggoebel joined 03:55 ZzZombo left, ZzZombo_ is now known as ZzZombo 04:04 moon_child joined 05:23 AlexDaniel left 06:36 sena_kun joined 07:14 domidumont joined 07:26 ggoebel left 08:39 sena_kun left 08:40 vesper joined 08:45 sena_kun joined 08:54 patrickb joined 08:58 patrickb left 09:53 Guest13443 joined 10:45 brrt joined
brrt \o 10:48
tellable6 2019-10-21T02:13:19Z #raku-dev <AlexDaniel> brrt: can you update me on what you're working on? It's something that needs to be fixed before the release, right? We're currently at 0 blockers otherwise
nwc10 o/
brrt .tell AlexDaniel a set of templates introduced a bug, which I fixed, then it turned out there's another bug, that I'm wrorking on now 10:49
tellable6 brrt, I'll pass your message to AlexDaniel
brrt ohai nwc10 10:50
if only we had a bug tracker....
Guest13443 o/ brrt
brrt ohai Guest13443 10:51
Guest13443 how is the bughunting/fixing going? 10:55
brrt never easy 10:56
Guest13443 do you have a theory as to what the bug might be? 11:06
brrt yeah 11:11
11:22 brrt left
Guest13443 oh no, he left 11:24
12:08 Voldenet joined, Voldenet left, Voldenet joined 12:12 ggoebel joined 12:24 AlexDaniel joined 12:25 AlexDaniel left, AlexDaniel joined
AlexDaniel . 12:25
tellable6 2019-10-21T10:49:54Z #moarvm <brrt> AlexDaniel a set of templates introduced a bug, which I fixed, then it turned out there's another bug, that I'm wrorking on now
AlexDaniel brrt: re “if only we had a bug tracker....”, I'm not sure what you mean by that. I can't see it in the bug tracker (both MoarVM and Rakudo), and it's definitely not labeled as something important 12:30
tellable6 AlexDaniel, I'll pass your message to brrt
nine AlexDaniel: I'm quite sure that's exactly what brrt meant. We do have a bug tracker, but we don't use it all the time 12:57
tellable6 2019-10-20T21:18:11Z #moarvm <AlexDaniel> nine, test test
12:58 ggoebel left
AlexDaniel nine: ok, well, here's one: github.com/rakudo/rakudo/issues/3256 13:00
:)
13:11 ggoebel joined 13:24 Voldenet left 13:29 Voldenet joined, Voldenet left, Voldenet joined 13:45 Voldenet left 13:50 Voldenet joined, Voldenet left, Voldenet joined
lizmat and the first Rakudo Weekly hits the Net: rakudoweekly.blog/2019/10/21/2019-42-answered/ 13:59
14:40 lucasb joined 15:03 patrickb joined 15:42 Guest13443 left 16:20 domidumont left 16:34 patrickb left 16:42 Kaiepi left 17:01 domidumont joined 17:04 domidumont left, domidumont joined 17:45 domidumont left 18:02 sena_kun left 18:43 brrt joined
brrt \o 18:56
tellable6 2019-10-21T12:30:58Z #moarvm <AlexDaniel> brrt: re “if only we had a bug tracker....”, I'm not sure what you mean by that. I can't see it in the bug tracker (both MoarVM and Rakudo), and it's definitely not labeled as something important
AlexDaniel brrt: I filed a placeholder here: github.com/rakudo/rakudo/issues/3256 18:57
brrt .tell AlexDaniel - I'm aware we have github issues for rakudo and MoarVM; there wasn't really a point to be made, and if there were, it'd be limited to 'it's not there yet'
tellable6 brrt, I'll pass your message to AlexDaniel
AlexDaniel .
nwc10 o/
brrt ohai AlexDaniel, you're here :-D
also, I appreciate that a release schedule means rather more to you, than to me; my main concern is getting bugs fixed 18:58
the theory I'm using right now is this 18:59
- we need to keep track of which values represent collectables (str or obj), so that we can properly mark the location where we spill them, if we need to
- for that reason, the expression template *builder* assigns the MVM_reg_type that belongs to each value that is in a register, and the post-build analysis tries to propagate that type as far as is reasonably possible 19:01
which isn't very far
and I don't have good proof that it is sufficient, or even correct
anyway, the trouble is, the template builder effectively assigns a type in top-down fashion; the tree analysis code assigns a type in bottom-up order, and if we have a top-down assigned type then the bottom-up computed type may overwrite it 19:02
which is fairly bad
does that make any sense? 19:04
It's interesting enough for a blog post I think
19:26 MasterDuke joined 19:39 tellable6 left 19:41 tellable6 joined 19:44 releasable6 joined
brrt so... one thing that I could be doing, which would be interesting, is replace the 'size' operand for load/store, with a type operand 20:27
samcv hey brrt 20:28
tellable6 2019-10-21T08:56:01Z #perl6-dev <patrickb> samcv What is a specfile? It it something rakudo should provide?
2019-10-21T08:56:40Z #perl6-dev <patrickb> samcv I also hope we'll be able to provide pre-built packages with the next compiler release. It has not been finally decided yet whether we'll provide pre-built packages with every monthly compiler release though.
2019-10-21T08:56:48Z #perl6-dev <patrickb> samcv I have tested relocatable builds to some extent, but there is no real life usage yet. I what to make this work robustly, so please do share any problems you hit.
2019-10-21T08:57:30Z #perl6-dev <patrickb> samcv Could you also join #raku and #raku-dev ?
gist.github.com/6c40ccfa6fc7e28821...c78235aada
gist.github.com/35b87ba1b0237af47b...167933cf8b
MasterDuke brrt: re your top-down vs bottom-up comments. maybe this is a silly/obvious question, but is there a way for the bottom-up process to know that the top-down one has already assigned a type? and if so report a conflict if it want to assign something different? 20:32
brrt hey samcv 20:33
MasterDuke: yes, there is 20:35
not particularly hard, as a matter of fact
MasterDuke and this happens during the moarvm build process? or at rakudo runtime? 20:36
brrt the question is more, can I determine the right set of operations that propagate a type either down or up, and can I prove that this is sufficient, or is there a cleverer way that sidesteps all of this
during the runtime of the JIT
maybe that's not necessary
I haven't had the tuits to spend on this yet 20:37
:-)
MasterDuke is a reasonable interim bandaid to just bail if such a things happens? i.e., can the jitting be safely canceled when that happens?
brrt well, not really, short of disabling the expression JIT entirely 20:38
because the trick is, 'when that happens' needs to be very specific in 'that'
I think I can bandaid over this specific case
hmm, let me try 20:39
yep, bandaid works 20:40
nine That sounds like good news :) 20:42
MasterDuke brrt++ 20:43
brrt well, it buys me time to rethink how this ought to be done, for sure 20:44
MasterDuke nine: btw, think github.com/MoarVM/MoarVM/pull/1196 is good now? (i'm probably afk for a bit)
nine Buying time to think things through is a very good strategy 20:45
brrt hang on, I need to try again
I didn't compile with the right debug settings
nope, bandaid doesn't work 20:46
:-(
damn 20:47
20:53 ggoebel left
brrt oh, duh 21:54
bandaids should be applied with the cotton side on the wound, not the other way around
less metaphorically, there's a distinction between '!=' and '==', and sometimes it's important 21:55
ok, bandaid does work
yay.
Geth MoarVM: 97e26c0186 | (Bart Wiegmans)++ | 4 files
[JIT] Fix bug in takedispatcher

Rather than assigning to the result of getf, use setf to assign the field, as this is what interp.c also does.		 22:01
MoarVM: d5f5185b2e | (Bart Wiegmans)++ | src/jit/expr.c
[JIT] We should not overwrite assigned type

The expression builder assigns value types in a top-down fasion, and the tree analysis will then compute the types in bottom up. Which means that it might overwrite the assigned types, which means that collectable values might be spilled to a register that isn't marked as object or string. ... (6 more lines)
brrt .tell AlexDaniel bandaid applied, bug should be fixed
tellable6 brrt, I'll pass your message to AlexDaniel
AlexDaniel .
thanks!
bumping
brrt (I didn't run spectest to test the full effect, but I think I understand this bug well enough...) 22:02
AlexDaniel brrt: what about tests for this issue? Is there a golf or something?
brrt there is a golf, yes 22:04
AlexDaniel: with MVM_GC_DEBUG=1 and MVM_NURSERY_SIZE=8192 compiled, 22:06
./perl6-m -e 'say (^1000 .grep: -> $n {([+] ^$n .grep: -> $m {$m and $n %% $m}) == $n })'
oh, and MVM_SPESH_BLOCKING=1 as env var
I thank... who do I need to thank for this repro? 22:07
MasterDuke dogbert i think did the initial golf 22:08
brrt Guest13443++ for the golf
AlexDaniel what was the original?
brrt that's the golf
AlexDaniel is it something from the spectest or someone's program?
MasterDuke from a spectest i believe
brrt colabti.org/irclogger/irclogger_lo...-10-18#l97
22:09 squashable6 joined
AlexDaniel ok, closed the ticket! 22:10
I'm in the middle of something right now so I'll check tomorrow if there's anything left for the release
brrt thanks! 22:11
AlexDaniel but it looks like there are 0 blockers :)
MasterDuke fwiw, nqp and rakudo both test and spectest clean at HEAD across the board
AlexDaniel: btw, do we have any existing tickets (or a defined place they should go) about getting run-code-in-a-brower sites updated (e.g., glot.io, tio.run)? both are currently using non-current versions 22:13
AlexDaniel I haven't checked 6.c and 6.d erratas though…
MasterDuke are there make targets for those?
AlexDaniel `git checkout 6.d-errata` in roast 22:15
then make spectest
brrt MasterDuke: that's a fast test
AlexDaniel I believe it was on the newest shiniest hardware? :) 22:16
MasterDuke brrt: the new ryzen 3700x i got a couple months ago is pretty nice. runs a spectest in 140s
AlexDaniel MasterDuke: there's user-experience micro repo github.com/perl6/user-experience/issues 22:19
MasterDuke t/spec/S04-declarations/constant.rakudo.moar (Wstat: 256 Tests: 70 Failed: 1) Failed test: 8 Non-zero exit status: 1
AlexDaniel MasterDuke: in the future I'd like to move its contents to problem-solving 22:20
MasterDuke t/spec/S32-exceptions/misc.rakudo.moar (Wstat: 256 Tests: 383 Failed: 1) Failed test: 68 Non-zero exit status: 1
those are on 6.c-errata
AlexDaniel MasterDuke: but user-experience is probably the right place to start the discussion anyway
MasterDuke: related issue, maybe: github.com/perl6/user-experience/issues/29
brrt I have a ryzen 2500u 22:21
MasterDuke: JIT-sensitive?
AlexDaniel MasterDuke: it has a nice list which can help you figure out where these sites take their rakudo from: repology.org/project/rakudo/versions
brrt: no-no, that's for me :)
brrt: probably just some errata tests that need updating
appveyor is not very happy though 22:23
MasterDuke brrt: those two don't seem to be jit/spesh sensitive
AlexDaniel brrt: there's a problem though 22:24
src/jit/compile.c:39:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
brrt ugh
ok, say no more
MasterDuke one seems to be `throws-like 'use v6.c; constant %hash = "nothash"', X::TypeCheck, 'constant hash requires Associative';` 22:27
m: use v6.c; use MONKEY; EVAL q|constant %hash = "nothash"|; CATCH { default { dd $_ } }
camelia X::Hash::Store::OddNumber.new(found => 1, last => "nothash")
Geth MoarVM: 5685d40b10 | (Bart Wiegmans)++ | src/jit/compile.c
[JIT] C99 fix
 22:28
MasterDuke bisect: use v6.c; use MONKEY; EVAL q|constant %hash = "nothash"|; CATCH { default { dd $_ } }
bisectable6 MasterDuke, Bisecting by output (old=2015.12 new=2058cfb) because on both starting points the exit code is 0
brrt AlexDaniel: thanks, fixed
22:28 brrt left
bisectable6 MasterDuke, bisect log: gist.github.com/0b387dcaa3ccef621d...08ef6aaa2f 22:28
MasterDuke, (2016-02-13) github.com/rakudo/rakudo/commit/60...4e047e20ca
AlexDaniel nah, that's not it 22:29
c: 2019.07.1,HEAD use v6.c; use MONKEY; EVAL q|constant %hash = "nothash"|; CATCH { default { dd $_ } }
committable6 AlexDaniel, ¦2019.07.1,HEAD(2058cfb): «X::Hash::Store::OddNumber.new(found => 1, last => "nothash")␤»
AlexDaniel c: 2019.07.1,HEAD use MONKEY; EVAL q|constant %hash = "nothash"|; CATCH { default { dd $_ } } 22:30
committable6 AlexDaniel, ¦2019.07.1,HEAD(2058cfb): «X::Hash::Store::OddNumber.new(found => 1, last => "nothash")␤»
AlexDaniel MasterDuke: should be something that's differen on 2019.07.1 and HEAD
t
MasterDuke c: 2019.07.1,HEAD use MONKEY; EVAL q|use v6.c; constant %hash = "nothash"|; CATCH { default { dd $_ } } 22:31
AlexDaniel also you can look at commits to that file
committable6 MasterDuke, gist.github.com/1c248b71447d5d4425...5fcbf6b701
AlexDaniel yep, that
bisect: 2019.07.1,HEAD use MONKEY; EVAL q|constant %hash = "nothash"|; CATCH { default { dd $_ } }
bisectable6 AlexDaniel, Using old=2019.07.1 new=HEAD in an attempt to do what you mean
AlexDaniel, On both starting points (old=2019.07.1 new=2058cfb) the exit code is 0 and the output is identical as well
AlexDaniel, Output on both points: «X::Hash::Store::OddNumber.new(found => 1, last => "nothash")␤»
AlexDaniel w… what?
ah
MasterDuke bisect: 2019.07.1,HEAD use MONKEY; EVAL q|use v6.c; constant %hash = "nothash"|; CATCH { default { dd $_ } }
bisectable6 MasterDuke, Using old=2019.07.1 new=HEAD in an attempt to do what you mean
MasterDuke, Bisecting by output (old=2019.07.1 new=2058cfb) because on both starting points the exit code is 0
AlexDaniel yep :)
bisectable6 MasterDuke, bisect log: gist.github.com/dc6165065ffaa74414...4f547b5042 22:32
MasterDuke, (2019-07-11) github.com/rakudo/rakudo/commit/07...f610ca7dee
MasterDuke bisect: 2019.07.1,HEAD use MONKEY; EVAL q|use v6.c; sub postbla:sym<foo>() { }|; CATCH { default { dd $_ } } 22:33
bisectable6 MasterDuke, Using old=2019.07.1 new=HEAD in an attempt to do what you mean
MasterDuke, Bisecting by output (old=2019.07.1 new=2058cfb) because on both starting points the exit code is 0
MasterDuke, bisect log: gist.github.com/bc96b66a85d1f86386...e93c3d3c7f 22:34
MasterDuke, (2019-07-11) github.com/rakudo/rakudo/commit/07...f610ca7dee
AlexDaniel MasterDuke: by any chance are looking for this? github.com/perl6/roast/commit/eb01...dbe078211b 22:35
MasterDuke the two fails weren't in that file 22:36
AlexDaniel hmm
MasterDuke oh wait, maybe one was
AlexDaniel if you figure it out please let me know, I'll need to fix that before the release anyway 22:37
MasterDuke i'm about to go to bed, so can't do any debugging
AlexDaniel it's OK, I'll look into it
MasterDuke but here are the v6.d-errata fails
t/spec/S10-packages/precompilation.rakudo.moar, t/spec/MISC/misc-6.d.rakudo.moar, t/spec/MISC/bug-coverage-6.d.t, t/spec/S02-literals/allomorphic.t, t/spec/S02-lists/indexing.t, t/spec/S02-literals/heredocs.rakudo.moar, t/spec/S06-currying/misc.rakudo.moar, t/spec/S06-currying/named.t, t/spec/S06-currying/positional.t, 22:39
t/spec/S10-packages/use-with-class.t
those are all `Non-zero exit status: 1 Parse errors: No plan found in TAP output`
AlexDaniel samcv: btw, there are no moarvm blockers that I see. No green light from me yet while I'm double checking things, but you can start preparing the moar release
MasterDuke: w… what??
that doesn't sound very promising :D 22:40
MasterDuke t/spec/S32-io/IO-Socket-Async-UDP.t had `Failed test: 1` and t/spec/S32-io/IO-Socket-Async.t had `Failed test: 23`
AlexDaniel OK I'll check :) 22:41
MasterDuke hm, a couple of those initial ones are working when run by themselves
anyway, i'm off now, later all... 22:43

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!