Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-14

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

All times shown according to UTC.

Time Nick Message
00:20 AlexDaniel fwiw
00:20 AlexDaniel c: HEAD sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s; say now - INIT now
00:20 committable6 AlexDaniel, ¦HEAD(c229022): «Unexpected named argument 'color' passed?  in sub foo at /tmp/gLDzLiAzAB line 1?  in block <unit> at /tmp/gLDzLiAzAB line 1? «exit code = 1»»
00:21 AlexDaniel c: MVM_SPESH_DISABLE=1 HEAD sub foo(:color(:$colour)) { $colour + 1 }; my $s; for ^1000000 { $s += foo(:color($_)) }; say $s; say now - INIT now
00:21 timotimo oh my!
00:21 committable6 AlexDaniel, ¦HEAD(c229022): «500000500000?1.9947207»
00:21 timotimo good catch
00:21 AlexDaniel timotimo: it's this blocker ticket RT #131857
00:21 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131857
00:21 AlexDaniel the new thing about it is that there's no bug with MVM_SPESH_DISABLE=1
00:22 timotimo baaf8b6 More sophisticated named arg handling in spesh.
00:22 timotimo it's not improbable that it's this
00:23 AlexDaniel it's one of the commits from the bump, so yeah
00:24 timotimo but maybe it's this exact moarvm commit in particular
00:40 timotimo huh, zed shaw just gave perl6 & moarvm a shout-out
00:42 timotimo gnite
01:36 Geth ¦ MoarVM: markmont++ created pull request #634: check ffi_closure_alloc() return value
01:36 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/634
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:06 brrt joined #moarvm
06:10 brrt good * #moarvm
06:12 nwc10 good *, brrt
06:13 nwc10 what's left to do before even-moar-jit can be merged? eg "tagging this month's release"?
06:17 brrt iirc jnthn had some comments
06:18 brrt well, jnthn started reviewiing
06:18 nwc10 ++jnthn
06:18 brrt i'm pondering rebasing the changes in graph.c and brining them in separately
06:24 nwc10 I don't know anything useful to be able to comment on that.
06:40 brrt well, the tl;dr is
06:40 brrt i made a big mistake in refactoring the graph *builder* out of graph building
06:41 brrt i did that because the graph builder is not such good design after all
06:41 brrt not as simple as just having a mutable graph, which it is anyway
06:42 nwc10 OK. I'd view your branch as "private" (and about to "die" anyway once its meaningful work is in master) so a rebase doesn't scare me
06:42 nwc10 but I'm curious what jnthn's take is
06:42 brrt well, a rebase does scare me
06:42 nwc10 ah OK :-)
06:42 nwc10 I like clean historyu
06:42 nwc10 (I'm biased)(I end up reading a lot of older commits)
06:43 brrt because i've done it before, and it always ends in a single bring-up-to-date-diff
06:43 nwc10 ah OK, that's a bit more ugly
06:43 brrt because so far the result has always been broken
06:43 brrt (for this branch, that is)
06:43 nwc10 "it's not supposed to be like that" :-/
06:43 brrt well, yeah
06:43 nwc10 hence, yes, now not so sure
06:43 brrt you're not supposed to use git branches and  rebase in the way i have :-P
06:45 brrt anyway, the idea is to split even-moar-jit into two pieces
06:45 brrt one containing the changes to the legacy JIT
06:45 brrt and the other just introduces the new JIT
06:45 brrt the second is much larger of course than the first
06:46 nwc10 that seems very sensible. but yes, as you say, making that split cleanly
06:57 dalek joined #moarvm
06:57 synopsebot6 joined #moarvm
07:20 brrt joined #moarvm
07:39 * brrt wonders how to contact evan miller and tell him about the JIT that isn't in the works but is actually done
07:40 * brrt also wonders how much reputation damage he has caused to MoarVM by starting a new JIT
07:43 lizmat joined #moarvm
07:56 dogbert17 joined #moarvm
08:03 TimToady well, fact is we had a rudimentary jit before and that wasn't mentioned
08:03 TimToady but overall, aside from a few minor misapprehensions, I thought it was a pretty fair (and extensive) article
08:04 TimToady and where there are misapprehensions, it probably indicates doc failure
08:04 brrt i agree
08:04 brrt it's a good article
08:04 brrt als
08:04 brrt *also
08:04 TimToady though I also agree our current repl is a bit schlocky
08:04 brrt i'm with the author that the list/container/itemization thing is much too complex for the value it brings
08:05 TimToady I'm planning to do something about the Nil return from grammars as well
08:05 brrt oooh, i'm interested
08:05 brrt (maybe a Failure?)
08:06 brrt my guess; when grammars were developed, Failures were not yet a thing
08:06 TimToady yes, probably a Failure
08:06 brrt cool
08:07 TimToady we already have the highwater mechanism in there; but there's no way to pull out the information from the P6 level yet
08:07 TimToady daxim++ also complained that there was no infinite left-recursion detection, which we should also fix
08:08 TimToady (at TPCiA)
08:09 brrt (if we do return Failures, can we refactor out the exception throwing in the grammar?)
08:09 TimToady what exception throwing?
08:10 brrt i recall having seen that… the FAILGOAL iirc
08:10 TimToady STD threw exceptions, but I don't think rakudo works that way right now, but then again I have no idea what timezone I'm in :)
08:11 TimToady oh, well, that's for a fatal panic anyway
08:11 TimToady but yeah, there may be connections to make there
08:20 zakharyas joined #moarvm
08:21 brrt i'm failing a test case of JSON::Fast
08:39 nwc10 good UGT, TimToady
08:42 nwc10 brrt: also, I'd suggest that the JIT is only unambigously "available" (struggingly for a word that isn't mistaken as "done" or "finished") when it's in a shipped release
08:42 nwc10 so maybe next week
08:42 brrt the legacy JIT is very much availalbe
08:43 brrt *available
09:00 brrt joined #moarvm
09:24 brrt joined #moarvm
09:29 nwc10 brrt: good point. if one has missed the "legacy" JIT, where has one been for the past couple of years?
09:34 TimToady well, it's not like we talk about jitting much in the user docs; it's supposed to be largely transparent
09:35 brrt it's not advertised, and my question is, is my work on the expr jit giving the impression it may be deprecated
09:35 brrt thereby stealing perl6's marketing points?
09:35 brrt should we have been much more silent about it?
09:36 TimToady second-guessing the past it pretty useless
09:37 brrt true
09:37 brrt i'm curious about the bug in uzu
09:43 * TimToady about to board CPH --> SFO
09:43 jnthn TimToady: Safe flight :)
09:43 TimToady catch y'all on the flip side
09:43 TimToady &
09:45 nine When one hears about a JIT in a language, one expects a certain level of performance. So maybe it's a good thing that the lego JIT is not widely advertised. "What you already have a JIT and you're still _that_ slow? There's no hope whatsoever!"
09:46 nine It really takes some time to understand the difference in expected performance between the lego JIT and even moar JIT. And very hard to predict the results. So for marketing purposes talking as if we'd go from zero to JIT could be useful :)
09:58 nwc10 can we say "prototype" instead of "zero" without being "wrong" (either on the marketing side or the engineering side)?
09:59 stmuk maybe call it Nearly In Time? :)
10:01 jnthn Our spesh + JIT division is actually doing what most other languages just call their JIT fwiw
10:02 jnthn If we want to talk about how much it helps, we can always show numbers with/without it :P
10:03 nine Once we have them, sure. My emphasis was more on the "There's no hope whatsoever!" part.
10:04 nine Though I personally think that spesh is in the best place to give us major improvements.
10:04 * brrt too
10:06 jnthn Yeah, there's still tons of opportunity there. It just needs very careful work; it's easy to get something faster, and another thing wronger.
10:06 brrt hehe
10:06 jnthn That said, a lot of the things I've been fixing have been long-standing issues that hid because we didn't optimize that aggressively
10:06 brrt i'm debugging the uzu thing
10:07 brrt it doesn't apparently look like a JIT or spesh bug
10:07 jnthn m: say 2.44 / 1.08
10:07 camelia rakudo-moar a3c71e: OUTPUT: «2.259259?»
10:07 jnthn That's the spesh/JIT speedup on the read a million lines benchmark for example
10:08 brrt can you decompose that in spesh/jit?
10:08 brrt or is that already deocmposed?
10:10 jnthn With spesh enabled and JIT disabled it's 1.34s
10:10 jnthn m: say 2.44 / 1.34
10:10 camelia rakudo-moar a3c71e: OUTPUT: «1.820896?»
10:11 jnthn m: say 1.34 / 1.08
10:11 camelia rakudo-moar a3c71e: OUTPUT: «1.240741?»
10:11 jnthn So the JI
10:11 jnthn T provides an extra 25% or so
10:11 nine Makes sense considering that it just removes the op dispatch overhead
10:12 jnthn Yeah. The non-lego JIT stands to remove a bunch of memory accesses
10:12 jnthn So could contribute more
10:12 jnthn Spesh could also do better
10:22 brrt (it will do that effectively, only, if we can compile large enough fragments, which means that i need to start thinking about multiple basic blocks soonish)
11:06 dogbert17_ FWIW, I tried to reproduce the uzu bug thingy this weekend on my 32 bit rig, there was no error !
11:07 dogbert17_ OTOH one spectest SEGV'd instead :)
11:15 brrt the uzu error disappears under lldb
11:15 brrt (and it also hangs sometimes under lldb)
11:19 Geth ¦ MoarVM: 0ee9103236 | (Jonathan Worthington)++ | 6 files
11:19 Geth ¦ MoarVM: Stub in atomic ops.
11:19 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0ee9103236
11:40 markmont joined #moarvm
11:43 dogbert17_ the uzu test work on my $work machine as well 'This is Rakudo version 2017.07-157-ga3c71e7d3 built on MoarVM version 2017.07-378-g5e94da03a' valgrind has no complaints
11:45 brrt joined #moarvm
11:50 timotimo brrt: i sent evan miller a few tweets, including this one: https://twitter.com/loltimo/status/896875772677242883
11:51 dogbert17_ timotimo: have you slept well?
11:51 timotimo not really, but better than the night before
11:51 dogbert17_ is it still unbearably hot?
11:52 brrt thanks timotimo
11:52 brrt :-)
11:53 timotimo no, the temperature is not an issue any more
11:53 timotimo in fact, recently we had intense rains that caused our basement to flood a little
11:53 dogbert17_ oops
11:57 timotimo we got lucky. the other people in this house, not so much
11:58 dogbert17_ and the cats didn't have to swim
11:59 timotimo right
11:59 timotimo they much prefer not swimming
12:01 dogbert17_ aren't cats a bit anti water
12:02 dogbert17_ heh, looks like I don't have jnthn's memset fix: total heap usage: 405,169 allocs, 149,692 frees, 21,599,768,962 bytes allocated
12:04 brrt1 joined #moarvm
12:04 timotimo there are cats that like swimming. ours aren't like those
12:05 nwc10 my parents had a cat once that loved to watch (and then hit) the water from a running tap
12:05 timotimo :D
12:06 nwc10 and was always disappointed to discover how something wonderfully shiny and fast moving could turn out to be uUURGH, wet.
12:08 dogbert17_ do the cats like to help you running rr and fixing SEGV's :)
12:12 timotimo not really :)
12:13 timotimo one of our cats really enjoys it when we open a can of champignons and spill the water
12:13 timotimo he would tilt his head sideways and "bite" the stream of water
12:29 dogbert17_ brrt, your findings wrt uzu are consistent with the fact that I don't see the problem as 32 bit => no JIT
12:33 dogbert17_ timotimo: the SEGV in t/spec/S32-io/IO-Socket-Async.t is gone in MoarVM HEAD. Probably fixed by 7d38e51ce12a2d
12:33 timotimo could be, yeah
12:35 zakharyas joined #moarvm
12:46 Geth ¦ MoarVM/atomics: 7d87ef5292 | (Jonathan Worthington)++ | 2 files
12:46 Geth ¦ MoarVM/atomics: Extend container v-table for atomic ops.
12:46 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/7d87ef5292
13:04 dogbert17_ another positive thing is that I'm no longer able to reproduce two MoarVM issues which I reported earlier
13:04 timotimo cool!
13:05 dogbert17_ perhaps I should close them
13:08 lizmat joined #moarvm
13:27 Geth ¦ MoarVM/atomics: 9a4b7381e9 | (Jonathan Worthington)++ | 2 files
13:27 Geth ¦ MoarVM/atomics: Extend container v-table for atomic ops.
13:27 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/9a4b7381e9
13:29 SourceBaby joined #moarvm
14:02 Geth ¦ MoarVM/atomics: 14323fdc9e | (Jonathan Worthington)++ | 2 files
14:02 Geth ¦ MoarVM/atomics: cas_o and atomicstore_o should be invokish.
14:02 Geth ¦ MoarVM/atomics:
14:02 Geth ¦ MoarVM/atomics: Granted using it with something like a subset type that needs a
14:02 Geth ¦ MoarVM/atomics: late-bound invoking type check would be a tad odd, but we should
14:02 Geth ¦ MoarVM/atomics: support it correctly anyway.
14:02 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/14323fdc9e
14:02 Geth ¦ MoarVM/atomics: faa9521e29 | (Jonathan Worthington)++ | src/6model/containers.h
14:02 Geth ¦ MoarVM/atomics: Should pass cas v-table function result register.
14:02 Geth ¦ MoarVM/atomics:
14:02 Geth ¦ MoarVM/atomics: So it can handle the late-bound case.
14:02 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/faa9521e29
14:02 Geth ¦ MoarVM/atomics: 5a8ea1116a | (Jonathan Worthington)++ | 3 files
14:02 Geth ¦ MoarVM/atomics: Forward container atomic ops to v-table functions.
14:02 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/5a8ea1116a
14:06 Geth ¦ MoarVM/atomics: 34c62427cc | (Jonathan Worthington)++ | 3 files
14:06 Geth ¦ MoarVM/atomics: cas v-table function is void now we pass register.
14:06 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/34c62427cc
14:19 Ven joined #moarvm
14:25 brrt joined #moarvm
14:49 brrt joined #moarvm
14:50 brrt joined #moarvm
14:51 dogbert17_ jnthn: will you blog about the atomics?
14:55 jnthn dogbert17_: Yeah, once I get the lot done :)
14:56 moritz atomics? nukular destruction!
15:01 Geth ¦ MoarVM: vendethiel++ created pull request #635: Fix typo in MVM_6model_container_atomic_store
15:01 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/635
15:03 Ven`` (at least I think that's what it's meant to be ^)
15:06 Geth ¦ MoarVM/atomics: 7ecdaa82ad | ven++ (committed using GitHub Web editor) | src/6model/containers.c
15:06 Geth ¦ MoarVM/atomics: Fix typo in MVM_6model_container_atomic_store
15:06 Geth ¦ MoarVM/atomics:
15:06 Geth ¦ MoarVM/atomics: In containers.c
15:06 Geth ¦ MoarVM/atomics: The function checked for cs->atomic_load being present, but then went on using cs->atomic_store.
15:06 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/7ecdaa82ad
15:06 Geth ¦ MoarVM/atomics: 9c906ef8b5 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/containers.c
15:06 Geth ¦ MoarVM/atomics: Merge pull request #635 from vendethiel/patch-1
15:06 Geth ¦ MoarVM/atomics:
15:06 Geth ¦ MoarVM/atomics: Fix typo in MVM_6model_container_atomic_store
15:06 Geth ¦ MoarVM/atomics: review: https://github.com/MoarVM/MoarVM/commit/9c906ef8b5
15:06 Ven`` I've loaded the blog post for now, can't wait to read it later :).
15:09 brrt joined #moarvm
15:17 stmuk_ joined #moarvm
15:19 [Coke] joined #moarvm
15:23 brrt jnthn: valgrind complains about us not writing the 'best result' in find_invokee_static_frame
15:24 brrt and indeed best_result is never written
15:26 brrt https://github.com/MoarVM/MoarVM/issues/636
15:27 jnthn uh, yeah, it wants initializing to NULL
15:28 brrt and then written as what?
15:28 jnthn It's written 5 lines below the one I mentioned
15:28 jnthn uh, the one *you* mentioned :)
15:28 jnthn https://github.com/MoarVM/MoarVM/blob/0ee9103236df139e3d75d0bc0bf7e26f7600e8b9/src/spesh/optimize.c#L1278
15:29 brrt i see
15:29 brrt yeah
15:29 brrt missed that
15:29 jnthn Well, I somehow missed NULLing it in the first place, so... :)
15:29 brrt pushing fix
15:30 brrt also, there's an off-by-one in MVM_string_index
15:31 Geth ¦ MoarVM: eb65519976 | (Bart Wiegmans)++ | src/spesh/optimize.c
15:31 Geth ¦ MoarVM: Initialize best_result as NULL
15:31 Geth ¦ MoarVM:
15:31 Geth ¦ MoarVM: Found by valgrind
15:31 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eb65519976
15:40 nwc10 Lee pointed me to https://morepypy.blogspot.ch/2017/08/lets-remove-global-interpreter-lock.html
15:40 nwc10 I got as far as "Why did the STM effort not work out?"
15:41 brrt yeah, i clicked that too
15:47 brrt also, there's an off-by-one in MVM_string...
15:48 brrt .tell samcv https://gist.github.com/bdw/9b0076211c6d7d80e8ec2c660ea7c6b9
15:48 yoleaux brrt: I'll pass your message to samcv.
15:49 brrt wonder if we can trigger this somewhat easier
15:53 brrt nwc10, that doesn't seem like they already have a very good overview yet
16:01 zakharyas joined #moarvm
16:12 Geth ¦ MoarVM: MasterDuke17++ created pull request #637: Cleanup typos, formatting, etc in comments
16:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/637
16:15 Geth ¦ MoarVM: 2a0570e6ac | MasterDuke17++ (committed using GitHub Web editor) | src/spesh/optimize.c
16:15 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
16:15 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2a0570e6ac
16:15 Geth ¦ MoarVM: db4909efe5 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/optimize.c
16:15 Geth ¦ MoarVM: Merge pull request #637 from MasterDuke17/patch-5
16:15 Geth ¦ MoarVM:
16:15 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
16:15 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/db4909efe5
16:32 jnthn Just got sent http://vmmeetup.github.io/2017/cfp.md
16:33 jnthn VM conference. In Prague at end of Septmeber
16:33 Geth ¦ MoarVM: MasterDuke17++ created pull request #638: Clean up typos, formatting, etc in comments
16:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/638
16:33 jnthn Kinda tempted to go along
16:53 jnthn Dinner &
17:01 travis-ci joined #moarvm
17:01 travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #637 from MasterDuke17/patch-5
17:01 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/264421326 https://github.com/MoarVM/MoarVM/compare/eb6551997618...db4909efe5f1
17:01 travis-ci left #moarvm
17:47 Geth joined #moarvm
17:51 coverable6 joined #moarvm
17:51 bloatable6 joined #moarvm
17:51 committable6 joined #moarvm
17:51 quotable6 joined #moarvm
17:51 evalable6 joined #moarvm
17:51 bisectable6 joined #moarvm
17:51 unicodable6 joined #moarvm
17:51 greppable6 joined #moarvm
17:51 benchable6 joined #moarvm
18:11 samcv good *
18:11 yoleaux 11 Aug 2017 21:00Z <AlexDaniel> samcv: FWIW, you may be interested in RT #131881 (it's about ignoremark)
18:11 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131881
18:11 yoleaux 15:48Z <brrt> samcv: https://gist.github.com/bdw/9b0076211c6d7d80e8ec2c660ea7c6b9
18:11 samcv i've got mail
18:13 samcv .tell brrt so the main thing to see there that it read 1 byte too much? looks like it's coming from threebyte_memmem since you use os x so it uses our 3rdparty/freebsd/memmem.c file
18:13 yoleaux samcv: I'll pass your message to brrt.
18:13 samcv though probably more likely we told it to read one further value than we should? hmm
18:14 samcv .tell brrt is that reproducable? can you tell me how you produced it? i can manually use the freebsd memmem/nonfreebsd memem and see if any diff
18:14 yoleaux samcv: I'll pass your message to brrt.
18:32 Geth ¦ MoarVM: 7c4150f569 | MasterDuke17++ (committed using GitHub Web editor) | src/spesh/manipulate.c
18:32 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
18:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7c4150f569
18:32 Geth ¦ MoarVM: 1f6fae6a9a | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/manipulate.c
18:32 Geth ¦ MoarVM: Merge pull request #641 from MasterDuke17/patch-4
18:32 Geth ¦ MoarVM:
18:32 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
18:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1f6fae6a9a
18:32 Geth ¦ MoarVM: 3e3f66ea3c | MasterDuke17++ (committed using GitHub Web editor) | src/spesh/dead_bb_elimination.c
18:32 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
18:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3e3f66ea3c
18:32 Geth ¦ MoarVM: 877f88a46b | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/dead_bb_elimination.c
18:32 Geth ¦ MoarVM: Merge pull request #642 from MasterDuke17/patch-5
18:32 Geth ¦ MoarVM:
18:32 Geth ¦ MoarVM: Cleanup typos, formatting, etc in comments
18:32 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/877f88a46b
18:33 jnthn Elimiantes, the great reductionist philosopher...
18:35 samcv :-)
18:37 samcv yay my fix fixes that rt
18:37 samcv well at least the one thing i tried
18:40 jnthn Is that the JSON::Tiny regression one?
18:40 samcv yep
18:40 jnthn yay \o/
18:40 jnthn Something stringy?
18:40 jnthn I thought it was gonna be some spesh bustage of mine until it turned out to happen even with that disabled...
18:40 samcv the issue was the path changed away from the MVM_ord_get_base_char_at or whatever it was to ord_basecharat
18:40 samcv *ord_getbasechar
18:41 samcv which didn't check for synthetics. i was planning on making the change. almost thought i'd done it but probably got caught up on my trip and forgot to commit it
18:41 jnthn :)
18:41 samcv though there was a huge bug in ignoremark where it would match anything that had the firts two codepoints of the haystack
18:42 samcv so 'blah' ~~ /blz/ would match
18:42 jnthn oops
18:42 samcv luckily i think it's not that one
18:42 samcv well it didn't have a ignoremark index op or eqatim op
18:42 samcv i mean it faked it by checkng the first two graphemes lol
18:42 samcv i installed JSON::Tiny with no issue. yay \o/
18:43 samcv i had a test i added but didn't push to roast yet which covered this case as well
18:43 samcv will add theirs too since can always use more tests
18:44 samcv err actually slightly different issue
18:44 samcv my issue was
18:44 samcv Synthetics with decomposable base characters properly work with ignoremark
18:44 samcv "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]" ~~ /:m:i j /,
18:44 samcv since letter j with caron is one codepoint. it used to not decompose it
18:45 samcv which will also get fixed with this as well
18:45 samcv since previously it assumed once it grabbed the synthetics base character it already had what it needed, but if the base char is latin small letter j with caron, or another decomposable character, that's very untrue
18:46 samcv jnthn, not sure what i'm going to do about Prepend and our synthetic representation which puts whatever the first codepoint it sees into `base`
18:47 jnthn Me either. I didn't worry about it as there were no prepends when I first implemented NFG ;)
18:47 jnthn But now there are.
18:48 samcv yeah heh
18:48 jnthn And yeah, we'd rather have the char props of the real base
18:48 samcv yeah
18:49 samcv we can have unlimited characters before the base. so maybe we need an extra buffer to hold prepends?
18:49 samcv i dunno
18:49 samcv so we have one for things after the base and one for those after it
19:07 Geth ¦ MoarVM: 712cff3341 | (Samantha McVey)++ | src/strings/ops.c
19:07 Geth ¦ MoarVM: Fix a bug in index/eqat(im) and in ord_getbasechar
19:07 Geth ¦ MoarVM:
19:07 Geth ¦ MoarVM: Previously it assumed that once we had gotten a synthetic's base character
19:07 Geth ¦ MoarVM: that we already had the final base character. This wasn’t true for example
19:07 Geth ¦ MoarVM: with: "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]"
19:07 Geth ¦ MoarVM: The "j with caron" would not be decomposed because it was the base character
19:07 Geth ¦ MoarVM: of a synthetic.
19:07 Geth ¦ MoarVM: <…commit message has 8 more lines…>
19:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/712cff3341
19:16 travis-ci joined #moarvm
19:16 travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #639 from MasterDuke17/patch-2
19:16 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/264432606 https://github.com/MoarVM/MoarVM/compare/a6d3a35758b3...b0250f107c53
19:16 travis-ci left #moarvm
19:32 AlexDaniel samcv: thank you very much!
19:33 samcv you're welcome :)
20:03 jnthn samcv: Maybe we should just store an array of codepoints that make up the synthetic
20:03 jnthn samcv: *including* the base char (somewhere)
20:03 jnthn samcv: And then the base char additionally
20:04 jnthn Then codepoint iteration wouldn't care, it'd just interate thet codes
20:04 jnthn And things that care for the base char would just take it
20:09 releasable6 joined #moarvm
20:20 samcv jnthn, that sounds decent
20:21 samcv and just store the index of the base?
20:22 jnthn samcv: We could, or just store the base itself and save a level of indirection? :)
20:23 jnthn I'm figuring most things either want all the codepoints *or* the base
20:23 jnthn So feels like just storing the base + the array would be easier, but maybe the struct packs to a byte boundary better or it makes something easier that I'm overlooking?
20:25 travis-ci joined #moarvm
20:25 travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #641 from MasterDuke17/patch-4
20:25 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/264467329 https://github.com/MoarVM/MoarVM/compare/b0250f107c53...1f6fae6a9aef
20:25 travis-ci left #moarvm
20:53 committable6 joined #moarvm
20:53 evalable6 joined #moarvm
20:53 bloatable6 joined #moarvm
20:53 releasable6 joined #moarvm
20:53 greppable6 joined #moarvm
20:53 unicodable6 joined #moarvm
20:53 coverable6 joined #moarvm
20:53 quotable6 joined #moarvm
20:53 benchable6 joined #moarvm
20:53 bisectable6 joined #moarvm
20:55 travis-ci joined #moarvm
20:55 travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #642 from MasterDuke17/patch-5
20:55 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/264467552 https://github.com/MoarVM/MoarVM/compare/1f6fae6a9aef...877f88a46bfc
20:55 travis-ci left #moarvm
21:00 markmont joined #moarvm
21:42 ilmari[m] joined #moarvm
23:02 lizmat and another issue of the Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/08/14/2017-33-in-review/
23:52 buggable joined #moarvm
23:52 ZofBot joined #moarvm
23:52 markmont joined #moarvm
23:52 leego joined #moarvm
23:53 tbrowder joined #moarvm
23:54 SmokeMachine joined #moarvm
23:55 TimToady joined #moarvm
23:56 MasterDuke joined #moarvm
23:56 ChanServ joined #moarvm
23:56 lizmat joined #moarvm
23:56 jsimonet joined #moarvm
23:56 Zoffix joined #moarvm
23:56 solarbunny joined #moarvm
23:56 Geth joined #moarvm
23:56 eater joined #moarvm
23:56 ingy joined #moarvm
23:59 TimToady joined #moarvm

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