Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-10-30

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

All times shown according to UTC.

Time Nick Message
00:30 ilbot3 joined #moarvm
00:30 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:15 tokuhiro_ joined #moarvm
02:33 tokuhirom joined #moarvm
02:40 tokuhirom joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:16 tokuhiro_ joined #moarvm
05:21 vendethiel joined #moarvm
07:05 FROGGS joined #moarvm
08:00 TimToady joined #moarvm
09:07 KDr2_ joined #moarvm
09:13 zakharyas joined #moarvm
09:32 tokuhiro_ joined #moarvm
09:36 kjs_ joined #moarvm
09:45 brrt joined #moarvm
09:45 brrt good * #moarvm
09:47 brrt what, a SEGV in moar, that isn't sensistive to either spesh or jit
09:47 brrt :-o
09:47 brrt that is remarkable
09:59 lizmat brrt: you mean the one I rakudobugged yesterday ?
10:00 timotimo used to be much easier to do before we put more and more MVM_isnull checks into interp.c :)
10:02 brrt i dunno lizmat, maybe that one
10:03 lizmat m: use nqp; class A { has str $!a; method BUILD() { nqp::chars($!a) } }; A.new
10:03 camelia rakudo-moar 2856ed: OUTPUT«(signal SEGV)»
10:05 brrt no, that's a different one
10:06 brrt oh, that looks bad
10:06 brrt although that's probably just a NPE?
10:06 timotimo isn't that just another point where we ought to check MVM_isnull?
10:06 timotimo m: use nqp; nqp::chars(nqp::null);
10:06 camelia rakudo-moar 2856ed: OUTPUT«Cannot unbox a type object␤  in block <unit> at /tmp/BJPfhs5uuV:1␤␤»
10:06 timotimo that potentially gets hllmap'd?
10:07 lizmat I think it's a missing initialization for native str on attributes
10:07 timotimo mhm
10:07 lizmat m: use nqp; my str $a; say nqp::chars($a)   # no problem here
10:07 camelia rakudo-moar 2856ed: OUTPUT«0␤»
10:07 timotimo mhm
10:09 jnthn m: use nqp; nqp::chars(nqp::null_s)
10:09 camelia rakudo-moar 2856ed: OUTPUT«(signal SEGV)»
10:09 jnthn ah, that
10:09 brrt :-)
10:09 timotimo haha, i thought about using null_s, but i expected that *that* wouldn't be problematic, compared to nqp::null
10:39 jnthn m: use nqp; nqp::codes(nqp::null_s)
10:39 camelia rakudo-moar 2856ed: OUTPUT«===SORRY!===␤No registered operation handler for 'codes'␤»
10:41 dalek MoarVM: fa03d65 | jnthn++ | src/strings/ops. (2 files):
10:41 dalek MoarVM: Fix SEGV on nqp::chars on a null string.
10:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fa03d65741
10:42 jnthn lizmat: ^^ should fix the SEGV
10:42 jnthn Though prolly not the attr init issue
10:43 * jnthn assumes there's a ticket tracking it
10:44 lizmat #126492
10:44 synbot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=126492
10:44 jnthn Cool
10:46 jnthn ah, eek
10:47 jnthn The test I've busted in nqp is the one for nqp::readlinefh, which doesn't understand the \r\n synthetic...
10:49 kjs_ joined #moarvm
10:54 jnthn Ah, and that's why the Rakduo build is busted
11:14 jnthn Gee, \r\n is quite the can of worms
11:14 jnthn So far it's basically brought up 2 other issues that I really need to deal with.
11:14 jnthn (That were known, and one of them is on the xmas list too)
11:27 lizmat I guess the \r\n synthetic is troublesome because it need to be part of nqp::const::CCLASS_WHITESPACE ?
11:27 lizmat *needs
11:28 lizmat perhaps fixable by making it always synthetic -1 ?
11:29 lizmat jnthn: ^^^
11:29 jnthn lizmat: Actually that bit is already fine
11:30 jnthn lizmat: 'cus graphemes take the properties of the base char
11:30 jnthn And \r is whitespace
11:30 lizmat ah, ok  :-)
11:30 jnthn That's one of the few problems we don't have :)
11:30 lizmat :-)
11:30 lizmat .oO( looking for problems in all the wrong places )
11:30 jnthn The one I'm dealing with now is mostly 'cus I just put off dealing with RT #122971
11:30 synbot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=122971
11:31 jnthn That is, separator handling for reading line by line has always been a "quick thing that'll work for hacky reasons"
11:31 lizmat ok, then maybe also consider putting in :chomp at the MvM or nqp level ?
11:32 jnthn Yeah, that's in The Plans
11:32 lizmat fwiw, we have a working IO::Handle.split that takes regexes
11:32 jnthn Though I was planning to work on I/O things *next* week, not this one :)
11:32 lizmat so, if we have a :nl that is a regex, we can refer to that at the rakudo level
11:33 jnthn aha
11:33 jnthn But for non-regex ones, best to leave it to the guts
11:33 lizmat yeah, because IO::Handle.split("\n") currently performs better than .lines, because of the :chomp at rakudo level
11:35 jnthn Wow :)
11:35 jnthn The thing is
11:35 jnthn the .chomp doesn't actually work
11:35 jnthn The moment you pick a separator that isn't \n
11:35 jnthn So it's gotta go anyway
11:36 lizmat $ 6 'my @a = "words".IO.open.split("\n")'
11:36 lizmat real0m0.651s
11:36 lizmat $ 6 'my @a = "words".IO.open.lines'
11:36 lizmat real0m1.230s
11:36 lizmat jnthn: indeed   :-)
11:48 tokuhiro_ joined #moarvm
12:10 kjs_ joined #moarvm
12:16 dalek MoarVM: 65bcb12 | jnthn++ | src/ (11 files):
12:16 dalek MoarVM: Start refactoring I/O handling of line separators.
12:16 dalek MoarVM:
12:16 dalek MoarVM: Introduce a new data structure that can hold multiple multi-grapheme
12:16 dalek MoarVM: separators. Update the decoders themselves to know about it. No
12:16 dalek MoarVM: semantic changes so far; this is just an enabling refactor.
12:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/65bcb12a83
12:29 dalek MoarVM: 81fb7c1 | jnthn++ | src/ (7 files):
12:29 dalek MoarVM: Refactor handles for new separator data structure.
12:29 dalek MoarVM:
12:29 dalek MoarVM: Again, no intended semantics changes in this patch. However, we do now
12:29 dalek MoarVM: preserve the full set of graphemes in multi-grapheme separators, to
12:29 dalek MoarVM: later enable full handling of this case (for now, only the handling of
12:29 dalek MoarVM: multiple separators is going to be used, as part of the \r\n grapheme
12:29 dalek MoarVM: change).
12:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/81fb7c1649
12:41 dalek MoarVM: d87a5a0 | jnthn++ | src/moar.c:
12:41 dalek MoarVM: Set up NFG subsystem before I/O handles.
12:41 dalek MoarVM:
12:41 dalek MoarVM: So we'll be able to compute the \r\n synthetic when setting up the
12:41 dalek MoarVM: default separators on the standard handles.
12:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d87a5a051b
12:59 tokuhiro_ joined #moarvm
13:12 tokuhirom_h joined #moarvm
13:40 dalek MoarVM: a5f1971 | jnthn++ | src/io/syncfile.c:
13:40 dalek MoarVM: Set default separator on syncfile handle.
13:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a5f197164f
13:40 dalek MoarVM: 47bb37e | jnthn++ | src/strings/decode_stream.c:
13:40 dalek MoarVM: Include \r\n synthetic in default separators.
13:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/47bb37efdd
13:42 * [Coke] wonders if this is going to screw up rj at all.
13:42 jnthn [Coke]: I'm doing my best to not do so
13:43 kjs_ joined #moarvm
13:43 jnthn (e.g. write code in NQP/Rakudo that is open to either case)
13:45 [Coke] jnthn++ I figured you were, just wasn't sure if we would soon hit the "jvm must now implement NFG etc." stage. :)
13:46 psch tangentially related, in how far is NFG involved with unicode properties?  e.g. Lr as a composite property isn't on jvm 1.7 at least, not sure about 1.8
13:47 jnthn psch: The synthetics inherit their properties from the base grapheme, so far.
13:48 psch jnthn: so we could be fine with building e.g. Lr from Ll, Lu and Lt manually?
13:49 psch that's S05-mass/properties-general.t, for reference
13:49 jnthn psch: Well, one option is to steal MoarVM's Unicode database script, hack it to spit out Java instead, and ship our own Unicode database.
13:52 psch i suppose something like that had happened in the past.  at least i hope no one wrote the 114 lines of static initialization in Ops.java manually...
13:52 jnthn I don't think I'd have had the patience ;)
13:53 jnthn Phew, I've got a Rakudo built using the \r\n -> 1 grapheme
13:54 psch anyway, yeah, i think not having to rely on oracle doing what we'd like to be right wrt unicode is probably saner
13:54 nwc10 you mentioned re-bootstrap - is that likely within the next day or two?
13:55 [Coke] m: say ?"\r\n".chars == 1
13:55 camelia rakudo-moar ba7027: OUTPUT«True␤»
13:55 [Coke] m: say "\r\n".chars == 1
13:55 camelia rakudo-moar ba7027: OUTPUT«False␤»
13:55 [Coke] <archer>Precedence!</archer>
13:55 jnthn m: say "\r\n".chars
13:55 camelia rakudo-moar ba7027: OUTPUT«2␤»
13:55 jnthn That's 1 locally :)
13:56 nwc10 are we also going to have NFT (Normalisation Form Twitter), which means that absoluately any Perl 6 program can fit into a single Tweet? :-)
13:57 jnthn nwc10: Not sure; I need to look at $other-thing for a bit this evening and then it'll be weekend and I should probably rest more than hack. And I can see that there's some amount of Rakudo tweaks needed.
13:57 nwc10 140 completely arbirary synthetics
13:57 jnthn And other encoding. :)
13:57 jnthn Heh, NFT :D
13:57 jnthn Yeah but getting it to Twitter would be tricky :)
13:58 jnthn 'cus you'd have to encode it, and NFG vanishes at encoding time
13:58 nwc10 that's a bother.
13:58 jnthn Anyway, rebootstrap probably not until Monday
13:59 jnthn 'cus I need to teach Rakudo's I/O that no, \n is not a sufficient separator default
14:00 jnthn And that may well be an API change
14:00 jnthn Not to mention we need an API to tell the VM about multiple separators
14:01 nwc10 I see what you meant about the little rabbit hole opening up onto a view of a field of yaks, awaiting your razor
14:01 nwc10 lots of stuff that can't be put off any more
14:02 jnthn Aye
14:02 jnthn Well, there's an xmas RT about sorting out the line seps stuff too
14:02 jnthn So this was already on the horizon.
14:03 nwc10 good job we never promised which Christma - oh wait :-)
14:03 jnthn :-)
14:04 jnthn Yes, a bit bothersome there are 66 xmas RTs and that's more than one per day to reach xmas
14:04 jnthn otoh there are some that'll probably boil down to "no, we're not doing this before 6.c" or "the current behavior is fine"
14:05 tokuhirom_h joined #moarvm
14:17 jnthn Anyway, time for $other-task
14:42 synbot6 joined #moarvm
15:03 colomon joined #moarvm
15:21 tokuhirom joined #moarvm
16:45 synbot6 joined #moarvm
17:01 vendethiel joined #moarvm
17:22 tokuhirom joined #moarvm
19:00 kjs_ joined #moarvm
19:36 tokuhirom_h joined #moarvm
20:18 tokuhirom joined #moarvm
21:35 leont joined #moarvm
22:25 tokuhirom joined #moarvm
23:03 kjs_ joined #moarvm

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