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