01:48 ilbot3 joined 05:09 brrt joined
brrt TheLemonMan: that is, if it is true, really clever 05:11
damn, unsensitive to JIT 05:14
a memory corruption is often enough a JIT issue
especially when exceptions are involved
hmmm
oh well
off to register allocation troubles 05:19
06:02 brrt joined
brrt oh, i'm being silly 06:12
i can just encode the register spec as 4 bytes, no reason to be difficult about it 06:13
and of course, that scales linearly with the amount of registers we use...
heh
06:27 brrt joined
brrt oh, another bit of news: v8project.blogspot.nl/2016/08/firin...reter.html 06:35
heh, C fields specifiers save the day, no macros required 06:42
06:47 dalek joined
brrt hmm, hang one, my struct is still 32 bits wide then 06:52
that is not very nice
07:10 domidumont joined, lizmat joined 07:12 lizmat joined 07:14 domidumont joined 07:23 zakharyas joined 08:16 lizmat joined 08:40 lizmat joined 08:47 lizmat_ joined 08:54 lizmat joined 09:04 zakharyas1 joined 09:11 domidumont joined
jnthn Hm, in 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:51
github.com/joyent/libuv/commit/aab...3e4081R295 says: 09:52
* - UV_RUN_DEFAULT: Runs the event loop until the reference count drops to
* zero. Always returns zero.
oh, no, old docs 09:54
docs.libuv.org/en/v1.x/loop.html
10:16 TheLemonMan joined
JimmyZ hard bug , I thought it was a bug between gc and fix size alloc 10:17
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 :)
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
jnthn Yeah, also not a long-term one 10:20
Since it causes various other issues 10:21
(Like, not being able to use a socket across threads)
Maybe it's time to bite the bullet and stop doing that. 10:22
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
jnthn For one, I think that MoarVM's I/O layer should probably get out of the business of encoding/decoding 10:24
And we expose the DecodeStream API, and use it.
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
JimmyZ re switch to our new *libuv*, I may help to commit some code if someone starts, :) 10:26
TheLemonMan JimmyZ, guesswork :D
jnthn The other thing is that it'd be nice to fix up having real async file and console I/O too 10:27
Which people miss
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.
(And then the VM-provided ones will just be "accelerated" versions.) 10:28
Which all told is a good bunch of work, but perhaps a better use of time than lots of patching :)
So, I think we'll solve the bug in question as part of that work :) 10:31
Probably the logical work order is
10:31 edehont joined, zakharyas joined
jnthn 1. Expose the decode stream from MoarVM 10:31
2. Use it in the async sockets and async processes implementations 10:32
3. Refactor to allow userspace encodings 10:33
4. Use this for sync I/O too
5. Fix up NQP similarly :) 10:34
6. Deprecate/remove string-based I/O from MoarVM, so it only deals in bytes
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
konobi: Pretty solid where?
konobi dealing only in bytes
jnthn Ah ;)
We don't use it to deal with non-bytes tbh :)
The thing is that we have MoarVM providing high-level I/O operations that deal in strings. 10:36
Which means it then gets very hard to extend encodings supported to userspace
konobi $str.to_bytes() ? 10:37
jnthn .encode, but pretty much, yes
Decoding is the fun part
Because of multi-byte sequences
And multi-codepoint sequences forming a single grapheme
Which the DecodeStream stuff handles correctly and fairly nicely 10:38
konobi isn't there a grammar for it?
jnthn You mean, decoding utf-8 using a Perl 6 grammar? :) 10:39
konobi sure =0)
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 :)
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
Don't think we need to re-invent that wheel.
However cute it might be :)
konobi nor would i suggest so
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:44
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:45
jnthn *nod* 10:46
konobi but yeah, for unicode streams... it's a little excessive ^_^
jnthn rt.perl.org/Ticket/Display.html?id=128862 and rt.perl.org/Ticket/Display.html?id=128863 are two of the more embarassing tickets that I'd really like to nail :) 10:47
So yeah, probably time to stop putting this stuff off :) 10:48
Plus the much-hated github.com/MoarVM/MoarVM/issues/165 10:49
konobi i know that adding streaming decoders to node was a big win back several versions ago 10:50
both in terms of performance and resumability (in cases of malformed bytes, etc.) 10:53
10:54 lizmat joined
konobi (since dying on a malformed string would have epic consequences to crashing a nodejs app) 10:55
jnthn Yeah, that's exactly the problem we're facing too :) 10:56
10:56 zakharyas joined
jnthn At least we're not to only ones to do that fail :P 10:56
konobi yeah, there were some pretty epic fails along the way 10:57
node has some really great concepts when it comes to handling I/O asyncly in a sane but flexible way 10:58
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...
ilmari :D 11:02
11:58 edehont joined 12:07 kjs_ joined 12:31 domidumont joined
dalek arVM/expose-decode-stream: 7a3e7f8 | jnthn++ | / (6 files):
Stub in Decoder REPR.
 12:32
arVM/expose-decode-stream: 7936fa7 | jnthn++ | / (6 files):
Stub in new decoder-related ops.
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
konobi anything you can do sync, you can implement with async 12:36
JimmyZ 8. Refactor async I/O to not use libuv ? :P
konobi libuv's a well proven library
jnthn No way 12:37
libuv does an incredible amount of heavy lifting on async I/O that I absolutely zero interest in replicating.
*I have
Not least in dealing with all the numerous quirks of various platforms. 12:38
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
*good
JimmyZ ah, i see ,it is about sync socket
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.
*rather
JimmyZ agrees
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
JimmyZ jnthn: re github.com/MoarVM/MoarVM/issues/234, do we have the same problem with async? 12:44
jnthn JimmyZ: Doubt it. 12:45
Pretty sure not actually, I was looking at that code a few days ago 12:46
Well, or few weeks... :)
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
(well, it says the crashes are unique...)
moritz that doesn't mean it actually is :-) 12:48
timotimo correct
collect.p6c.org/cgi-bin/collection....undefined; 12:49
(yay, huge urls)
will we get our own url shortener? :P 12:50
nwc10 dogfood? 12:51
moritz dogfo.od/
timotimo hah
moritz there's no .od TLD, it seems :(
timotimo but probably .food
ok, this is #perl6 talk now :P
nwc10 don't all channels turn into that eventually? 12:52
jnthn Righty, code stubbed, tests stubbed, now to start making things work. 13:01
TheLemonMan that was fast 13:05
timotimo ugh, bash completion 13:06
won't let me complete this path/filename because ... why exactly? probably because the command starts with "gdb --args"? 13:07
ah! an interesting crash! it explodes inside set_size_internal in MVMArray 13:08
buh. compiled with -O0 and i still get some things "optimized out" in gdb ... annoying 13:12
looks like it's just calling setelemspos on an uninitialized(??) MVMArray 13:14
at least the slots pointer is a null pointer, which explains the asplosion 13:15
13:26 kjs_ joined 13:31 zakharyas joined 13:42 lizmat joined
nine h/win 14 13:53
lizmat c2-c4 13:54
14:06 kjs_ joined 14:21 kjs_ joined 14:30 lizmat joined 14:34 kjs_ joined
dalek arVM/expose-decode-stream: c3e199f | jnthn++ | src/ (3 files):
Implement various of the new decoder ops.
 14:39
jnthn That nearly gets me much of what I need for fixing async sockets at least 14:43
Though in looking at what I need for that I think I spotted a subtle bug 14:46
14:51 lizmat joined 14:57 lizmat joined
dalek arVM/expose-decode-stream: 5116ada | jnthn++ | / (10 files):
Distinguish taking all chars from available chars.

The "all chars" indicates we have reached EOF and so want to take all that is left, flushing the normalization buffer. The "available chars" indicates that we want to take what is available, but leave anything in the normalization buffer in place (so an incoming combiner can go on it, for example).		 15:11
timotimo ooooh
jnthn IO::Socket::Async gets that wrong today (always does the "all" behavior)
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
timotimo right 15:13
jnthn Also, thanks to my test writing, just discovered another little bug :)
timotimo that'll be soon enough
\o/
dalek arVM/expose-decode-stream: b73d8dc | jnthn++ | src/strings/ (2 files):
Correct decode stream empty check.

It should factor in unnormalized things in the normalization buffer too.		 15:23
jnthn spectests, hoping that tweak won't have caused bustage 15:26
Phew, it's fine :) 15:30
timotimo \o/
jnthn Time for a break :) 15:33
16:38 lizmat joined
TheLemonMan timotimo, can you point me to the part in the spesh that deals with the mvmframes ? 16:41
timotimo ummm 16:42
deals wih the mvmframes?
i'm not sure what you mean :( 16:43
inlining perhaps?
TheLemonMan hmm, some optimization pass that might modify the existing mvmframe and/or the call chain 16:44
I can't be more precise because I don't know yet what to look for heh
timotimo the bytecode in the frame stays around, but invoking can trigger any of the spesh "candidates" to be invoked instead
and dedoptimization goes from a spesh'd candidate to the original bytecode 16:45
17:15 edehont joined 17:31 kjs_ joined 17:54 kjs_ joined 18:08 kjs_ joined
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:17
18:30 khagan joined
TheLemonMan timotimo, I was just poking around in the spesh trying to figure out why #120 doesn't segfault anymore 18:35
jnthn It might have been that some callframe introspection op got marked noinline 18:39
timotimo that's a good hint
jnthn git log --grep=noinline will show those up, I'd bet 18:40
timotimo git blame on src/core/oplist might also give appropriate hints 18:41
git gui blame if you want to be able to directly see the related commit's message
18:42 kjs_ joined
jnthn It mighta been something else, but that'd be my first guess 18:42
TheLemonMan disabling the inlining, jit or osr doesn't seem to have any effect 18:43
jnthn Wait, is it still broken?
timotimo "doesn't segfault any more" implies you've found a commit that has the segfault?
jnthn If so...it's also possible that we just got more robust somewhere 18:44
TheLemonMan bisecting is too tiresome as you need to rebuild nqp/rakudo after some commit 18:45
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
hoelzro =) 18:51
timotimo did you know we have "bisectable"? 18:52
hoelzro timotimo: this was in the dark days before bisectable =) 18:53
also, local bisect is still useful when it comes to code testing modules and other larger things
(unless bisectable is even better than I thought)
TheLemonMan the robustness is masking this bug pretty well heh 19:05
19:38 [Coke]_ joined
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
hoelzro =O 20:02
TIL
TimToady oops, mischan 20:03
20:09 TheLemonMan joined 20:10 kjs_ joined
timotimo ooooh 20:11
is that (+)?
20:49 brrt joined 22:42 moritz joined 22:47 Util joined 22:52 edehont joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!