Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-10

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 bisectable6_ joined #moarvm
00:05 samcv timotimo, that would be nice :)
01:29 colomon joined #moarvm
01:40 colomon joined #moarvm
01:41 colomon joined #moarvm
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:05 pharv_ joined #moarvm
03:44 stmuk joined #moarvm
03:46 Util joined #moarvm
06:15 lizmat joined #moarvm
06:22 lizmat_ joined #moarvm
06:38 lizmat joined #moarvm
08:25 zakharyas joined #moarvm
09:10 jnthn moarning o/
09:12 lizmat joined #moarvm
09:17 dogbert17_ morning, why do I get the impression the everyone is in Amsterdam
09:17 zakharyas joined #moarvm
09:18 jnthn I dunno, maybe most of 'em are
09:19 dogbert17_ so what's on the agenda today, closures and/or tuning?
09:21 jnthn Think I'll make an attempt at the closures thing
09:21 jnthn Though running a little short on time
09:23 dogbert17_ is it a straightforward fix or one requiring a lot of thought and coffee?
09:23 jnthn It's not really a fix
09:23 jnthn It's more trying to remove a limitation of inlining
09:23 jnthn It's tricky
09:24 dogbert17_ and so can take an unspecified amount of time 1 .. *
09:24 jnthn Well, I've got a rough plan that I think might work
09:24 jnthn First step is to try and teach deopt to find the correct code ref via a register
09:25 jnthn So uninlining would be able to reconstruct things correctly
09:25 jnthn Which today doesn't matter
09:26 jnthn The basic idea is that we add a spesh op that can resolve a lexical relative to the outer of a code-ref held in a register
09:27 jnthn otoh since an MVMFrame is a collectable, we could extract the outer frame, but maybe still need the coderef for deopt anyway
09:51 * dogbert17_ was temporarily called away, a disadvantage of $work
09:52 dogbert17_ any wild theories as to performance increases with this new opt?
09:54 brrt joined #moarvm
09:55 Geth ¦ MoarVM: 9f12f0c1a6 | (Jonathan Worthington)++ | 7 files
09:55 Geth ¦ MoarVM: Start storing/using static frame in inline table.
09:55 Geth ¦ MoarVM:
09:55 Geth ¦ MoarVM: In the vast majority of cases, the code ref was only used as a way to
09:55 Geth ¦ MoarVM: get at the static frame, so now just store and access it directly.
09:55 Geth ¦ MoarVM: This prepares the way for starting to store the code ref instead by a
09:55 Geth ¦ MoarVM: reference to the register holding it.
09:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9f12f0c1a6
09:55 brrt good hi *
09:55 jnthn dogbert17_: Well, inlining can be a notable win
09:56 timotimo yo brrt
09:56 jnthn o/ brrt
09:56 timotimo when's the jit talk?
09:56 brrt tomorrow
09:56 jnthn How's Amsterdam?
09:56 timotimo OK!
09:56 brrt i'm not there yet
09:56 brrt :-)
09:56 jnthn Oh!
09:56 brrt long story
09:56 brrt but i'll be there in 2h :-)
09:56 brrt yesterday, it was kind of rainy
09:58 brrt .tell nwc10 you should be able to build nqp by now
09:58 yoleaux brrt: I'll pass your message to nwc10.
10:12 lizmat_ joined #moarvm
10:16 lizmat joined #moarvm
10:20 brrt joined #moarvm
10:21 timotimo so i was wondering how to implement getting the remote peer from IO::Socket::Async's listen functionality
10:22 jnthn timotimo: Just pass it as an extra argument or two to the callback that fires per incoming connection
10:23 timotimo that sounds good, that'll get us the feature without a new op
10:23 jnthn Right :)
10:28 Geth ¦ MoarVM: 30ff9d5147 | (Jonathan Worthington)++ | 5 files
10:28 Geth ¦ MoarVM: Use register holding code ref for deopt purposes.
10:28 Geth ¦ MoarVM:
10:28 Geth ¦ MoarVM: This means that we will deoptimize to the correct closure clone. This
10:28 Geth ¦ MoarVM: also prepares the way for an attempt at inlining of closures.
10:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/30ff9d5147
10:28 jnthn Well, seems my preparatory work went without hitches.
10:29 nwc10 it's a trap! :-)
10:29 yoleaux 09:58Z <brrt> nwc10: you should be able to build nqp by now
10:29 nwc10 (I'd found that already last night)
10:31 lizmat joined #moarvm
10:34 * brrt is now taking the express train to amsterdam
10:46 timotimo can't pay attention to talk and code att he satem tim
10:49 timotimo hmmm ... nqp-debug-m ...
10:49 brrt joined #moarvm
10:55 brrt joined #moarvm
11:09 markmont joined #moarvm
11:27 jnthn Well, got a patch that works for the NQP build/test under spesh stressing. Explodes during CORE.setting compilation alas
11:27 jnthn Lunch, will investigate after
11:38 markmont joined #moarvm
11:48 lizmat joined #moarvm
12:06 * jnthn back
12:07 jnthn Of course, the CORE.setting build is the worst place to hunt a problem down, so I'll see if it'll built without nodelay/blocking and then see if any tests fail with it
12:08 nwc10 or watch Damian live...
12:08 jnthn I get to do that in a couple of weeks :)
12:09 nwc10 he seems to have just blown some folks' minds.
12:12 colomon joined #moarvm
12:15 jnthn :)
12:15 * jnthn found a simpler test to investigate
12:30 jnthn Ah, a rewrite thinko
12:35 jnthn yay, and with that fixed it built Rakudo with spesh stressing, and passes make test too
12:36 jnthn Next for spectest with spesh stressing
12:41 lizmat joined #moarvm
12:47 jnthn Just a few busted
12:48 jnthn otoh yesterday there was one busted and it took all afternoon to work out why...
12:48 colomon joined #moarvm
12:50 dogbert17_ jnthn: these ones? S03-junctions/autothreading.t, S05-modifier/ignoremark.t, S05-modifier/samemark.t, S32-io/IO-Socket-INET.t and integration/eval-and-threads.t
12:50 jnthn No
12:50 dogbert17_ :(
12:50 jnthn But it turnsout
12:51 jnthn They are I think the same tests I regressed when I hadn't JITted new ops a couple of days ago
12:51 jnthn And it turned out it was an issue going way back
12:51 jnthn So I think I've just stumbled on that again
12:51 jnthn Time to write some assembly I guess...
12:52 dogbert17_ making brrt unemployed :)
12:57 jnthn I'm not *that* good at assembly :P
12:58 jnthn Also the hard part of what brrt++ is doing is figuring out how to generate good assembly, whereas I at the moment just need to write a block of it for the lego JIT
12:58 nwc10 at this time any other JITs that might exist are merely the figments of someone else's imagination/on a branch/wrapped in an SEP field
12:59 nwc10 and IIRC he's on a train so won't notice for a while :-)
13:02 jnthn Ooooh.
13:04 jnthn OK, looks like I've some more fix to fix
13:05 jnthn *stuff to fix
13:05 jnthn But with the new ops JITted and a tweak to the inline threshold, we get another bit of movement on the read a million lines benchmark.
13:09 dogbert17_ figuring out what is good assembly must be much harder today than in, let's say, the 6502 days
13:12 jnthn Well, my assembly at least passes spesh stressing on NQP build/test and Rakudo build/test
13:12 dogbert17_ coool
13:12 jnthn Now for another spectest run to find out what I need to fix.
13:12 lizmat joined #moarvm
13:20 geekosaur arguably it was harder back then, because you had to think more.
13:22 geekosaur *especially* on 6502 where, if you wanted really good asm, you had to decide which indexing mode to use (which determined whether/how you used the index registers)
13:22 geekosaur that said, the two worst cases are also in the past. RISC, and VLIW (the late unlamented Itanium)
13:25 dogbert17_ interesting: I was convinced that it had actually become harder, having to think about caches, branch predictors, pipe stalls etc
13:26 geekosaur those are issues, yes, but more meta-issues in some sense.
13:27 geekosaur and even there, RISC was nastier --- delayed branch slots were supposed to make that easier, but instead made it harder in many cases
13:28 geekosaur by "meta-issues" I mean that to do it right, you have to think about more than just the current asm, you have to think about the program context it is invoked from
13:29 brrt joined #moarvm
13:29 dogbert17_ very educational, fortunately for me, the last time I had to do anything with assembler the cpu of choice was the 68000
13:29 geekosaur so they're more matters of *global* code generation/optimization. which is one reason LTO is becoming a thing; it has a more global viewpoint and can do a better job with that kind of optimization
13:30 brrt .tell nwc10 i've already long since arrived at the conference
13:30 yoleaux brrt: I'll pass your message to nwc10.
13:30 nwc10 "I'm here all week"
13:30 yoleaux 13:30Z <brrt> nwc10: i've already long since arrived at the conference
13:31 brrt :-)
13:31 nwc10 (but not necessarily awake)
13:31 brrt also, making myself redundant is very much the endgame
13:31 dogbert17_ LTO, is that what gcc is doing?
13:31 geekosaur gcc and clang both support LTO but not by default
13:31 brrt i think msvc dooes it by default
13:31 brrt it makes build times really really bad
13:31 geekosaur ("link-time optimization")
13:32 brrt it's also pretty cool optimization
13:32 dogbert17_ do we, i.e Perl 6, use it
13:32 geekosaur no, and I don't think it realistically can
13:33 brrt dynamic optimization is in a way similar
13:33 brrt in that it works on the rprogram in its entirety
13:33 brrt but only on the parts that are actually running
13:33 brrt that's usually a pretty good tradeoff of resources
13:34 jnthn We can inline across compilation units already, which I guess is one of the things that LTO does with C code
13:34 jnthn afaik, prior to that, inlining was only within a file?
13:35 geekosaur C99 has extern inline functions
13:36 geekosaur but it has to be explicitly declared as such (and in a header file so it can be #include-d)
13:37 brrt jnthn, i'm curious why your branch breaks when the JIT can't JIT the right things
13:37 brrt that's worrisome
13:37 lizmat joined #moarvm
13:38 jnthn brrt: I don't know.
13:39 jnthn brrt: But I traced it back to some time before my recent work
13:40 jnthn So I think it's one of those spesh bugs that's long existed
13:40 brrt hmmm
13:40 brrt and JITting it fixes it?
13:40 jnthn I've found/fixed many of those
13:40 brrt that
13:40 jnthn Yeah
13:40 jnthn Which is *really* odd
13:40 brrt which is really scary
13:40 jnthn That too
13:41 brrt because to me, it sounds like the JIT might cover up some bits
13:50 jnthn First test I tried to bisect with the spesh limit didn't lead anywhere good. Second one has led to something that looks more sensible
13:50 jnthn In common they seem to have exceptions
14:00 zakharyas joined #moarvm
14:11 timotimo oof, so handlers and maybe how inlining treats handlers
14:12 Geth ¦ MoarVM: 55f850ca41 | (Jonathan Worthington)++ | src/spesh/graph.c
14:12 Geth ¦ MoarVM: Another place needing deleted handler handling.
14:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/55f850ca41
14:12 Geth ¦ MoarVM: af24ab825a | (Jonathan Worthington)++ | src/spesh/inline.c
14:12 Geth ¦ MoarVM: Can never inline frames declaring state vars.
14:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/af24ab825a
14:15 markmont joined #moarvm
14:17 brrt joined #moarvm
14:18 jnthn ah good, I got a golf
14:27 jnthn Ahhh.
14:27 jnthn OK, DEPRECATED assumes $bt.next-interesting-index will always return a value, in one case
14:27 jnthn But because we're inlining more aggressively these days, that doesn't actually happen
14:28 jnthn Backtraces could really do with inline fixups
14:35 lizmat joined #moarvm
14:40 brrt joined #moarvm
15:07 jnthn oh man...1 line fix.
15:07 jnthn From a thinko from 2+ years ago
15:07 jnthn Or so it seems
15:10 brrt joined #moarvm
15:17 japhb Amazing how long those things can lie dormant ...
15:19 jnthn Indeed. otoh, we inline quite a lot more than we used to
15:19 jnthn Or, the other way round, we didn't have so many inlining opportunities before. :)
15:20 japhb Heh.
15:20 japhb Let me know when to do a Rakudo rebuild, and I'll try again with my collection of what seem to be sensitive module installs.
15:29 Geth ¦ MoarVM: c8d902a0ed | (Jonathan Worthington)++ | src/spesh/inline.c
15:29 Geth ¦ MoarVM: Correct handler order when inlining.
15:29 Geth ¦ MoarVM:
15:29 Geth ¦ MoarVM: We duplicate the exception handlers in force when inlining. It's true
15:29 Geth ¦ MoarVM: that order matters, and innermost first is searched for. Unfortunately
15:29 Geth ¦ MoarVM: the effort to do the right thing about that was misguided here, since
15:29 Geth ¦ MoarVM: we're copying from a table that's already sorted, so should just leave
15:29 Geth ¦ MoarVM: it in the order it was already in.
15:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c8d902a0ed
15:35 zakharyas joined #moarvm
15:46 Geth ¦ MoarVM: c663342b48 | (Jonathan Worthington)++ | 9 files
15:46 Geth ¦ MoarVM: Implement inlining of basic lexical lookups.
15:46 Geth ¦ MoarVM:
15:46 Geth ¦ MoarVM: This means that we can now inline closures that look up symbols they
15:46 Geth ¦ MoarVM: close over. It works by introducing a new pair of lookup ops that find
15:46 Geth ¦ MoarVM: the code ref in a register and use it to find the outer. After JIT,
15:46 Geth ¦ MoarVM: this turns out to be as many dereferences as in the non-inlined case.
15:47 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c663342b48
15:48 timotimo whoops
15:48 jnthn Oh, maybe one more instruction actually...forgot the initial register access.
15:48 timotimo but inlining will still give us the power to optimize more stuff
15:48 jnthn timotimo: The "as many dereferences as" is a good result
15:49 jnthn It means that the machinery to make the inlining work doesn't make the lexical lookups more expensive.
15:49 timotimo oh!
15:49 timotimo yay :)
15:50 japhb "only as many"?
15:51 jnthn "only as many" might have been clearer
15:54 Geth ¦ MoarVM: e50eb617db | (Jonathan Worthington)++ | src/spesh/inline.h
15:54 Geth ¦ MoarVM: Tune the inline size a bit.
15:54 Geth ¦ MoarVM:
15:54 Geth ¦ MoarVM: Based on looking at some benchmarks. The original bytecode size often
15:54 Geth ¦ MoarVM: shrinks notably during the specialization process in Perl 6 code, as
15:54 Geth ¦ MoarVM: the argument prelude gets gutted. We do check the size after, but it
15:54 Geth ¦ MoarVM: will then include any nested inlines, which made us more reluctant to
15:54 Geth ¦ MoarVM: do multi-level inlines. This could likely be tuned further; for now
15:54 Geth ¦ MoarVM: this seems a win.
15:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e50eb617db
15:55 jnthn With this lot, I measure us slightly beating Perl 5 at the "read a million lines with UTF-8 and add up the chars" benchmark
15:55 jnthn With the bonus that we're counting graphemes, not codepoints.
15:56 jnthn Something's a tad off with the profiler though
15:56 jnthn The wallclock times and the spesh log both show that the loop body is 100% inlined
15:57 jnthn Like, the + operator and .chars call are inlined into the loop body, and the loop body is inlined into the unit frame.
15:57 jnthn But for some reason that isn't shown
15:58 jnthn It shows the + and chars, but not the pull-one
15:58 jnthn uh...I mean the loop body
15:58 jnthn Oh but...maybe the extra profiling instructions push it over the inline limit? :)
15:58 jnthn That probably will be it :P
15:59 zakharyas joined #moarvm
16:00 jnthn Anyway, hopefully this will have other similarly positive effects :)
16:06 jnthn Sadder news is that the budget for doing this stuff is about spent, so that'll be the last major new opt for now. There's a little left, while I'll use to see if the named arg alias regression that got RT'd is still a thing and hunt it down. And maybe a little further tuning if time allows.
16:07 jnthn Really happy to have got to the point of having this kind of inlining though :)
16:12 jnthn Time to go cook dinner. Yes, it is Indian today :)
16:18 timotimo \o/
16:25 dogbert17 joined #moarvm
16:32 Zoffix \o/
16:33 timotimo since there's not only getpeername but also getsockname i'll be returning two ports and two ips when an async socket is accepted
16:35 Zoffix AlexDaniel: maybe you have a recommendation? I think it was you whose system had a ? that looked a lot different than \ https://twitter.com/kaokun/status/895682264998326273
16:36 AlexDaniel ?\
16:36 AlexDaniel yeah, silly me expected to look at it in my browser to see how it renders there
16:37 Zoffix Renders like this for me on this box: http://i.imgur.com/FbmsXq1.png
16:39 Zoffix I don't think it's that much of a problem in real code, since \ is an unspace or a Capture, which tend to be in different places than ?
16:39 AlexDaniel Zoffix: my recommendation is really stupid. I'm using bitmap fonts for everything, these typically don't have the whole unicode range, so it falls back to any font that the system has with that glyph. This way, ascii range renders sharp and everything else is noticeably blurry
16:39 Zoffix my @stuff = keys @a ? @b; don't make much sense
16:39 Zoffix *if it were \
16:39 AlexDaniel Zoffix: it works for me, but I can't see how anybody could benefit from that idea
16:39 Zoffix heh
16:40 Zoffix I'll leave it unanswered then :)
16:40 AlexDaniel example: https://files.progarm.org/2017-08-10-193951_153x51_scrot.png
16:40 AlexDaniel it has slightly different angle too, so maybe the right solution would be to ping font authors to make it not look like \
16:42 AlexDaniel I think Damian's answer would be to change your vim config to color unicode symbols differently
16:43 AlexDaniel and the right answer is possibly to change your emacs config to change the background color without affecting syntax highlighting (?) :)
16:55 lizmat joined #moarvm
17:00 AlexDaniel Zoffix: I don't know if it helps but I created this: https://github.com/perl6/doc/issues/1444
17:01 Zoffix You're chatting using emacs?
17:02 Zoffix ....all of a sudden the jokes about it being the whole operating system make sense :)
17:03 AlexDaniel yeah, I'm using ERC
17:06 timotimo AlercsDaniel
17:11 Geth ¦ MoarVM/asyncsocket_listen_sockname: 658b53456a | (Timo Paulssen)++ | src/io/asyncsocket.c
17:11 Geth ¦ MoarVM/asyncsocket_listen_sockname: the listen callback shall also push socket and peer ip & port
17:11 Geth ¦ MoarVM/asyncsocket_listen_sockname: review: https://github.com/MoarVM/MoarVM/commit/658b53456a
17:11 timotimo AFK before i see to it that the rakudo portion also works
17:17 AlexDaniel timotimo: while you're at it, you may also like RT #131766 :)
17:17 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131766
17:18 timotimo oh, hmm
17:18 timotimo that's more api design questions i suppose
17:21 timotimo but it's correct to put uv_tcp_bind before connect to get a source ip
17:26 timotimo for some reason i get empty strings here
17:26 timotimo no matter, gotta run
17:31 lizmat joined #moarvm
17:51 lizmat joined #moarvm
17:51 AlexDaniel .tell MasterDuke I've created a ticket. Please leave some comments there: RT #131879
17:51 yoleaux AlexDaniel: I'll pass your message to MasterDuke.
17:51 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131879
17:54 AlexDaniel FWIW I'm marking RT #131879 as a blocker, but I can easily change my mind. It is a very frustrating bug for whose who use rakudo to run long-running processes, but it could also be that I'm the only person affected.
17:54 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131879
17:56 lizmat joined #moarvm
18:00 AlexDaniel for example, it only “leaks” with that specific gist, everything else seems to be normal
18:08 jnthn AlexDaniel: I'm going to look into a leak tomorrow that may well be the same one, fwiw
18:12 AlexDani` joined #moarvm
18:14 AlexDani` jnthn: cool, thanks
18:15 japhb jnthn: Is there an active grant request that I can support?
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: b943f8236d | (Timo Paulssen)++ | src/io/asyncsocket.c
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: you use VMString to decode strings, box it in BOOTStr
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: review: https://github.com/MoarVM/MoarVM/commit/b943f8236d
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: fa64450d91 | (Timo Paulssen)++ | src/io/asyncsocket.c
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: return undefined hosts and ports in error cases
18:32 Geth ¦ MoarVM/asyncsocket_listen_sockname: review: https://github.com/MoarVM/MoarVM/commit/fa64450d91
18:52 geekosaur joined #moarvm
18:54 timotimo i wonder if i should do anything like this for the connect side, too? probably interesting to get the local host and port, but maybe not the target?
19:23 brrt joined #moarvm
19:32 timotimo though having accessors for all four things would make things consistent
19:32 timotimo just set everything
20:14 timotimo i've got a moar bump coming up to make rakudo and moarvm agree on the signature of the callbacks for listen and connect
20:50 AlexDaniel joined #moarvm
21:01 colomon joined #moarvm
21:17 colomon joined #moarvm
21:22 lizmat joined #moarvm
21:50 samcv o/
21:53 timotimo o/
21:54 nwc10 o/
21:54 nwc10 oh, hangon, I should go to bed
21:54 timotimo good night nwc10
21:55 timotimo samcv: i only saw the first and about ½ of the second talk, but the parts i did watch were good
21:56 timotimo wow holy crap that last rt bug just now
22:03 Geth ¦ MoarVM/asyncsocket_listen_sockname: dd95f89b93 | (Timo Paulssen)++ | src/io/asyncsocket.c
22:03 Geth ¦ MoarVM/asyncsocket_listen_sockname: also pass socket and peer names for outgoing connections
22:03 Geth ¦ MoarVM/asyncsocket_listen_sockname: review: https://github.com/MoarVM/MoarVM/commit/dd95f89b93
22:04 timotimo (it didn't take me this long to do that, i just had the code uncommitted and unpushed for a while)
22:09 MasterDuke anyone have thought/comments on https://github.com/MoarVM/MoarVM/pull/626 (other than i need to rebase to fix the oplist conflict)?
22:12 dogbert17 joined #moarvm
22:20 timotimo i say go ahead and merge it
22:23 MasterDuke rebased and force pushed
22:24 MasterDuke i don't have a commit bit, but maybe one of you fine people who do could merge once travis oks it
22:28 zakharyas joined #moarvm
22:32 Geth ¦ MoarVM: 955a9cd1a8 | (Samantha McVey)++ | src/core/interp.c
22:32 Geth ¦ MoarVM: Move indexim_s and eqatim_s to oplist order
22:32 Geth ¦ MoarVM:
22:32 Geth ¦ MoarVM: Move them in interp.c to oplist order.
22:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/955a9cd1a8
22:33 samcv zhuoming should be happy the ops will be back in correct order
22:33 samcv wonder if we want to make a script to put them all in order of their numbers? though the compilier may optimize it since it sees goto statements after each
22:33 jnthn japhb: Sorry, was AFK relaxing some. https://6guts.wordpress.com/2017/05/12/looking-for-perl-6-rakudo-and-moarvm-development-funding/ is the last thing I posted on the topic, and the offer there is still current, at least.
22:33 yoleaux 21:15Z <AlexDaniel> jnthn: FWIW some kind of breakage due to f590863e17 https://gist.github.com/Whateverable/2a9088ddcff37fd6f748b77ba3339af2
22:34 AlexDaniel this is RT #131881 now I believe
22:34 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131881
22:34 jnthn AlexDaniel: Which repo is f590863e17 a commit in?
22:34 AlexDaniel jnthn: rakudo, can't bisect into moarvm yet
22:34 AlexDaniel not with a bot at least
22:34 markmont joined #moarvm
22:35 AlexDaniel Geth: ver https://github.com/rakudo/rakudo/commit/f590863e17
22:35 Geth AlexDaniel, version bump brought in these changes: https://github.com/perl6/nqp/compare/2017.07-19-g82d06cc...2017.07-32-gd40d6dc
22:35 jnthn lol, what, I managed to make a bug such that it makes gnome-terminal-server sigabrt, thus presumably uncovering a bug in that too? :D
22:37 geekosaur yep, unicode decoding fails poorly
22:37 jnthn AlexDaniel: Is there a way with the bot to try it with an env var set before spawning?
22:37 AlexDaniel actually, would be great to submit a bug report there as well
22:37 jnthn I'll try and recreate it tomorrow of course
22:38 jnthn Though the first thing I'll do is check if MVM_SPESH_DISABLE=1 and similar hide it
22:38 AlexDaniel jnthn: not via IRC, no, but I can do it
22:39 jnthn I'm presuming it's one of my clever opts being less than clever...
22:39 AlexDaniel jnthn: actually… I think all you need is just run it with MVM_SPESH_DISABLE=1 on head
22:39 jnthn AlexDaniel: Ah, yeah. :)
22:48 AlexDaniel if somebody has an idea on how should the command look like, please comment on https://github.com/perl6/whateverable/issues/76#issuecomment-321693966
22:48 AlexDaniel “commit: MVM_SPESH_DISABLE=1 HEAD say 42” ?
22:48 AlexDaniel “commit: HEAD MVM_SPESH_DISABLE=1 say 42” ?
22:48 AlexDaniel … both?
22:51 AlexDaniel jnthn: seems to be failing with MVM_SPESH_DISABLE=1 too
22:51 jnthn !!
22:51 jnthn Oh wow
22:52 jnthn I wonder what I coulda touched that isn't spesh related...
22:53 timotimo AlexDaniel: i think both are fine, you can tell from the presence of = in there, right?
22:54 AlexDaniel timotimo: yeah, I think so. Should I support arbitrary env variables?
22:54 AlexDaniel and how likely is it that someone's code is going to start with foo=smth ? :)
22:54 timotimo hmm
22:54 jnthn I figure so, though be careful people can't shell-inejct them
22:54 timotimo very bad idea, if you don't sandbox
22:55 timotimo imagine MVM_SPESH_LOG=/home/alexdaniel/.ssh/id_rsa
22:55 AlexDaniel not yet :'(
22:55 jnthn I mean, if you do allow any env vars, make absolutely sure that you parse them and set up a %*ENV
22:55 jnthn Or similar
22:56 timotimo even without shell injection to the shell vars you can remote trash files on the FS whereever the committable bot has write access
22:56 jnthn timotimo: Uh, but if we can do that by sending the spesh log there then a program can write there too already? :)
22:56 timotimo er, i guess
22:56 AlexDaniel I've been trying to find some time to implement sandboxing for a year… this is horrible
22:57 AlexDaniel jnthn: not really. Well yes, sure, but not as easily, because of RESTRICTED setting
22:57 AlexDaniel but of course working around it is very trivial
22:57 timotimo aye
22:59 AlexDaniel this is the reason why these bots don't respond to private messages. If somebody wants to destroy my server, please do it on public ?_? ?_? ?_? ?_?
23:00 AlexDaniel .oO( this strategy is working surprisingly well )
23:02 timotimo ah yes
23:23 MasterDuke joined #moarvm
23:38 AlexDaniel what's the right falsy value for dev env vars? 0 or emtpy string?
23:39 AlexDaniel both I guess https://github.com/MoarVM/MoarVM/blob/b27f197a6ccb5312a80c5341798b4c503b0e1bc5/src/moar.c#L203
23:42 committable6 joined #moarvm
23:42 AlexDaniel commit: MVM_SPESH_DISABLE=1 HEAD say %*ENV<MVM_SPESH_DISABLE>
23:42 committable6 AlexDaniel, ¦HEAD(ec7bc25): «1»
23:43 AlexDaniel commit: MVM_SPESH_DISABLE=1 f590863e17^,f590863e17 use lib ‘data/all-modules/moritz/json/lib/’; use JSON::Tiny; use Test; my @t = '{ "a" : "b\u00E5" }' => { 'a' => 'bå' }, '[ "\u2685" ]' => [ '?' ], qq{"x\c[ZERO WIDTH JOINER]a"} => "x\c[ZERO WIDTH JOINER]a", qq{"\c[ZERO WIDTH JOINER]"} => "\c[ZERO WIDTH JOINER]"; plan (+@t); for @t -> $p { my $got = from-json($p.key); is-deeply $got, $p.value; }
23:43 committable6 AlexDaniel, https://gist.github.com/2f9573fe562b78bcd1d3c9546739f2bb
23:43 AlexDaniel :)
23:46 jnthn Hmmm
23:46 jnthn AlexDaniel++
23:54 timotimo m: -> Mu \a? { say a }()
23:54 camelia rakudo-moar ec7bc2: OUTPUT: «===SORRY!=== Error while compiling <tmp>?Malformed parameter?at <tmp>:1?------> -> Mu \a?? { say a }()?    expecting any of:?        constraint?»
23:54 timotimo m: -> Mu $a? is raw { say a }()
23:54 camelia rakudo-moar ec7bc2: OUTPUT: «===SORRY!=== Error while compiling <tmp>?Undeclared routine:?    a used at line 1??»
23:54 timotimo m: -> Mu $a? is raw { say $a }()
23:54 camelia rakudo-moar ec7bc2: OUTPUT: «(Mu)?»
23:55 timotimo maybe i'll implement passing hosts and ports with this so i don't have to immediately bump moar when moar learns to submit those
23:55 Zoffix AlexDaniel++
23:55 timotimo it could then also skip sending Str, Int, Str, Int in case of errors

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary