Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-11-16

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

All times shown according to UTC.

Time Nick Message
00:16 stmuk_ joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:44 domidumont joined #moarvm
06:48 domidumont joined #moarvm
06:50 domidumont joined #moarvm
06:52 domidumont joined #moarvm
08:23 zakharyas joined #moarvm
08:59 brrt joined #moarvm
08:59 brrt \o #moarvm
08:59 nwc10 o/
09:00 brrt how are things?
09:00 nwc10 OK.
09:10 brrt hmm, okay :-)
09:11 brrt me, I'm happy, because I (conceptually, at least) solved a problem of unreferenceable references
09:13 * masak .oO( next, I will move on to squaring the circle! )
09:14 brrt well, it is a bit more specific than that :-)
09:15 brrt roughly; synthetic tiles don't live in the big tile array before their final step, so they can't be referenced by index into that big tile array; however, we can reference them out-of-band, and that will DWIM
09:15 brrt as in, I think it is safe to do so
09:24 masak I'm intrigued by the use of the word "synthetic"
09:24 masak that's something I use for 007 ASTs, too
09:25 masak (things that are parsed from text are "natural"; things that are created in vitro as AST objects with no connection to source text are "synthetic")
09:38 brrt well, it makes sense
09:39 brrt synthetic is basically used as standing for 'artificially created', which is of course not entirely what it means
09:39 brrt that usage probably comes from synthetic organic chemistry, in which things are synthesized as in 'put together'
09:43 brrt (and the reason to reference them in the first place is to ensure they are assigned the correct registers)
09:45 masak on average, a macro will want to freely mix parsed and synthetic ASTs. I find macros come to their full strength when one does.
09:46 masak the tricky detail is that (in Perl 6) a lot of checking happens during parse, so parsed ASTs are automatically safer/saner than synthetic ones.
09:46 masak two examples: you could create a synthetic Q::Identifier whose name is the empty string. can't happen with a parsed one.
09:46 masak you could create a synthetic AST containing a reference cycle.
09:47 jnthn morning, #moarvm
09:47 brrt morning jnthn
09:47 brrt hmm, yes, you could
09:47 masak a lot of things like that will have to be checked during macro expansion, when the synthetic AST is inserted into the program.
09:47 masak morning, jnthn -- Perl 6 day today? :)
09:47 brrt tbh, perl6 *ought* not to do the checking at parse time, necessarily
09:48 jnthn masak: Yup :)
09:48 masak brrt: there are very interesting tensions there, for sure
09:49 brrt or rather, the checking element could be implemented as a tree iterator and then work both during parsing and during macro expansion
09:49 masak heh
09:49 masak we'll get there in the end :>
09:49 masak it's exactly questions like these that 007 has (quietly) helped delve into in the past two years
09:50 jnthn I guess it boils down to syntactic vs. semantic checks
09:51 jnthn Where syntactic ones living in the grammar are no bother because you can't construct a "syntactically invalid" AST node
09:51 masak it's more like -- the textual medium puts up certain natural text-based limits
09:51 masak there's nothing *a priori* wrong with an identifier called "" or an identifier called "42 LULZ ☠"
09:51 masak it's just that the rules of parsing disallow them
09:52 jnthn Right, but even there we've got escape hatches for most things
09:52 masak (it's been tempting sometimes to implement gensyms using disallowed-by-parsing names)
09:52 jnthn m: class ::("42 LULZ ☠") { }.^name.say
09:52 camelia rakudo-moar ee8ae9: OUTPUT«42 LULZ ☠␤»
09:52 masak yes, good point
09:53 masak this all comes back to Perl not liking arbitrary limits :P
09:53 * masak .oO( what do you *mean* I can't call my class that!? )
09:53 * masak .oO( I'll *show* you weird! )
09:54 * brrt has had the 'but that is evil' discussion quite a few times in the last few months
09:55 brrt 'why do you hate code sanity' <- a literal question I've been asked
09:55 jnthn o.O :)
09:56 masak brrt: Perl mentality is a minority viewpoint there, which sometimes makes those discussions hard.
09:56 brrt well, in fairness, maybe sometimes I have suggested insane ideas, even for perl
09:56 brrt but yeah
09:57 timotimo o/
09:57 masak brrt: the rest of the world tends to think "if something is dangerous even though it's powerful and expressive, we should avoid it". Perl people tend to do the opposite: "if something is powerful and expressive even though it is dangerous, we should explore it"
10:02 brrt true
10:02 * jnthn is continuing on with his string flattening / hash cleanup, fwiw
10:02 jnthn Which should make us less combustible
10:02 brrt the counterargument is usually 'but what about my colleagues'
10:03 brrt which is less about 'my colleagues are idiots' and more about 'the bandwidth from me to my colleagues is really limited'
10:03 timotimo when we have "stores int8 chars", we can add a "doesn't own its memory" flag and point directly into the string heap :3
10:03 masak brrt: similar to the discussion about private members in classes
10:04 brrt on the other other hand, I think that expecting code to be the sole communicator of your ideas about the software is a rather limited viewpoint
10:04 jnthn fwiw, I've seen the "what about my colleagues" thing pop up discussing such insane horrors as type inference and lambda expressions in C# :)
10:04 masak brrt: it's not because colleagues are inherently power abusers; it's because it's a sane way to abstract things and expose the important bits
10:04 brrt that sanity is at least partially a convention, though
10:04 masak brrt: not the sole communicator -- but I'd say more than people in general expect
10:05 jnthn Sometimes, it's just another case of "I don't like change/new things"
10:05 brrt hmmm... I find the opposite, really
10:05 masak brrt: "the hidden assumption when asking people to write intentful code is that people have intents" :/
10:05 brrt i mean, most programmers I've met seem to take a code-first viewpoint to fairly extreme lengths
10:05 brrt hehehe, that is true
10:07 jnthn m: for ^10000 { my $a = ("A".."Z").pick x 1000; for ^4 { start { my %h; %h{$a} = 42; } } }
10:07 camelia rakudo-moar ee8ae9: OUTPUT«MoarVM panic: Memory allocation failed; could not allocate 4 bytes␤»
10:08 jnthn aww
10:08 jnthn Anyway, that reliably triggers the thing I'm fixing, so will become my test csae :)
10:08 jnthn (It doesn't with camelia because we ulimit things so far we can't start up a full pool of threads)
10:09 masak dare I run that locally? :)
10:09 masak whoa, segfault!
10:09 jnthn Right :)
10:10 jnthn "Glad" to see my test case works on somebody elses machine too
10:10 masak the happiness is mutual
10:10 timotimo that's not the kind of crash i'd expect from string flattening
10:10 jnthn My $dayjob prototype that works rather nicely occasionally combusts because of this
10:10 jnthn timotimo: gdb it ;)
10:11 nwc10 ASAN does not reward you with full-on technicolor barfage :-/
10:11 nwc10 merely
10:11 nwc10 ==12134==ERROR: AddressSanitizer: attempting double-free on 0x603000730030 in thread T16:
10:11 jnthn Yup
10:11 jnthn The rehash branch is the refactoring to let me fix this in one place
10:11 jnthn So the task now is to fix it
10:11 masak a "double-free" is like Swedes being able to take vacation and sick leave simultaneously, aye? :P
10:11 timotimo fair enough, just totally b0rks the heap
10:13 timotimo jnthn: also make sure you transplant the "if the key is a null string, don't try to asplode" fix from master a few days ago
10:13 timotimo 'cuz we're able to get an actually null pointer in there if we have an uninitialized "str" attribute in a class
10:13 jnthn Ah, maybe I should just rebase this branch on master before continuing
10:14 timotimo not sure that'll help
10:14 nine jnthn: camelia is ulimited to 80 processes and 1 GiB of virtual memory. Shouldn't that be enough?
10:14 jnthn nine: I'd have thought so
10:15 jnthn The default max thread pool size is 16 and they can each carve out up to 8MB of nursery
10:15 timotimo jnthn: actually, i can just put that fix back in when you merge into master
10:15 jnthn Which is only 128MB on top of the Rakudo base memory
10:15 timotimo not a big deal at all
10:15 jnthn So 1GB should really be enough
10:15 camelia joined #moarvm
10:15 jnthn timotimo: bah, then i'll just have a merge conflict later rathe than now :)
10:15 nine m: for ^10000 { my $a = ("A".."Z").pick x 1000; for ^4 { start { my %h; %h{$a} = 42; } } }
10:16 camelia rakudo-moar ee8ae9: OUTPUT«(signal ABRT)*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': double free or corruption (fasttop): 0x0000000004a283a0 ***␤======= Backtrace: =========␤/lib64/libc.so.6(+0x727df)[0x7f9a9f6217df]␤/lib64/libc.so.6(+0x7804e)[0x7f9a9f62704e]␤/lib6…»
10:16 nwc10 and a merge conflict that's obvious in history, instead of one that's tidied away
10:16 jnthn nine++
10:16 nine Seems to be the ulimit indeed. Strange.
10:16 timotimo OK
10:17 nine Though one has to remember that virtual memory does not mean used memory. Could be mmaped files or unused but allocated memory
10:17 timotimo quite.
10:22 jnthn timotimo: I trust you added a test to cover the thing you fixed, so spectest should be enough to be sure my rebase is OK?
10:22 camelia joined #moarvm
10:22 nine m: for ^10000 { my $a = ("A".."Z").pick x 1000; for ^4 { start { my %h; %h{$a} = 42; } } }
10:22 timotimo i didn't because i didn't want to force a version bump, but i can do it now because versions have been bumped in the mean time
10:22 timotimo because it gave us a segfault and i didn't want test files to segfault
10:23 camelia rakudo-moar ee8ae9: OUTPUT«(signal SEGV)»
10:23 timotimo now to find what file it ought to go into ...
10:23 nine That's now with 2 GiB ov virtual memory
10:25 dalek MoarVM/rehash: b687df8 | jnthn++ | src/6model/reprs/MVMHash.h:
10:25 dalek MoarVM/rehash: Remove a couple of now-unused macros.
10:25 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/b687df851d
10:25 dalek MoarVM/rehash: edd3bbf | jnthn++ | src/6model/reprs/MVMHash.h:
10:25 dalek MoarVM/rehash: Remove unused macro parameter.
10:25 jnthn There's the rebase
10:26 dalek joined #moarvm
10:27 timotimo the tests in S32-hash are not really numerous ...
10:27 timotimo and none of the existing files there seems to cover just doing an assignment that can asplode
10:28 timotimo could make a new file in integration/   :\
10:28 timotimo maybe it fits into weird-errors.t?
10:36 jnthn weird-errors.t is getting a bit...unweildy :)
10:37 * timotimo compiles some rakudo to make sure the test actually fails before the moar patch
10:40 timotimo # Failed test 'using a null string to access a hash does not segfault'
10:42 timotimo ok 31 - using a null string to access a hash does not segfault
10:42 timotimo yay
10:42 timotimo the test file is pushed
10:47 jnthn Thanks!
11:02 dalek MoarVM/rehash: 3678acf | jnthn++ | / (2 files):
11:02 dalek MoarVM/rehash: Push MVMString awareness deeper into hash guts.
11:02 dalek MoarVM/rehash:
11:02 dalek MoarVM/rehash: In preparation for eliminating the need for MVM_string_flatten.
11:02 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/3678acfa1e
11:19 timotimo hmm. if we go ahead with making strings storable in int8 codepoint buffers and such, we'll have to make sure these representations are actually unambiguous, right?
11:20 timotimo or does uthash allow us to build a "compare keys" function that can handle multiple different representations?
11:26 timotimo also, when we do implement the "GC synthetic codepoints when the table becomes too big" thing, we might end up having to re-hash all our keys ... well, only if we compact synthetic codepoints rather than just making a free-list
11:28 jnthn Doubt we'll compact
11:28 timotimo that makes it simpler
11:29 jnthn What we'll have by the end of this refactoring will not really be uthash any more, I suspect
11:29 timotimo hehe.
11:34 timotimo maybe when we have a hoard-like allocator we'd be interested in allocating our hash tables with that
11:37 nwc10 jnthn: origin/rehash doesn't change any spectests for me
11:37 nwc10 reward yourself with lunch! :-)
11:39 timotimo looking at my current trajectory and energy levels, i won't get a hoard-like thing into moar before the next release, but this is the last release before we have a big influx of eyes from the advent calendar :|
12:02 dalek MoarVM/rehash: 2410ff3 | jnthn++ | / (3 files):
12:02 dalek MoarVM/rehash: Implement hashing that will not need flattening.
12:02 dalek MoarVM/rehash:
12:02 dalek MoarVM/rehash: We still need it for comparison, which will need fixing up next.
12:02 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/2410ff3988
12:04 timotimo cool
12:04 ggoebel joined #moarvm
12:35 nwc10 jnthn: origin/rehash doesn't change any spectests for me
12:36 brrt what is a hoard allocator?
12:36 timotimo hoard is the name of an allocator that is multithreaded and handles producer-consumer patterns better than others
12:37 timotimo it's based on giving back mostly-empty pages to the shared heap for other threads to take
12:38 jnthn lunch &
12:38 nwc10 jnthn++
12:38 jnthn nwc10: Next patch will be The Big One :)
12:38 timotimo The Big Patch Theory
12:38 nwc10 best eat lunch first then
12:40 brrt jnthn++ cool
12:48 domidumont joined #moarvm
13:01 lizmat is the plan to merge this before or after the release ?
13:14 jnthn Before provided it spectests clean, given how nasty the thing it's fixing is...
13:14 yoleaux2 12:49Z <MasterDuke_> jnthn: do you have any thoughts on my line directive PR https://github.com/rakudo/rakudo/pull/919 and Zoffix's suggestion?
13:16 jnthn Thing with hashes is they're used so widely, if you break something it's likely going to show up rather quickly
13:26 jnthn NQP built/tested fine. Rakudo build in progress :)
13:32 lizmat jnthn++
13:32 lizmat would this make things faster ?
13:33 jnthn Hard to say
13:33 jnthn Though I think I'll be able to get an 8-byte memory reduction per hash key
13:34 jnthn And not having to turn all strings that get hashed into 32-bit wide ones would also save memory
13:34 jnthn And less memory use = better cache use = faster
13:34 jnthn The hash computation itself may be marginally slower
13:34 dalek MoarVM/rehash: 70fa980 | jnthn++ | / (10 files):
13:34 dalek MoarVM/rehash: Use string comparison to compare hash keys.
13:34 dalek MoarVM/rehash:
13:34 dalek MoarVM/rehash: This requires us to store an MVMString * in the key slot of the hash
13:34 dalek MoarVM/rehash: rather than a pointer to memory. That in turn means we need to make
13:34 dalek MoarVM/rehash: sure this pointer is known to the GC, which is what makes up most of
13:34 dalek MoarVM/rehash: this commit.
13:34 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/70fa98025a
13:46 dalek MoarVM/rehash: ad25deb | jnthn++ | 3rdparty/uthash.h:
13:46 dalek MoarVM/rehash: Avoid dupe setting of string hash cache.
13:46 dalek MoarVM/rehash:
13:46 dalek MoarVM/rehash: It's set at the point of computation now.
13:46 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/ad25deb189
13:46 dalek MoarVM/rehash: 9d0a2f2 | jnthn++ | src/6model/reprs/MVMHash.h:
13:46 dalek MoarVM/rehash: Eliminate use of MVM_string_flatten in hashes.
13:46 dalek MoarVM/rehash:
13:46 dalek MoarVM/rehash: Which means strings become truly immutable, resolving a longstanding
13:46 dalek MoarVM/rehash: thread safety bug.
13:46 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/9d0a2f2e03
13:48 jnthn That thing that crashed sub-second reliably has now been running for 5 minutes solid here, no problems :)
13:52 timotimo \o/
14:14 diakopter joined #moarvm
14:16 dalek MoarVM/rehash: 052ea53 | jnthn++ | src/ (5 files):
14:16 dalek MoarVM/rehash: Eliminate duplicate storage of hash key.
14:16 dalek MoarVM/rehash:
14:16 dalek MoarVM/rehash: This shaves a pointer off each entry in an NQP or Perl 6 hash.
14:16 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/052ea53e2a
14:21 dalek MoarVM/rehash: bc6e933 | jnthn++ | src/6model/reprs/MVMHash. (2 files):
14:21 dalek MoarVM/rehash: Missing nullness checking.
14:21 dalek MoarVM/rehash: review: https://github.com/MoarVM/MoarVM/commit/bc6e933a06
14:22 domidumont joined #moarvm
14:27 domidumont joined #moarvm
14:31 jnthn Alrighty, this is looking good, I think
14:35 timotimo i like to hear that
14:35 timotimo so the only thing remaining for using 8 bit per character storage is ... just doing it? :)
14:36 dalek MoarVM: b687df8 | jnthn++ | src/6model/reprs/MVMHash.h:
14:36 dalek MoarVM: Remove a couple of now-unused macros.
14:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b687df851d
14:36 dalek MoarVM: edd3bbf | jnthn++ | src/6model/reprs/MVMHash.h:
14:36 dalek MoarVM: Remove unused macro parameter.
14:36 jnthn timotimo: We already do do it in various cases, I think? :)
14:37 jnthn But yeah, we could do it in more places :)
14:37 timotimo well, i mean ... store it like that forever :)
14:37 dalek joined #moarvm
14:38 timotimo we used to blow it up for the benefit of hashes always
14:38 jnthn We never promote strings from 8-bit to 32-bit in-place now
14:38 timotimo awesome!
14:38 * timotimo cracks fingers :P
14:38 jnthn And I'm about to remove the deprecated flattenropes o
14:38 jnthn *op
14:39 nwc10 you really have got it in for dalek today
14:40 ggoebel joined #moarvm
14:40 jnthn :)
14:41 nwc10 I'm trying to remmeber - after this, how many known concurrency bugs?
14:46 jnthn Well, according to RT, 50ish :P
14:46 jnthn Though it's possible some of them boil down to what I just fixed
14:46 jnthn And that others share root causes
14:46 nwc10 Oh OK. How many known distinct causes
14:47 nwc10 (Yes, what I was typing)
14:47 nwc10 what next? well earned beer?
14:47 jnthn No, there's still more things needing attention :P
14:47 nwc10 are you sure that you have your priorities right here? :-)
14:48 jnthn Tomorrow is a national holiday, so plenty of time for beer then :)
14:48 nwc10 sounds terrible
14:49 jnthn Struggle for freedom and democracy day
14:50 jnthn Or, from the news I read this morning, struggling to find enough police to cope with the 30 different marches people have planned :P
14:52 brrt well, that is freedom, innit
14:52 jnthn 'tis fair enough, provided they don't make trouble, yes.
14:53 jnthn Hopefully the group that decided to fake an IS invasion of the old town square earlier this year will stay home :P
14:55 dalek MoarVM: 1dc68e5 | jnthn++ | / (7 files):
14:55 dalek MoarVM: Remove the deprecated flattenropes op.
14:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1dc68e5eb5
14:55 dalek MoarVM: 9d5c874 | jnthn++ | src/strings/ops. (2 files):
14:55 dalek MoarVM: Remove now-unused MVM_string_flatten function.
14:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9d5c874add
14:57 jnthn Well, that hopefully rounds off that task.
15:06 brrt does that mean that strings are now always flat?
15:08 jnthn brrt: No
15:09 jnthn It means that we don't have to make them flat in order to hash them
15:11 domidumont joined #moarvm
15:12 timotimo brrt: we can re-use the mmapped string heap for a certain subset of our strings now!
15:13 timotimo well, we could have already done that before, i suppose
15:13 timotimo but now we won't need to immediately turn it into 32bit wide thingies as soon as they hit a hash
15:17 jnthn Um
15:17 jnthn Remember that compunits are GC-able
15:19 travis-ci joined #moarvm
15:19 travis-ci MoarVM build failed. Jonathan Worthington 'Missing nullness checking.'
15:19 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/176390873 https://github.com/MoarVM/MoarVM/compare/20c8591ad764...bc6e933a0688
15:19 travis-ci left #moarvm
15:20 domidumont joined #moarvm
15:24 jnthn wtf...
15:26 [Coke] looks like all mac failures.
15:26 [Coke] I'll try a build.
15:30 jnthn May just be a timing issue
15:32 [Coke] Looking at the output, yah, maybe it got an nqp that didn't get the bump.
15:33 [Coke] so far seems fine locally; also kicked off a rebuild of one of those failed subtasks.
15:33 timotimo jnthn: but don't the compunits hold the strings they own in a table?
15:34 timotimo jnthn: seems like if the compunit gets thrown out, i can go through the already-decoded strings and give them their own memory to hold their string data in
15:38 * timotimo looks at the actual code rather than rely on memory and guesswork
15:41 dalek MoarVM: 20e968b | jnthn++ | src/io/ (2 files):
15:41 dalek MoarVM: An nread of 0 is not an error.
15:41 dalek MoarVM:
15:41 dalek MoarVM: And very occasionally happens. Just treat it as an empty buffer of
15:41 dalek MoarVM: incoming data.
15:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/20e968be78
15:51 FROGGS joined #moarvm
15:51 FROGGS o/
15:59 jnthn o/ FROGGS
16:10 nwc10 if we all go o/ will the channel capsize?
16:10 nwc10 (I think I asked this before, didn't I?)
16:10 jnthn It's the channel, not the boat on the channel :P
16:11 * FROGGS actually lives quite near a channel
16:12 FROGGS nwc10: btw, are you sad if I try to get all our Perl 5 scripts work on 5.8.8?
16:13 nwc10 I think I'm actually happy
16:14 nwc10 because it seems to make sense to remove a small barrier to entry
16:14 FROGGS aye
16:14 nwc10 you could go for 5.8.5, although I'm told that the CentOS that ships that is about to fall off the end of the support conveyor belt
16:14 nwc10 5.8.8 is the next logical one
16:14 FROGGS I see
16:15 FROGGS it just happens that the AIX box I'm working with has 5.8.8
16:15 nwc10 5.8.8 is probably the best trade off
16:15 nwc10 and xlc? :-)
16:15 FROGGS no :o)
16:15 FROGGS gcc
16:15 brrt aha, okay
16:15 brrt (late response, of course)
16:15 brrt are strings going to be flat at all?
16:15 FROGGS xlc is discontinued it seems
16:16 nwc10 oh, boring
16:16 timotimo brrt: why not?
16:16 nwc10 it had all the best pedanticism
16:16 brrt or rather, how hard is string-character lookup going to be in the future
16:16 FROGGS nwc10: aix is still weird about linking...
16:16 nwc10 if your code worked on xlc, it had a fighting chance of working pretty much anywhere
16:16 timotimo we ought to always go through the grapheme iterator codepath
16:16 nwc10 (At least, on any OS still currently shipping)
16:17 nwc10 the DEC compiler seems to have been awkward, but I never really got to meet it
16:17 * brrt wonders how hard it is to support 5.8.8 for the tile template generator
16:17 brrt my question is really, how hard would it be to specially JIT that codepath?
16:17 brrt if you consider that loops are already kind of tricky
16:18 FROGGS brrt: we most likely dont hit that path I guess
16:18 brrt the grapheme iterator path i mean
16:18 * FROGGS is talking about a platform with an ancient perl where we implement the jit
16:23 brrt aha :-)
16:23 brrt my mistake for trying to engage two conversations at once
16:25 timotimo brrt: since strings are now properly read-only, we can have a fast path for flat strings up front, or alternatively just ask for a flattened string up front and then plough through a compact flat string in jitted code
16:30 brrt hmm
16:31 brrt okay, that is pretty cool
16:33 domidumont joined #moarvm
16:33 jnthn Note taht we can keep a spesh fact for "this string was flat" in regex code
16:34 jnthn Since we can spot uses of the indexingoptimized op
16:34 brrt hmm.... that would be decenlty useful
16:35 brrt anyway, how far are we along with having branching guards....
16:38 timotimo huh
16:38 timotimo i tried changing decoding latin1 to using MVM_grapheme_8 - though it probably should be ASCII instead if it doesn't have newlines in it? - but there's things that are beyond 127
16:39 timotimo 171, 187, 160, and 162
16:39 timotimo m: say .&uniname for (160, 162, 171, 187)
16:39 camelia rakudo-moar 395f36: OUTPUT«NO-BREAK SPACE␤CENT SIGN␤LEFT-POINTING DOUBLE ANGLE QUOTATION MARK␤RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK␤»
16:39 timotimo i'm only surprised by the no-break space there
16:39 timotimo the cent sign is probably $¢
16:39 timotimo and the double angle quotation is also quite unsurprising
16:40 timotimo so i suppose that's fine. i'll put in a fallback to turn it into a 32bit grapheme storage thing when something's found that's outside 0..127
16:40 timotimo in theory, if there hasn't yet been a newline, we could use an ASCII stored string instead, since that allows us to use 0..255
16:41 timotimo actually, ASCII storage should also only allow 0..127
16:42 jnthn latin-1 goes up to 255
16:45 timotimo right, but the _8 storage is signed, so it's not useful for all of latin1
16:45 timotimo could not resolve lexical ꈤ翝
16:45 timotimo fantastic %)
16:46 timotimo ok, compiling rakudo now
16:51 travis-ci joined #moarvm
16:51 travis-ci MoarVM build failed. Jonathan Worthington 'Missing nullness checking.'
16:51 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/176390873 https://github.com/MoarVM/MoarVM/compare/20c8591ad764...bc6e933a0688
16:51 travis-ci left #moarvm
16:53 timotimo Found /tmp/moar/bin/moar version 2016.10-69-gbc6e933, which is too old.
16:53 timotimo ^- at least one of the mac builds failed like this
16:54 timotimo all mac builds failed like that
16:55 jnthn I think that the jobs were in the Travis queue for a bit, and then pulled NQP after it got a version bump
16:56 timotimo ah. could very well be
17:00 timotimo seems like a repl test is now hanging
17:01 timotimo oh, all the failing tests up until then were in perl5-integration
17:02 timotimo which could just be from Inline::Perl5 being too old or something
17:02 timotimo ah, i had a debug printf still in there
17:03 travis-ci joined #moarvm
17:03 travis-ci MoarVM build failed. Jonathan Worthington 'Remove the deprecated flattenropes op.'
17:03 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/176395412 https://github.com/MoarVM/MoarVM/compare/bc6e933a0688...1dc68e5eb5d1
17:03 travis-ci left #moarvm
17:03 timotimo but it still hangs :|
17:13 domidumont joined #moarvm
18:24 dalek MoarVM/libatomic_ops-update: 6521f58 | FROGGS++ | 3rdparty/libatomic_ops/ (88 files):
18:24 dalek MoarVM/libatomic_ops-update: remove executable flag where not needed
18:24 dalek MoarVM/libatomic_ops-update: review: https://github.com/MoarVM/MoarVM/commit/6521f58960
18:37 dalek MoarVM/libatomic_ops-update: 562c9dc | FROGGS++ | 3rdparty/libatomic_ops/configure.ac:
18:37 dalek MoarVM/libatomic_ops-update: remove executable flag where not needed
18:37 dalek MoarVM/libatomic_ops-update: review: https://github.com/MoarVM/MoarVM/commit/562c9dcd03
18:45 lizmat jnthn: could it be that there is a subtle difference in the way nqp::atpos works between shaped and unshaped arrays ?
18:46 lizmat aka, one is deconting and the other isnt?
18:51 dalek MoarVM/libatomic_ops-update: 6b7c1f7 | FROGGS++ | 3rdparty/libatomic_ops/src/atomic_ops_ (4 files):
18:51 dalek MoarVM/libatomic_ops-update: add midding files
18:51 dalek MoarVM/libatomic_ops-update: review: https://github.com/MoarVM/MoarVM/commit/6b7c1f75d6
19:00 lizmat jnthn: not so good news: HARNESS_TYPE=6 make spectest still not error free (segfault around S11)
19:03 lizmat https://gist.github.com/lizmat/916dd334cce318b3ae0594afbe537214   # problem with nqp::atpos / shaped arrays
19:04 lizmat afk to see some fantastic beasts&
19:41 domidumont joined #moarvm
19:55 dalek Heuristic branch merge: pushed 97 commits to MoarVM/libatomic_ops-update by FROGGS
20:06 dalek Heuristic branch merge: pushed 100 commits to MoarVM by FROGGS
20:06 FROGGS \m/
20:07 timotimo we gots a new libatomic_ops now?
20:10 FROGGS aye
20:15 timotimo cool
20:15 timotimo i wonder if we should grab newest libuv, too
20:23 dalek MoarVM/wip_aix: f7b1529 | FROGGS++ | / (6 files):
20:23 dalek MoarVM/wip_aix: add all changes that are needed for aix
20:23 dalek MoarVM/wip_aix:
20:23 dalek MoarVM/wip_aix: I will clean that up later, as well as splitting up this patch
20:23 dalek MoarVM/wip_aix: into smaller bits.
20:23 dalek MoarVM/wip_aix: review: https://github.com/MoarVM/MoarVM/commit/f7b1529069
20:23 FROGGS timotimo: since there are no issues with libuv from debian unstable and testing, I'd say yes
20:24 FROGGS to all (probably 0) aix users here: that aix branch just works if you have libffi on your box
20:26 timotimo \o/
20:32 * timotimo teaches utf8 decoder to use 8 bit per char if possible
20:34 FROGGS gnight
20:36 stmuk_ watching interp.c compile on an old clang is about as interesting as watching paint dry
20:36 ggoebel joined #moarvm
20:36 timotimo yeah, that's about right
20:42 timotimo boo!!!    graphemes between   58 and  8745.
20:42 timotimo infix:sym<)>
20:42 timotimo o_O
20:42 timotimo m: say uniname(8745)
20:42 camelia rakudo-moar 58a482: OUTPUT«INTERSECTION␤»
20:44 timotimo i'm not sure i understand what's going on there
20:44 timotimo well, for one i'm not outputting valid utf8 to see what the thing is
20:44 timotimo so my console gets confused. fair enough
20:45 timotimo ok, these are our magical set operators and such
20:45 timotimo so "intersectin" was right all along %)
20:48 timotimo i mean ... we could still save some space if we introduce a 16bit storage category, but we might not want that
21:15 jnthn lizmat: Don't think it can be that simple; decont is a property of an op rather (stricly, the compilation of an op) rather than the REPR beneath it
22:09 travis-ci joined #moarvm
22:09 travis-ci MoarVM build errored. Jonathan Worthington 'An nread of 0 is not an error.
22:09 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/176412130 https://github.com/MoarVM/MoarVM/compare/9d5c874add5b...20e968be784b
22:09 travis-ci left #moarvm

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