Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-08-24

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:09 brrt joined #moarvm
05:11 brrt TheLemonMan: that is, if it is true, really clever
05:14 brrt damn, unsensitive to JIT
05:14 brrt a memory corruption is often enough a JIT issue
05:14 brrt especially when exceptions are involved
05:14 brrt hmmm
05:14 brrt oh well
05:19 brrt off to register allocation troubles
06:02 brrt joined #moarvm
06:12 brrt oh, i'm being silly
06:13 brrt i can just encode the register spec as 4 bytes, no reason to be difficult about it
06:13 brrt and of course, that scales linearly with the amount of registers we use...
06:13 brrt heh
06:27 brrt joined #moarvm
06:35 brrt oh, another bit of news: http://v8project.blogspot.nl/2016/08/firing-up-ignition-interpreter.html
06:42 brrt heh, C fields specifiers save the day, no macros required
06:47 dalek joined #moarvm
06:52 brrt hmm, hang one, my struct is still 32 bits wide then
06:52 brrt that is not very nice
07:10 domidumont joined #moarvm
07:10 lizmat joined #moarvm
07:12 lizmat joined #moarvm
07:14 domidumont joined #moarvm
07:23 zakharyas joined #moarvm
08:16 lizmat joined #moarvm
08:40 lizmat joined #moarvm
08:47 lizmat_ joined #moarvm
08:54 lizmat joined #moarvm
09:04 zakharyas1 joined #moarvm
09:11 domidumont joined #moarvm
09:51 jnthn Hm, in https://ptpb.pw/UOuH I agree with the analysis, but can't figure out how that check on uv_run is doing anything useful from the libuv docs...
09:52 jnthn https://github.com/joyent/libuv/commit/aab8d9dab45d03d9df01a7deab7ae1f2ebe9ada3#diff-56343bd7ad8bf449c2693082fb3e4081R295 says:
09:52 jnthn *  - UV_RUN_DEFAULT: Runs the event loop until the reference count drops to
09:52 jnthn *    zero. Always returns zero.
09:54 jnthn oh, no, old docs
09:54 jnthn http://docs.libuv.org/en/v1.x/loop.html
10:16 TheLemonMan joined #moarvm
10:17 JimmyZ hard bug , I thought it was a bug between gc and fix size alloc
10:18 TheLemonMan jnthn, that was just a quick example to possibly prove my hypotesis, don't know enough libuv to suggest what the right way to clean up is
10:18 jnthn TheLemonMan: Yeah, looking into it some now :)
10:19 jnthn Also doing some auditing to find out how common the problem is, since I fear we might have other cases of this too
10:19 TheLemonMan using libuv for synchronous IO is a weird choice
10:20 jnthn Yeah, also not a long-term one
10:21 jnthn Since it causes various other issues
10:21 jnthn (Like, not being able to use a socket across threads)
10:22 jnthn Maybe it's time to bite the bullet and stop doing that.
10:23 jnthn Though there's a few other things that should probably also happen at the same time.
10:23 TheLemonMan it might even be easier than trying to figure out what the error is heh
10:24 jnthn For one, I think that MoarVM's I/O layer should probably get out of the business of encoding/decoding
10:24 jnthn And we expose the DecodeStream API, and use it.
10:25 JimmyZ how did you find it's about longjmp bug? I can't see anything from the gdb
10:25 jnthn Since we also have problems with async sockets and so forth where string decoding throws and doesn't pass on the exception right
10:26 JimmyZ re switch to our new *libuv*, I may help to commit some code if someone starts, :)
10:26 TheLemonMan JimmyZ, guesswork :D
10:27 jnthn The other thing is that it'd be nice to fix up having real async file and console I/O too
10:27 jnthn Which people miss
10:27 jnthn And while we're on the decodestream stuff, making an API so other encodings can be implemented and plugged in in Perl 6 space would also be desirable.
10:28 jnthn (And then the VM-provided ones will just be "accelerated" versions.)
10:28 jnthn Which all told is a good bunch of work, but perhaps a better use of time than lots of patching :)
10:31 jnthn So, I think we'll solve the bug in question as part of that work :)
10:31 jnthn Probably the logical work order is
10:31 edehont joined #moarvm
10:31 zakharyas joined #moarvm
10:31 jnthn 1. Expose the decode stream from MoarVM
10:32 jnthn 2. Use it in the async sockets and async processes implementations
10:33 jnthn 3. Refactor to allow userspace encodings
10:33 jnthn 4. Use this for sync I/O too
10:34 jnthn 5. Fix up NQP similarly :)
10:34 jnthn 6. Deprecate/remove string-based I/O from MoarVM, so it only deals in bytes
10:35 konobi libuv's pretty solid there
10:35 jnthn 7. Refactor sync I/O to not use libuv - which will be a smaller task thanks to earlier changes
10:35 jnthn konobi: Pretty solid where?
10:35 konobi dealing only in bytes
10:35 jnthn Ah ;)
10:35 jnthn We don't use it to deal with non-bytes tbh :)
10:36 jnthn The thing is that we have MoarVM providing high-level I/O operations that deal in strings.
10:36 jnthn Which means it then gets very hard to extend encodings supported to userspace
10:37 konobi $str.to_bytes() ?
10:37 jnthn .encode, but pretty much, yes
10:37 jnthn Decoding is the fun part
10:37 jnthn Because of multi-byte sequences
10:37 jnthn And multi-codepoint sequences forming a single grapheme
10:38 jnthn Which the DecodeStream stuff handles correctly and fairly nicely
10:38 konobi isn't there a grammar for it?
10:39 jnthn You mean, decoding utf-8 using a Perl 6 grammar? :)
10:39 konobi sure =0)
10:40 konobi i'm pretty sure it should JIT well
10:40 jnthn You probably could, but I'm not sure it's very practical in reality :)
10:41 jnthn I'm pretty sure it wouldn't. Not without significant changes to grammars. And efficient UTF-8 decoding is pretty much a solved problem.
10:41 jnthn Don't think we need to re-invent that wheel.
10:41 jnthn However cute it might be :)
10:41 konobi nor would i suggest so
10:44 * jnthn tries to decide if this is a bunch of stuff to try and do now, given we've by this point got quite a number of outstanding bug reports in the area...
10:45 konobi jnthn: well, it's the sort of stuff that I'm expecting to be able to do for practical purposes, like taking a grammar and attaching it to a stream so that I get full objects/hahes out. dhcp packet, sctp, postgres, redis, pcap, etc.
10:46 jnthn *nod*
10:46 konobi but yeah, for unicode streams... it's a little excessive ^_^
10:47 jnthn https://rt.perl.org/Ticket/Display.html?id=128862 and https://rt.perl.org/Ticket/Display.html?id=128863 are two of the more embarassing tickets that I'd really like to nail :)
10:48 jnthn So yeah, probably time to stop putting this stuff off :)
10:49 jnthn Plus the much-hated https://github.com/MoarVM/MoarVM/issues/165
10:50 konobi i know that adding streaming decoders to node was a big win back several versions ago
10:53 konobi both in terms of performance and resumability (in cases of malformed bytes, etc.)
10:54 lizmat joined #moarvm
10:55 konobi (since dying on a malformed string would have epic consequences to crashing a nodejs app)
10:56 jnthn Yeah, that's exactly the problem we're facing too :)
10:56 zakharyas joined #moarvm
10:56 jnthn At least we're not to only ones to do that fail :P
10:57 konobi yeah, there were some pretty epic fails along the way
10:58 konobi node has some really great concepts when it comes to handling I/O asyncly in a sane but flexible way
10:59 jnthn lunch, then will dig into exposing the decode stream stuffs we have :)
10:59 * nwc10 is a creature of habit and about to remind ilmari about this, but then remembered...
11:02 ilmari :D
11:58 edehont joined #moarvm
12:07 kjs_ joined #moarvm
12:31 domidumont joined #moarvm
12:32 dalek MoarVM/expose-decode-stream: 7a3e7f8 | jnthn++ | / (6 files):
12:32 dalek MoarVM/expose-decode-stream: Stub in Decoder REPR.
12:32 dalek MoarVM/expose-decode-stream: review: https://github.com/MoarVM/MoarVM/commit/7a3e7f8327
12:32 dalek MoarVM/expose-decode-stream: 7936fa7 | jnthn++ | / (6 files):
12:32 dalek MoarVM/expose-decode-stream: Stub in new decoder-related ops.
12:32 dalek MoarVM/expose-decode-stream: review: https://github.com/MoarVM/MoarVM/commit/7936fa7f83
12:35 JimmyZ 7. Refactor sync I/O to not use libuv # we still use libuv for sync IO? I thought it's not
12:35 jnthn Yes, we still do
12:36 konobi anything you can do sync, you can implement with async
12:36 JimmyZ 8. Refactor async I/O to not use libuv ? :P
12:36 konobi libuv's a well proven library
12:37 jnthn No way
12:37 jnthn libuv does an incredible amount of heavy lifting on async I/O that I absolutely zero interest in replicating.
12:37 jnthn *I have
12:38 jnthn Not least in dealing with all the numerous quirks of various platforms.
12:39 konobi it's had a lot of money thrown behind it... so it's probably as goos as it's going to get
12:39 konobi *good
12:39 JimmyZ ah, i see ,it is about sync socket
12:40 konobi any file descriptor really
12:40 jnthn Right. There's no way we're going to come up with something better with the resources we have, and if we had the resources to do that we'd still be better spending them on stuff that'd let MoarVM and Perl 6 stand out, ratehr that re-solving a solved problem.
12:40 jnthn *rather
12:40 * JimmyZ agrees
12:41 JimmyZ ea and jit etc are more important to do haha
12:41 moritz and if there's a problem with some details of libuv, not its overall architecture, contributing to upstream libuv would be much more economical than reinvent it
12:44 JimmyZ jnthn: re https://github.com/MoarVM/MoarVM/issues/234, do we have the same problem with async?
12:45 jnthn JimmyZ: Doubt it.
12:46 jnthn Pretty sure not actually, I was looking at that code a few days ago
12:46 jnthn Well, or few weeks... :)
12:47 timotimo with a recent change to afl-fuzz's scheduling of paths, it's coming up with a crapton of different unique crashes
12:47 timotimo (well, it says the crashes are unique...)
12:48 moritz that doesn't mean it actually is :-)
12:48 timotimo correct
12:49 timotimo http://collect.p6c.org/cgi-bin/collection.modified.cgi?action=show_graph;plugin=cpu;type=cpu;plugin_instance=cpu-sum;host=hack.p6c.org;timespan=day;start=12:49%20Aug%2023%202016;end=12:49%20Aug%2024%202016;=undefined;
12:49 timotimo (yay, huge urls)
12:50 timotimo will we get our own url shortener? :P
12:51 nwc10 dogfood?
12:51 moritz dogfo.od/
12:51 timotimo hah
12:51 moritz there's no .od TLD, it seems :(
12:51 timotimo but probably .food
12:51 timotimo ok, this is #perl6 talk now :P
12:52 nwc10 don't all channels turn into that eventually?
13:01 jnthn Righty, code stubbed, tests stubbed, now to start making things work.
13:05 TheLemonMan that was fast
13:06 timotimo ugh, bash completion
13:07 timotimo won't let me complete this path/filename because ... why exactly? probably because the command starts with "gdb --args"?
13:08 timotimo ah! an interesting crash! it explodes inside set_size_internal in MVMArray
13:12 timotimo buh. compiled with -O0 and i still get some things "optimized out" in gdb ... annoying
13:14 timotimo looks like it's just calling setelemspos on an uninitialized(??) MVMArray
13:15 timotimo at least the slots pointer is a null pointer, which explains the asplosion
13:26 kjs_ joined #moarvm
13:31 zakharyas joined #moarvm
13:42 lizmat joined #moarvm
13:53 nine h/win 14
13:54 lizmat c2-c4
14:06 kjs_ joined #moarvm
14:21 kjs_ joined #moarvm
14:30 lizmat joined #moarvm
14:34 kjs_ joined #moarvm
14:39 dalek MoarVM/expose-decode-stream: c3e199f | jnthn++ | src/ (3 files):
14:39 dalek MoarVM/expose-decode-stream: Implement various of the new decoder ops.
14:39 dalek MoarVM/expose-decode-stream: review: https://github.com/MoarVM/MoarVM/commit/c3e199fb8c
14:43 jnthn That nearly gets me much of what I need for fixing async sockets at least
14:46 jnthn Though in looking at what I need for that I think I spotted a subtle bug
14:51 lizmat joined #moarvm
14:57 lizmat joined #moarvm
15:11 dalek MoarVM/expose-decode-stream: 5116ada | jnthn++ | / (10 files):
15:11 dalek MoarVM/expose-decode-stream: Distinguish taking all chars from available chars.
15:11 dalek MoarVM/expose-decode-stream:
15:11 dalek MoarVM/expose-decode-stream: The "all chars" indicates we have reached EOF and so want to take all
15:11 dalek MoarVM/expose-decode-stream: that is left, flushing the normalization buffer. The "available chars"
15:11 dalek MoarVM/expose-decode-stream: indicates that we want to take what is available, but leave anything
15:11 dalek MoarVM/expose-decode-stream: in the normalization buffer in place (so an incoming combiner can go
15:11 dalek MoarVM/expose-decode-stream: on it, for example).
15:11 dalek MoarVM/expose-decode-stream: review: https://github.com/MoarVM/MoarVM/commit/5116adac2a
15:11 timotimo ooooh
15:11 jnthn IO::Socket::Async gets that wrong today (always does the "all" behavior)
15:12 timotimo a-ha!
15:12 jnthn Not going to fix it in Moar though; will just implement it correctly when switching Rakudo to use the new decode stream stuff
15:13 timotimo right
15:13 jnthn Also, thanks to my test writing, just discovered another little bug :)
15:13 timotimo that'll be soon enough
15:13 timotimo \o/
15:23 dalek MoarVM/expose-decode-stream: b73d8dc | jnthn++ | src/strings/ (2 files):
15:23 dalek MoarVM/expose-decode-stream: Correct decode stream empty check.
15:23 dalek MoarVM/expose-decode-stream:
15:23 dalek MoarVM/expose-decode-stream: It should factor in unnormalized things in the normalization buffer
15:23 dalek MoarVM/expose-decode-stream: too.
15:23 dalek MoarVM/expose-decode-stream: review: https://github.com/MoarVM/MoarVM/commit/b73d8dc9d4
15:26 * jnthn spectests, hoping that tweak won't have caused bustage
15:30 jnthn Phew, it's fine :)
15:30 timotimo \o/
15:33 jnthn Time for a break :)
16:38 lizmat joined #moarvm
16:41 TheLemonMan timotimo, can you point me to the part in the spesh that deals with the mvmframes ?
16:42 timotimo ummm
16:42 timotimo deals wih the mvmframes?
16:43 timotimo i'm not sure what you mean :(
16:43 timotimo inlining perhaps?
16:44 TheLemonMan hmm, some optimization pass that might modify the existing mvmframe and/or the call chain
16:44 TheLemonMan I can't be more precise because I don't know yet what to look for heh
16:44 timotimo the bytecode in the frame stays around, but invoking can trigger any of the spesh "candidates" to be invoked instead
16:45 timotimo and dedoptimization goes from a spesh'd candidate to the original bytecode
17:15 edehont joined #moarvm
17:31 kjs_ joined #moarvm
17:54 kjs_ joined #moarvm
18:08 kjs_ joined #moarvm
18:17 timotimo TheLemonMan: sorry, i was probably not helpful; can you try broadening your question so i can figure out what you're looking for?
18:30 khagan joined #moarvm
18:35 TheLemonMan timotimo, I was just poking around in the spesh trying to figure out why #120 doesn't segfault anymore
18:39 jnthn It might have been that some callframe introspection op got marked noinline
18:39 timotimo that's a good hint
18:40 jnthn git log --grep=noinline will show those up, I'd bet
18:41 timotimo git blame on src/core/oplist might also give appropriate hints
18:41 timotimo git gui blame if you want to be able to directly see the related commit's message
18:42 kjs_ joined #moarvm
18:42 jnthn It mighta been something else, but that'd be my first guess
18:43 TheLemonMan disabling the inlining, jit or osr doesn't seem to have any effect
18:43 jnthn Wait, is it still broken?
18:43 timotimo "doesn't segfault any more" implies you've found a commit that has the segfault?
18:44 jnthn If so...it's also possible that we just got more robust somewhere
18:45 TheLemonMan bisecting is too tiresome as you need to rebuild nqp/rakudo after some commit
18:46 hoelzro TheLemonMan: I use ccache and a script that keeps old NQPs around to speed up bisects; maybe that would help?
18:46 TheLemonMan hmm, that's a smart idea heh
18:51 hoelzro =)
18:52 timotimo did you know we have "bisectable"?
18:53 hoelzro timotimo: this was in the dark days before bisectable =)
18:53 hoelzro also, local bisect is still useful when it comes to code testing modules and other larger things
18:53 hoelzro (unless bisectable is even better than I thought)
19:05 TheLemonMan the robustness is masking this bug pretty well heh
19:38 [Coke]_ joined #moarvm
19:59 TimToady m: my @pieces = <mouse 1>, <cat 3>, <bird 1>, <dog 2>, <frog 5>, <cat 2>, <mouse 7>; say [⊎] @pieces».Hash
19:59 camelia rakudo-moar a4cc1c: OUTPUT«bag(mouse(8), frog(5), cat(5), bird, dog(2))␤»
20:01 TheLemonMan joined #moarvm
20:02 hoelzro =O
20:02 hoelzro TIL
20:03 TimToady oops, mischan
20:09 TheLemonMan joined #moarvm
20:10 kjs_ joined #moarvm
20:11 timotimo ooooh
20:11 timotimo is that (+)?
20:49 brrt joined #moarvm
22:42 moritz joined #moarvm
22:47 Util joined #moarvm
22:52 edehont joined #moarvm

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