00:30 ilbot3 joined 02:15 tokuhiro_ joined 02:33 tokuhirom joined 02:40 tokuhirom joined 02:47 ilbot3 joined 03:16 tokuhiro_ joined 05:21 vendethiel joined 07:05 FROGGS joined 08:00 TimToady joined 09:07 KDr2_ joined 09:13 zakharyas joined 09:32 tokuhiro_ joined 09:36 kjs_ joined 09:45 brrt joined
brrt good * #moarvm 09:45
what, a SEGV in moar, that isn't sensistive to either spesh or jit 09:47
:-o
that is remarkable
lizmat brrt: you mean the one I rakudobugged yesterday ? 09:59
timotimo used to be much easier to do before we put more and more MVM_isnull checks into interp.c :) 10:00
brrt i dunno lizmat, maybe that one 10:02
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)»
brrt no, that's a different one 10:05
oh, that looks bad 10:06
although that's probably just a NPE?
timotimo isn't that just another point where we ought to check MVM_isnull?
m: use nqp; nqp::chars(nqp::null);
camelia rakudo-moar 2856ed: OUTPUT«Cannot unbox a type object␤ in block <unit> at /tmp/BJPfhs5uuV:1␤␤»
timotimo that potentially gets hllmap'd?
lizmat I think it's a missing initialization for native str on attributes 10:07
timotimo mhm
lizmat m: use nqp; my str $a; say nqp::chars($a) # no problem here
camelia rakudo-moar 2856ed: OUTPUT«0␤»
timotimo mhm
jnthn m: use nqp; nqp::chars(nqp::null_s) 10:09
camelia rakudo-moar 2856ed: OUTPUT«(signal SEGV)»
jnthn ah, that
brrt :-)
timotimo haha, i thought about using null_s, but i expected that *that* wouldn't be problematic, compared to nqp::null
jnthn m: use nqp; nqp::codes(nqp::null_s) 10:39
camelia rakudo-moar 2856ed: OUTPUT«===SORRY!===␤No registered operation handler for 'codes'␤»
dalek arVM: fa03d65 | jnthn++ | src/strings/ops. (2 files):
Fix SEGV on nqp::chars on a null string.
 10:41
jnthn lizmat: ^^ should fix the SEGV 10:42
Though prolly not the attr init issue
jnthn assumes there's a ticket tracking it 10:43
lizmat #126492 10:44
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126492
jnthn Cool
ah, eek 10:46
The test I've busted in nqp is the one for nqp::readlinefh, which doesn't understand the \r\n synthetic... 10:47
10:49 kjs_ joined
jnthn Ah, and that's why the Rakduo build is busted 10:54
Gee, \r\n is quite the can of worms 11:14
So far it's basically brought up 2 other issues that I really need to deal with.
(That were known, and one of them is on the xmas list too)
lizmat I guess the \r\n synthetic is troublesome because it need to be part of nqp::const::CCLASS_WHITESPACE ? 11:27
*needs
perhaps fixable by making it always synthetic -1 ? 11:28
jnthn: ^^^ 11:29
jnthn lizmat: Actually that bit is already fine
lizmat: 'cus graphemes take the properties of the base char 11:30
And \r is whitespace
lizmat ah, ok :-)
jnthn That's one of the few problems we don't have :)
lizmat :-)
.oO( looking for problems in all the wrong places )
jnthn The one I'm dealing with now is mostly 'cus I just put off dealing with RT #122971
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=122971
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 ?
jnthn Yeah, that's in The Plans 11:32
lizmat fwiw, we have a working IO::Handle.split that takes regexes
jnthn Though I was planning to work on I/O things *next* week, not this one :)
lizmat so, if we have a :nl that is a regex, we can refer to that at the rakudo level
jnthn aha 11:33
But for non-regex ones, best to leave it to the guts
lizmat yeah, because IO::Handle.split("\n") currently performs better than .lines, because of the :chomp at rakudo level
jnthn Wow :) 11:35
The thing is
the .chomp doesn't actually work
The moment you pick a separator that isn't \n
So it's gotta go anyway
lizmat $ 6 'my @a = "words".IO.open.split("\n")' 11:36
real0m0.651s
$ 6 'my @a = "words".IO.open.lines'
real0m1.230s
jnthn: indeed :-)
11:48 tokuhiro_ joined 12:10 kjs_ joined
dalek arVM: 65bcb12 | jnthn++ | src/ (11 files):
Start refactoring I/O handling of line separators.

