Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-07

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

All times shown according to UTC.

Time Nick Message
00:00 timotimo does libuv do anything afterwards with bufs?
00:00 timotimo oh
00:00 timotimo there's a const in our function signature
00:00 timotimo you can probably drop that
00:01 timotimo alternatively put the pointer into our res_buf and then realloc it from there
00:01 timotimo i ... don't know why we'd get a run-time error from that
00:02 MasterDuke sorry, that was a compile error
00:02 MasterDuke but it worked with the changes i showed
00:03 timotimo huh, somehow i missed that line
00:03 timotimo more evidence that i should be going to sleep
00:41 markmont joined #moarvm
00:46 MasterDuke A suggested size (65536 at the moment in most cases) is provided, but it’s just an indication, not related in any way to the pending data to be read. The user is free to allocate the amount of memory they decide.  As an example, applications with custom allocation schemes such as using freelists, allocation pools or slab based allocators may decide to use a different size which matches the memory chunks they already have.
00:46 MasterDuke from the libuv docs for on_alloc
00:47 MasterDuke could we somehow use the FSA for those buffers?
00:48 timotimo we could, but vmarray objects expect to be able to MVM_free their pointers
00:48 timotimo we'd have to figure something out for that
00:52 MasterDuke i just hard-coded the on_alloc value to 8192 instead of using suggested_size, not a huge difference: 1242396maxresident)k
00:52 timotimo huh
00:54 MasterDuke oh, only 516mb were from on_alloc, and that did go down to 69mb
00:55 MasterDuke it's MVM_gc_collect that's doing 1.9gb, then down to 1.7gb
00:58 MasterDuke where are those defined?
01:39 MasterDuke oh, you can't use the FSA, because the signature of on_alloc is fixed and so it doesn't have a tc in it
01:40 MasterDuke here's someone with a similar question/problem in Python: https://groups.google.com/forum/#!topic/libuv/oQO1HJAIDdA
01:51 ilbot3 joined #moarvm
01:51 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:30 pharv joined #moarvm
04:22 yoleaux joined #moarvm
05:30 lizmat joined #moarvm
05:52 brrt joined #moarvm
06:23 brrt joined #moarvm
06:38 Geth ¦ MoarVM/even-moar-jit: 74d906b4b6 | (Bart Wiegmans)++ | 3 files
06:38 Geth ¦ MoarVM/even-moar-jit: Compile less with --no-jit
06:38 Geth ¦ MoarVM/even-moar-jit:
06:38 Geth ¦ MoarVM/even-moar-jit: We tried to compile all sorts of internal stuff even if we didn't
06:38 Geth ¦ MoarVM/even-moar-jit: have JTI support configured, and 'stub' had to emulate all sorts
06:38 Geth ¦ MoarVM/even-moar-jit: of internal routines. That's not necessary now; now the stub only
06:38 Geth ¦ MoarVM/even-moar-jit: provides a 'public' API, and does not rely on internal structures.
06:38 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/74d906b4b6
06:46 lizmat joined #moarvm
06:55 brrt joined #moarvm
07:04 brrt good hi, #moarvm
07:15 Ven joined #moarvm
07:36 yoleaux joined #moarvm
07:57 zakharyas joined #moarvm
08:31 edehont joined #moarvm
08:36 robertle joined #moarvm
08:37 edehont joined #moarvm
08:50 jnthn morning o/
08:53 brrt \o jnthn
09:01 Ven joined #moarvm
09:21 Ven_ joined #moarvm
09:45 jnthn brrt: if_o and unless_o aren't marked :invokish, even though they really do invoke
09:45 jnthn brrt: I'm considering using invokish/throwish as basic block terminators
09:46 jnthn Can you think of any problem I'll have if I mark if_o and unless_o with :invokish?
09:46 jnthn I'm wondering if there's a reason they are left out.
09:52 jnthn Ditto for:
09:52 jnthn loadbytecode
09:52 jnthn masttocu
09:52 jnthn continuationinvoke
09:52 jnthn parameterizetype
09:52 jnthn loadbytecdoebuffer
09:52 jnthn loadbytecodefh
10:00 brrt ehm, the main reason is that i translate if_o and unless_o to istrue_o and if_i/unless_i, so i don't need them to be invokish
10:00 brrt and the others i just haven't looked at
10:01 jnthn But if I mark them that way because i use these annotations as basic block terminators, I'm not going to upset the JIT?
10:01 brrt not 100% positive, but if you did, it would be easily mitigated
10:01 jnthn NQP build/test seems happy with me doing so
10:01 jnthn (with blocking/nodelay)
10:02 jnthn Doing a Rakudo build/test to see what it thinks :)
10:02 brrt odds are good the JIT doesn't mind, then
10:02 jnthn Didn't change the BB splits yet, just added the annotations.
10:04 brrt thanks for the review comments btw :-)
10:04 jnthn Yeah, I didn't get all the way through it yet :)
10:05 jnthn Will try and continue later on today :)
10:05 brrt yeah, i figured :-) thanks
10:05 brrt btw, i since resolved the —no-jit issue
10:06 brrt part of the rest of travis's complaining revolves around the use of package foo {..} syntax
10:06 brrt which that version of perl does not support
10:06 jnthn ah, ok
10:09 jnthn Yeah, looks like no bad effects
10:09 Geth ¦ MoarVM: 8f70da7674 | (Jonathan Worthington)++ | 2 files
10:09 Geth ¦ MoarVM: Mark further ops as :invokish.
10:09 Geth ¦ MoarVM:
10:09 Geth ¦ MoarVM: To get a more accurate set of ops that might invoke.
10:09 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8f70da7674
10:13 jnthn Well, we sure get more basic blocks when I start splitting at throwish/invokish :)
10:13 jnthn But not more PHIs, which is what I'd expect
10:13 jnthn e.g. there's no increase in join points
10:20 jnthn Some failures from the additional splitting though
10:21 brrt hmmm
10:21 jnthn MoarVM oops: Spesh: failed to fix up handlers (-1, 138, 138)
10:21 jnthn Hmm
10:22 jnthn At least a couple of those
10:22 jnthn a SEGV inside of spesh
10:23 jnthn And a second one in another place
10:24 jnthn OK, so three distinct failure modes
10:24 jnthn Quite possibly all of which will turn out to be long-standing issues that we just never hit before...let's see
10:33 jnthn oh goodness
10:33 jnthn The crashes are because we end up with more basic blocks now, and optimize_bb recurses
10:33 jnthn We actually blow the C stack
10:33 brrt lol
10:34 jnthn haha
10:35 jnthn It happens in the mainline of https://github.com/perl6/roast/blob/master/S15-normalization/nfc-concat.t
10:35 jnthn Which we only try to optimize at all because of NODELAY
10:36 jnthn That now ends up with 51,000 basic blocks
10:36 jnthn And since it's all linear code, the dominance tree will also be a straight line :P
10:38 brrt ouch
10:38 jnthn Yeah.
10:38 jnthn So this only happens because of NODELAY
10:38 jnthn We'd never attempt to optimize that code in any normal conditions
10:39 jnthn But for the sake of being robust, I think I'll just stick in an upper limit on bytecode size or some such
10:45 nwc10 until someone (else) refactors optimize_bb not to recurse (and it's no less complex than the current implementaiton)
10:48 jnthn Even then, an upper limit is probably still wise
10:48 jnthn The algorithms we're using aren't all O(n)
10:49 Geth ¦ MoarVM: 7eb021fc60 | (Jonathan Worthington)++ | 2 files
10:49 Geth ¦ MoarVM: Put hard upper limit on bytecode size to optimize.
10:49 Geth ¦ MoarVM:
10:49 Geth ¦ MoarVM: To avoid ending up with gigantic, stack-blowing CFGs and dominance
10:49 Geth ¦ MoarVM: trees. We can tweak this limit as needed, but 64KB of bytecode seems
10:49 Geth ¦ MoarVM: quite substantial.
10:49 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7eb021fc60
10:50 jnthn It substantial enough that we never hit it during CORE.setting compilation
10:50 jnthn And I know we've some sizable rules/tokens and methods in that
11:04 Geth ¦ MoarVM: 65bdc2f56a | (Jonathan Worthington)++ | src/spesh/manipulate.c
11:04 Geth ¦ MoarVM: Move annotations multiple basic blocks if needed.
11:04 Geth ¦ MoarVM:
11:04 Geth ¦ MoarVM: Sometimes the next or previous basic block won't have an instruction
11:04 Geth ¦ MoarVM: to move the annotation to. So, search until we find one.
11:04 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/65bdc2f56a
11:06 jnthn With that, my patch to split in invokish/throwish is OK even with blocking+nodelay
11:07 jnthn But oddly it seems to cause the number of inlined frames in that lines benchmark to drop? o.O
11:08 jnthn Yup, it's exactly that change that does it. Darn.
11:18 jnthn oh, I see
11:29 Geth ¦ MoarVM: 75f9ac37ed | (Jonathan Worthington)++ | 3 files
11:29 Geth ¦ MoarVM: Eliminate "blocked by alias" propagation checks.
11:29 Geth ¦ MoarVM:
11:29 Geth ¦ MoarVM: We explicitly guard decont now, and so cannot run into these kinds of
11:29 Geth ¦ MoarVM: issues any more (and the guards that looked into containers are gone
11:29 Geth ¦ MoarVM: also). We will do some alias analysis in the future to remove some of
11:29 Geth ¦ MoarVM: the guards when we can prove they aren't needed. But we are now safe
11:29 Geth ¦ MoarVM: by default, without needing a check like this.
11:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/75f9ac37ed
11:31 edehont joined #moarvm
11:31 Geth ¦ MoarVM: 4ce52ef48f | (Jonathan Worthington)++ | src/spesh/graph.c
11:31 Geth ¦ MoarVM: End basic blocks after all throwish/invokish.
11:31 Geth ¦ MoarVM:
11:31 Geth ¦ MoarVM: This is a bit more honest, and also paves the way for trying to put in
11:31 Geth ¦ MoarVM: more accurate edges for control exception handlers.
11:31 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ce52ef48f
11:31 jnthn lunch &
11:32 jnthn Oh, also it's possbile that 65bdc2f will have fixed https://github.com/MoarVM/MoarVM/issues/629
11:33 lizmat joined #moarvm
12:07 colomon joined #moarvm
12:16 * jnthn back
12:16 brrt ohai
12:17 jnthn o/ brrt
12:18 jnthn So, let's see if I can figure out this exception handler thingy
12:19 brrt which exception handler thingy is that?
12:20 jnthn The one where instead of anchoring control exception handlers from the root of the graph, we instead link them from all basic blocks within the handler region
12:20 jnthn Just going to do it for control exceptions for now
12:20 dogbert17 ./perl6 -e 'my $a; for ^100_000 { $a = $_.comb.sort.uniq }; say $a'
12:21 dogbert17 No such method 'uniq' for invocant of type 'Seq'. Did you mean 'unique'?
12:25 jnthn What if you MVM_SPESH_BLOCKING=1 and MVM_SPESH_NODELAY=1 on it?
12:26 brrt (i have no idea what that actually means though)
12:26 colomon joined #moarvm
12:30 zakharyas joined #moarvm
12:31 colomon joined #moarvm
12:32 jnthn brrt: The end goal is that we get more precise dominance frontiers, so less PHIs joining things from the entry point, where we know nothing.
12:32 dogbert17 jnthn: both works
12:32 jnthn dogbert17: yay :)
12:34 dogbert17 jnthn++ bug swatter :)
12:38 Geth ¦ MoarVM/even-moar-jit: 94f55f927d | (Bart Wiegmans)++ | tools/tiler-table-generator.pl
12:38 Geth ¦ MoarVM/even-moar-jit: Use fewer 'new' perl features
12:38 Geth ¦ MoarVM/even-moar-jit:
12:38 Geth ¦ MoarVM/even-moar-jit: Travis CI tells me it trips over package + block syntax, and apparently
12:38 Geth ¦ MoarVM/even-moar-jit: also over the /r modifier for substituting regular expressions; we can
12:38 Geth ¦ MoarVM/even-moar-jit: also do without.
12:38 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/94f55f927d
12:39 brrt lets see if travis Ci agrees with that
12:42 brrt re: the whole stack-spilling-vs-anywhere else discussion, I do believe some CPU's 'optimize' stack-relative access to registers
12:43 brrt or at least, i've heard tell
12:44 brrt the problem with that is that either you now allocate everything from stack, or, you point your stack to your heap-allocated frame - nothing wrong with that, until you start calling other C functions, which expect the stack to be the stack
13:04 lizmat_ joined #moarvm
13:07 brrt travis is happy!
13:18 jnthn yay :)
13:26 samcv grant status update 3 is up https://cry.nu/perl6/grant-status-update-3/
13:31 brrt sancv++
13:31 brrt sorry samcv++
13:34 JimmyZ samcv: s/3.5%/3.5x/ maybe?
13:34 samcv JimmyZ, nice catch heh
13:37 JimmyZ samcv: do you mean won't make it more compact which you planed?
13:43 samcv compact?
13:43 timotimo samcv: "add to nqp::codes op to"? :)
13:43 timotimo "in stthe string"? :)
13:44 samcv i think i hit my keyboard in a few places
13:45 samcv since that wasn't there the last time i read through it :P
13:46 samcv should be fixed now
13:46 timotimo i usually hit my keyboard all over the place :D
13:47 JimmyZ samcv: reduce the  unicode data  size
13:47 samcv ah
13:47 samcv yeah it might not happen. we will see
13:47 JimmyZ that's a sad ,haha
13:48 samcv i still am planning to do it though
13:49 timotimo it'll be partially my fault if it doesn't happen :|
13:50 samcv well hm we could do the name space savings. and i leave the rest of the unicode database
13:50 samcv that is workable
13:50 samcv since i remember it being substantial, the savings
13:55 JimmyZ any a bit improvement is good :)
13:59 samcv but it was like 1.5MB-> like 350KB with the string compression i had experimented with. so that's pretty nice
14:06 Geth ¦ MoarVM: 6c02672c95 | (Jonathan Worthington)++ | src/spesh/candidate.c
14:06 Geth ¦ MoarVM: Extra fflush so spesh log is written before crash.
14:06 Geth ¦ MoarVM:
14:06 Geth ¦ MoarVM: So we have the data to look at if the next step goes bad.
14:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6c02672c95
14:06 Geth ¦ MoarVM: bd6d9222cd | (Jonathan Worthington)++ | src/spesh/graph.c
14:06 Geth ¦ MoarVM: Ensure frame handler start/ends are BB boundaries.
14:06 Geth ¦ MoarVM:
14:06 Geth ¦ MoarVM: This will almost always have been the case anyway, but this means we
14:06 Geth ¦ MoarVM: can rely on it.
14:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bd6d9222cd
14:07 jnthn So there's good news and bad
14:07 jnthn The good is that I seem to have got a working change that gets a more accurate CFG for control exceptions.
14:07 brrt the bad is?
14:09 jnthn That because an osrpoint is linked from the entry block also, we still have a PHI r7(0)
14:09 lizmat joined #moarvm
14:11 timotimo oof
14:11 jnthn And that edge is there because when we jump into the optimized code, we don't actually know what holds.
14:11 jnthn Which is a safe solution
14:11 jnthn But, uh... :)
14:17 jnthn ah crap, and my patch doesn't actually quite work :/
14:36 jnthn Oh no, it just uncovers something else...
14:37 timotimo doesn't it always :|
14:37 jnthn We now can end up discovering more things as being unreachable
14:38 jnthn That it's not quite clear why we don't kill them off when doing BB elimination in optimize.c
14:38 jnthn And so they survive until graph.c
14:38 jnthn Uh, that is, they are parsed again but this time as an inlinee
14:42 jnthn It looks like we're somehow optimizing out a conditonal
14:43 jnthn But the body that becomes unreachable doesn't go away
14:50 jnthn Bah, it's 'cus spesh is smarter than I am :P
14:50 jnthn Or something like that :)
14:51 jnthn So there's an osrpoint instruction
14:51 jnthn Which is removed
14:51 jnthn But the basic block is alive and referenced from the entry point because it used to be there
14:51 jnthn This is all fine
14:52 jnthn So then we turn it into bytecdoe etc.
14:52 jnthn So inline makes a graph of this
14:52 jnthn But because the osrpoint is done it correctly doesn't insert the edge from the entry point
14:52 jnthn This is totally correct because there's no way we'll ever OSR into an inline
14:52 jnthn But know this makes more code dead
14:52 jnthn Which in turn means handlers get whipped out
14:53 jnthn *Bu tnow
14:53 jnthn But we don't mark them up as such on this code path, and thus why we get fixup errors
14:54 jnthn The final result of the inlining, if we did succeed in code-gen, is a goto shorter thanks to all of this.
14:55 jnthn .oO( why did nobody tell me building optimizers is hard? :P )
14:58 Geth ¦ MoarVM: 6e438edf67 | (Jonathan Worthington)++ | src/spesh/dump.c
14:58 Geth ¦ MoarVM: Don't explode on spesh dump when no facts.
14:58 Geth ¦ MoarVM:
14:58 Geth ¦ MoarVM: We may dump at this point when things go wrong, such as in the
14:58 Geth ¦ MoarVM: reverse post-order calculation.
14:58 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6e438edf67
14:59 japhb jnthn: Because some things you have to learn by doing?  ;-)
15:03 lizmat joined #moarvm
15:13 brrt joined #moarvm
15:24 Geth ¦ MoarVM: 693c5e3574 | (Jonathan Worthington)++ | src/spesh/manipulate.c
15:24 Geth ¦ MoarVM: Add descriptions to various functions.
15:24 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/693c5e3574
15:24 Geth ¦ MoarVM: 9b4bde5403 | (Jonathan Worthington)++ | src/spesh/inline.c
15:24 Geth ¦ MoarVM: Cope with extra successors when inlining.
15:24 Geth ¦ MoarVM:
15:24 Geth ¦ MoarVM: Once we start inserting extra successors due to the presence of
15:24 Geth ¦ MoarVM: control exceptions, this will be needed.
15:24 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9b4bde5403
15:25 jnthn To be fair, many of the correct-but-not-precise things I put in genuinely did allow dealing with tricky things to be put off until there was time to do that.
15:25 jnthn And let us have the benefit in the meantime.
15:28 Geth ¦ MoarVM: 35f82730a4 | (Jonathan Worthington)++ | 6 files
15:28 Geth ¦ MoarVM: Factor our and re-use dead BB elimination.
15:28 Geth ¦ MoarVM:
15:28 Geth ¦ MoarVM: The version in optimize was more complete and more correct than the
15:28 Geth ¦ MoarVM: one in graph. This unifies them, using a flag to convey the one small
15:28 Geth ¦ MoarVM: difference that needs to be taken into account.
15:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/35f82730a4
15:28 Geth ¦ MoarVM: 39dbe1bd77 | (Jonathan Worthington)++ | src/spesh/dead_bb_elimination.c
15:28 Geth ¦ MoarVM: Allow for GOTO handler to become unreachable.
15:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/39dbe1bd77
15:28 japhb The bill always comes due, or so they say.  Still, as you say, nice the have the benefit in the meantime.
15:29 japhb *to have
15:29 * [Coke] wonders if japhb has just recently watched Doctor Strange.
15:30 japhb I've watched it a couple times.  Not terribly recently though.
15:33 lizmat joined #moarvm
15:37 samcv eater wanted to add unix sockets to moar what has our work been so far with that?
15:37 Geth ¦ MoarVM: 0fe5cd606c | (Jonathan Worthington)++ | src/spesh/graph.c
15:37 Geth ¦ MoarVM: More precise CFGs for control exception handlers.
15:37 Geth ¦ MoarVM:
15:37 Geth ¦ MoarVM: Prior to this, they were always linked from the entry block. This
15:37 Geth ¦ MoarVM: meant that:
15:37 Geth ¦ MoarVM:
15:37 Geth ¦ MoarVM: 1) PHI nodes were always inserted at the start of a handler, and the
15:37 Geth ¦ MoarVM:    join always included the entry point. Since this has an empty set
15:37 Geth ¦ MoarVM: <…commit message has 12 more lines…>
15:37 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0fe5cd606c
15:37 jnthn Phew
15:38 jnthn samcv: We don't support that in Moar yet, but it should be a case of patching asyncsocket.c
15:38 [Coke] japhb: I just rewatched last night, so that stood out to me as one of mordo's lines.
15:38 samcv yeah i know we don't support it yet. will let him know about that. thanks
15:39 jnthn Will also need some kind of API design choice up at Perl 6 level, but that's the easy part once we get it working :)
15:39 jnthn Well, except for bikeshedding :)
15:40 samcv eater is making some init system in perl6 i believe
15:40 jnthn Man, didn't expect to spend all day on that CFG thing
15:40 jnthn But worth it
15:41 samcv https://github.com/the-eater/shinit
15:42 jnthn The OSR point thing is tricky though...hmm
15:45 jnthn What we really want is a way to get the set of guards that we should ensure are upheld in order to enter the code at the OSR point
15:45 * ilmari giggles childishly at "already_succs"
15:45 jnthn ;)
15:48 lizmat joined #moarvm
15:55 samcv o/ lizmat
15:55 lizmat samcv o/
15:56 lizmat so, your presentations are ready ?   :-)
15:56 jnthn I *think* that if, after doing the opts, we walk the dominance tree...
15:56 jnthn And note each guard that we encounter
15:56 jnthn Disregard those that guard an already-changed register
15:57 jnthn Uh, I mean, if there's two guards on the same register, we take the latter
15:57 jnthn Then we should end up with an *over-estimate* of the set of guards that would be in place at that point
15:58 jnthn The reason being that the dominance tree indicates code paths we always have taken to reach this point
15:59 jnthn It's an overestimate becuase we may never rely on the guards again from that point on
15:59 jnthn I just worry if there's a way for it to be an underestimate...
15:59 samcv lizmat, yeah. just gotta practice a little bit more
16:00 samcv and got my grant report done today as well-
16:01 zakharyas joined #moarvm
16:02 lizmat yeah, it will be in the weekly!
16:06 jnthn Ah, yeah, I guess the problem is that there may have been guards in two branches and then a join point, and the osrpoint would be in the join
16:06 Ven joined #moarvm
16:07 jnthn while blah() { if foo() { ...guard 1... } else { ...guard 2 ... }; osrpoint; ...blah... }
16:07 jnthn Then (if this code structure could happen) we'd have a merge of the facts from guard 1 and guard 2 by osrpoint
16:08 jnthn But those branches don't dominate the BB where the osrpoint is
16:08 jnthn So no, it can't be so simple as I suggested after all.
16:09 robertle joined #moarvm
16:14 Ven_ joined #moarvm
16:17 jnthn Guess I'll ponder that this evening :)
16:17 jnthn afk for a bit
16:28 dogbert11 joined #moarvm
16:45 lizmat joined #moarvm
17:13 Ven joined #moarvm
17:17 edehont joined #moarvm
17:44 Ven_ joined #moarvm
18:15 Ven joined #moarvm
18:28 geekosaur joined #moarvm
19:04 brrt joined #moarvm
19:06 brrt good * #moarvm
19:06 timotimo good
19:07 brrt timotimo: will you be coming to TPC?
19:07 timotimo nope :(
19:07 brrt aw, too bad
19:07 brrt i thik we've never met in person, have we
19:10 timotimo not yet, no
19:11 timotimo hrmpf. i'm late for grocery shopping and we haven't decided what to cook yet
19:19 Geth ¦ MoarVM: 127fa2ce73 | (Samantha McVey)++ | 8 files
19:19 Geth ¦ MoarVM: Add indexim_s op and improve/fix bugs in eqatim_s
19:19 Geth ¦ MoarVM:
19:19 Geth ¦ MoarVM: eqatim_s used to only check that the first codepoints of string a and b
19:19 Geth ¦ MoarVM: were the same using MVM_string_ord_basechar_at. The
19:19 Geth ¦ MoarVM: MVM_string_equal_at_ignore_mark function was added and we now use this
19:19 Geth ¦ MoarVM: instead for the eqatim_s op which fixes the bug when it would say the
19:19 Geth ¦ MoarVM: two strings were eqat when only one codepoint was.
19:19 Geth ¦ MoarVM:
19:19 Geth ¦ MoarVM: MVM_string_index_ignore_mark was also added, which is accessible as the indexim_s
19:19 Geth ¦ MoarVM: op.
19:19 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/127fa2ce73
19:35 edehont joined #moarvm
19:38 samcv ok so i found a bug in nqp::ordbaseat. it just returns the base character if it happens to be a synthetic — but it can be a base character which still decomposes
19:38 samcv m: use nqp; dd nqp::ordbaseat("\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]", 0).uniname
19:38 camelia rakudo-moar 46ef1b: OUTPUT: «"LATIN SMALL LETTER J WITH CARON"?»
19:38 samcv when it should be J
19:39 samcv i guess it just assumed that would be the case, but it's a bad assumption to make. so will make that change
19:39 brrt joined #moarvm
19:44 travis-ci joined #moarvm
19:44 travis-ci MoarVM build errored. Samantha McVey 'Add indexim_s op and improve/fix bugs in eqatim_s
19:44 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/261960078 https://github.com/MoarVM/MoarVM/compare/0fe5cd606c24...127fa2ce73ff
19:44 travis-ci left #moarvm
19:44 samcv m: use nqp; dd "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]" ~~ /:m:i j/
19:44 camelia rakudo-moar 46ef1b: OUTPUT: «Nil?»
19:44 samcv m: use nqp; dd "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]" ~~ /:m:i J/
19:44 camelia rakudo-moar 46ef1b: OUTPUT: «Nil?»
19:46 lizmat joined #moarvm
19:53 edehont joined #moarvm
19:53 lizmat_ joined #moarvm
21:10 dogbert11 joined #moarvm
21:27 Ven joined #moarvm
21:52 stmuk joined #moarvm
22:08 stmuk joined #moarvm
22:09 lizmat_ and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/08/07/2017-32-weekly-101/
22:30 japhb .oO( lizmat is best mat )
22:30 japhb :-)

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