Introduce a new data structure that can hold multiple multi-grapheme separators. Update the decoders themselves to know about it. No semantic changes so far; this is just an enabling refactor.		 12:16
arVM: 81fb7c1 | jnthn++ | src/ (7 files):
Refactor handles for new separator data structure.

Again, no intended semantics changes in this patch. However, we do now preserve the full set of graphemes in multi-grapheme separators, to later enable full handling of this case (for now, only the handling of multiple separators is going to be used, as part of the \r\n grapheme change).		 12:29
arVM: d87a5a0 | jnthn++ | src/moar.c:
Set up NFG subsystem before I/O handles.

So we'll be able to compute the \r\n synthetic when setting up the default separators on the standard handles.		 12:41
12:59 tokuhiro_ joined 13:12 tokuhirom_h joined
dalek arVM: a5f1971 | jnthn++ | src/io/syncfile.c:
Set default separator on syncfile handle.
 13:40
arVM: 47bb37e | jnthn++ | src/strings/decode_stream.c:
Include \r\n synthetic in default separators.
[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
jnthn (e.g. write code in NQP/Rakudo that is open to either case) 13:43
[Coke] jnthn++ I figured you were, just wasn't sure if we would soon hit the "jvm must now implement NFG etc." stage. :) 13:45
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:46
jnthn psch: The synthetics inherit their properties from the base grapheme, so far. 13:47
psch jnthn: so we could be fine with building e.g. Lr from Ll, Lu and Lt manually? 13:48
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.
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 ;)
Phew, I've got a Rakudo built using the \r\n -> 1 grapheme 13:53
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?
[Coke] m: say ?"\r\n".chars == 1 13:55
camelia rakudo-moar ba7027: OUTPUT«True␤»
[Coke] m: say "\r\n".chars == 1
camelia rakudo-moar ba7027: OUTPUT«False␤»
[Coke] <archer>Precedence!</archer>
jnthn m: say "\r\n".chars
camelia rakudo-moar ba7027: OUTPUT«2␤»
jnthn That's 1 locally :)
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:56
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
jnthn And other encoding. :)
Heh, NFT :D
Yeah but getting it to Twitter would be tricky :)
'cus you'd have to encode it, and NFG vanishes at encoding time 13:58
nwc10 that's a bother.
jnthn Anyway, rebootstrap probably not until Monday
'cus I need to teach Rakudo's I/O that no, \n is not a sufficient separator default 13:59
And that may well be an API change 14:00
Not to mention we need an API to tell the VM about multiple separators
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
lots of stuff that can't be put off any more
jnthn Aye 14:02
Well, there's an xmas RT about sorting out the line seps stuff too
So this was already on the horizon.
nwc10 good job we never promised which Christma - oh wait :-) 14:03
jnthn :-)
Yes, a bit bothersome there are 66 xmas RTs and that's more than one per day to reach xmas 14:04
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
jnthn Anyway, time for $other-task 14:17
14:42 synbot6 joined 15:03 colomon joined 15:21 tokuhirom joined 16:45 synbot6 joined 17:01 vendethiel joined 17:22 tokuhirom joined 19:00 kjs_ joined 19:36 tokuhirom_h joined 20:18 tokuhirom joined 21:35 leont joined 22:25 tokuhirom joined 23:03 kjs_ 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!