00:05 pyrimidine joined 00:22 pyrimidine joined 00:41 pyrimidine joined 00:51 pyrimidine joined 01:01 pyrimidine joined 02:48 ilbot3 joined 02:52 pyrimidine joined 03:01 pyrimidine joined 03:11 colomon_ joined, pyrimidine joined 03:19 stmuk_ joined 03:20 pyrimidine joined 03:29 pyrimidine joined 03:39 pyrimidine joined 03:49 pyrimidine joined 03:58 pyrimidine joined 04:07 pyrimidine joined 04:25 leego joined 04:26 pyrimidine joined 04:35 pyrimidine joined 04:53 pyrimidine joined 05:01 pyrimidine joined 05:03 pyrimidi_ joined 05:21 pyrimidine joined 05:31 pyrimidine joined 05:40 pyrimidine joined 05:58 pyrimidine joined 06:16 pyrimidine joined 06:26 pyrimidine joined 06:35 pyrimidine joined 06:45 pyrimidine joined 06:54 pyrimidine joined 07:03 pyrimidine joined 07:22 pyrimidine joined 07:32 pyrimidine joined 07:45 Dunearhp joined 07:50 pyrimidine joined 08:00 domidumont joined 08:07 domidumont joined 08:11 sivoais_ joined
dalek arVM/even-moar-jit: 52ef878 | brrt++ | / (5 files):
Write register specification from tile definitions

This is intended to replace the use of the template pointer and the
  'vtype' to determine which values should live in registers.		 08:42
09:34 pyrimidi_ joined 10:08 brrt joined
brrt \o 10:08
nwc10 o/
10:10 pyrimidine joined
brrt i'm decently happy about the register specification logic, but I need to figure some bits out yet 10:10
jnthn moarning o/ 10:14
brrt moarning jnthn 10:20
perl6 day today?
jnthn Aye
Also last working day for me before Christmas break. :) 10:21
This turns out to be one of the years where out of the 4 national holidays that .cz has around this season, 3 of them fall on weekends. 10:23
brrt :last-workday<nice>, :holiday-on-weekends<better luck next year> 10:34
jnthn Indeed :)
Ah well, I'd got plenty of spare vacation days :) 10:35
brrt @$work, most people are having the last workday as well
i have just about enough
will be glad to be taking a holiday 10:36
jnthn Yeah, I need some good rest :)
brrt hehe, it will be the first time i get some *real* time for MoarVM soon 10:37
so i hope to make some progress. but then again, christmas 10:38
jnthn Yes, remember to relax some too :)
Well, I did what I immediately could on the OO::Monitors issue...
jnthn ponders what to look at next
brrt ehm, could you fix the expr jit register allocator, if you have nothing better to do? ;-) 10:39
jnthn :P
I think you're in a better place to do that :-)
brrt oh, can i bug you about the extract-spesh-allocator thingy by any chance 10:40
do you think it's a good idea, or doesn't it matter sufficiently?
10:40 domidumont joined
jnthn Oh, right, I can look at that now :) 10:40
I even saw the PR yesterday when looking at another one and thought "ah, I should review that" :) 10:41
10:42 dogbert17_ joined
jnthn Yeah, I like it 10:43
But why was Travis sad... 10:44
huh wat travis-ci.org/MoarVM/MoarVM/jobs/168582210
Yeah, they look bogus fails where the Travis build agent fell offline or something 10:45
dalek arVM: aba07a2 | brrt++ | / (7 files):
Extract spesh allocation from spesh

The `spesh` allocator uses a strategy known as memory-region allocation and is suitable for more contexts than just `spesh`.
arVM: a645d7e | jnthn++ | / (7 files):
Merge pull request #432 from MoarVM/extract-spesh-alloc

Extract spesh allocation from spesh
brrt cool, thanks :-) 10:46
dogbert17_ o/ so what will you hack on today?
jnthn Good question :) 10:47
rt.perl.org/Ticket/Display.html?id=130379 looks ungood 10:48
dogbert17_ :-) don't you have any longstanding issues you'd like to fix?
jnthn Well, hyper/race is pretty near the top of the list. Re-writing the scheduler also. Making await non-blocking for three. :-) 10:50
dogbert17_ perhaps something that is easy to reproduce?
jnthn I'm seeing if I can reproduce the one I linked
dogbert17_ cool
jnthn But I also wonder a little bit if it was another case of the thing I fixed yesterday, or in the alternate something else we've fixed recently.
dogbert17_ could be 10:51
jnthn We've had a couple of reports where the symptom was a crash in gc_mark of an MVMCallCapture
dogbert17_ m: class Foo { has $.a = Metamodel::ClassHOW.new_type(name => "Bar"); method comp { $!a.^compose } }; my $obj = Foo.new; $obj.comp; say $obj; #RT 128516
camelia rakudo-moar b8df3a: OUTPUTĀ«(signal SEGV)Ā»
jnthn o.O
dogbert17_ at lest it is easy to reproduce :-) 10:56
dogbert17_ sips coffee
jnthn Aye
RT #130379 didn't explode with a normal build of HEAD
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130379
jnthn Trying it with GC stress now
nwc10 ASAN still chokes on t/spec/S32-str/encode.rakudo.moar 10:57
jnthn Alas, no such luck
dogbert17_ maybe you've already fixed it 11:00
jnthn That is very possible too 11:01
jnthn comments on the tikcet
*ticket
dogbert17_ sneaks away for a short lunch 11:06
jnthn :)
jnthn has RT #128516 reproduced locally
11:35 Dunearhp joined
jnthn Fixed the SEGV, and also a bug that was then exposed in Rakudo 11:47
yoleaux2 11:08Z <lizmat> jnthn: I've put it in a gist: gist.github.com/lizmat/afb86eeb905...b361fa2870
11:20Z <lizmat> jnthn: the minimum case is: "my $a = 0.5e0; for ^100000 { $a.floor }" where floor takes between 60 and 194 msecs with rest remaining the same
jnthn spectesting now :) 11:48
dalek arVM: e2ffc35 | jnthn++ | src/6model/reprs/P6opaque.c:
Don't allow re-compose of a P6opaque.
 11:55
jnthn lunch for me now also :) 12:03
.tell lizmat How are you determining that? :) When I run it under `time` then I get fairly little variance in the overall runtime. 12:07
yoleaux2 jnthn: I'll pass your message to lizmat.
jnthn .tell lizmat and in the profile it came out as spending 20%, 22%, 22%, 21% of time in there over 4 runs also 12:09
yoleaux2 jnthn: I'll pass your message to lizmat.
jnthn Really lunch :) 12:10
lizmat . 12:13
yoleaux2 12:07Z <jnthn> lizmat: How are you determining that? :) When I run it under `time` then I get fairly little variance in the overall runtime.
12:09Z <jnthn> lizmat: and in the profile it came out as spending 20%, 22%, 22%, 21% of time in there over 4 runs also
nwc10 ilmari: ^^
lizmat jnthn: well, maybe it is a macOS specific thing than
*then
260,266,487,261,440,277,290,255,279,395,276 12:15
hmmm... maybe it's an artefact of profiling: if the OS needs to pre-empt for something else, that time will show up in the place where execution takes place the most ? 12:16
in any case, I'm used to seeing maybe 20% variance in timing, not like a factor 0f 3.5 or so
anyways, afk for the rest of the day 12:17
jnthn Curious. Maybe that or maybe your CPU does some kind of performance scaling thing? 12:41
To control power/heat etc. 12:42
dogbert17_ what's on the fix list now? 12:52
jnthn That ASAN barf that nwc10 mentioned I think :)
dogbert17_ sounds interesting
jnthn Oh no, this is going to be about utf8-c8 12:53
RT #128184 12:54
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128184
dogbert17_ uh oh, no tasty SEGV in other words 12:57
jnthn Well, I've put off fixing it for a good while, so I should really do it 13:00
dogbert17_ I can always throw a juicy SEGV your way later if you're interested 13:07
jnthn I suspect redesigning this decoder will take a bit :) 13:17
I'm tired of patching it up. 13:18
timotimo yeah, utf8-c8 </3
brrt that is an interesting smiley :-o 13:24
notviki looks like a severed nutsack 13:26
but I suspect it's šŸ’” 13:27
jnthn o.O 13:31
notviki :} 13:32
dalek arVM/needless_mvmroot: 0a170ab | (Jimmy Zhuo)++ | src/spesh/deopt.c:
remove another unused MVMROOT
jnthn Well done, you just made working on utf8-c8 feel comparatively painless :P
notviki \o/
brrt yeah, i had understood it to be a broken heart. it's just funny because it looks like HTML close tags? 13:38
jnthn Only if you've spent too long looking at HTML :P 13:39
brrt well, how long is too long, really
it's HTML, so not very long
jnthn :) 13:41
brrt wonders if he should start a clang-stfu branch 14:02
moritz call it silent-clang, just for the giggles :-) 14:05
brrt hehehe
timotimo i get a tremendous amount of output from libatomic_ops, btw 14:10
every single file it complains loudly about the piece of code that's meant to prevent loud complaining about some option
3rdparty/libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:36:37: warning: ā€˜-pedanticā€™ is not an option that controls warnings [-Wpragmas]
# pragma GCC diagnostic ignored "-pedantic"
brrt oh, that's on GCC right 14:11
timotimo it is an gcc
brrt hmmm
gcc has decided to become clangy...
14:32 pyrimidi_ joined
dalek arVM/utf8-c8-rewrite: ef10f18 | jnthn++ | src/strings/utf8_c8.c:
Update comments describing UTF8-C8.

To match what it *should* be doing.		 14:40
MoarVM/utf8-c8-rewrite: a17449b | jnthn++ | src/strings/utf8_c8.c:
MoarVM/utf8-c8-rewrite: Start re-doing UTF8-C8 non-streaming decode.
MoarVM/utf8-c8-rewrite:
MoarVM/utf8-c8-rewrite: We don't try and trick a UTF-8 decoder with its own state model into
MoarVM/utf8-c8-rewrite: playing along with your scheme; that proved fragile. Instead, just
MoarVM/utf8-c8-rewrite: have our own decode loop where that need was thought out from the
MoarVM/utf8-c8-rewrite: very start. Interestingly, this partial re-work that totally ignores
MoarVM/utf8-c8-rewrite: normalization passes the majority of the tests and passes a number
MoarVM/utf8-c8-rewrite: of todo'd tests also.
14:41 zakharyas joined
dalek arVM/even-moar-jit: 4b8b2be | brrt++ | src/jit/ (4 files):
Use register spec rather than template ptr

Because live-range calculation overlaps with tree-node extraction, this use can't be removed as easily, and will have to wait for the move of node extraction to the tiler.		 15:32
arVM/even-moar-jit: 68d37f8 | brrt++ | src/jit/tile.c:
Cosmetic change - call TileTree TreeTiler

It's the state object of the tiling process, not really a tree, so I think the new name makes more sense than the old one did.		 15:37
brrt once i've moved the tree node reading code to the tiler, i'll be ready to remove the template pointer 15:39
interestingly; the node number stays, as it is equivalent to the 'virtual register index' of the tile 15:40
and then we're just a bit more ready to finish and swap the linear scan allocator in
(moving the tree extraction code to the tiler is an almost-but-not-quite mechanical transformation because it affects how the register allocator finds out the references) 15:42
jnthn Sounds like nice progress :) 15:46
jnthn is fixing utf8-c8 to deal with normalization breaking its round-tripping
As well as the buffer overrun
15:47 domidumont joined
dalek arVM/utf8-c8-rewrite: 22f1324 | jnthn++ | src/strings/utf8_c8.c:
Properly handle normalization in utf8-c8.

We can emit NFG synthetics into the result string, but only when the result of encoding them back to utf8-c8 later will not result in the byte sequence produced changing. Also, any normalization that changes the codepoints in any way will result in synthetics being inserted to ensure the round-trip.
This passes the utf8-c8 tests that we passed before. It also passes encode.t without upsetting valgrind, and makes todo'd tests for utf8-c8 pass also, which will fix an RT. 5b10c3d | jnthn++ | src/strings/utf8_c8.c: Fix the empty buffer case for utf8-c8.		 16:19
jnthn Phew. :)
timotimo fantastic
jnthn The bad news is that the streaming version still needs re-doing
But I ain't doing that today :) 16:20
nwc10 so bottled utf8-c8 works, but the draft is off?
timotimo right. i'll be busy for rest of day with the insane idea of going christmas shopping in town
jnthn Something like
Also...seems it's not entirely happy
JimmyZ jnthn: looks like missing a 'break' after the second mismatch = 1? 16:29
jnthn It doesn't much matter for correctness 16:30
But yeah, we can for a tad extra speed
(The one about *is* needed for correctness)
nwc10 s/about/above/ # naughty fingers?
jnthn uh, yes
dalek arVM/utf8-c8-rewrite: c087b98 | jnthn++ | src/strings/utf8_c8.c:
Another early break, for speed.

Spotted by JimmyZ++.		 16:32
jnthn I'm off for a bit, but will give it a spectest run while I'm gone 16:33
japhb jnthn: saw your comment about oo-monitors; perhaps I did something wrong last time, I'll rebuild the world with your new version and check again. 16:34
jnthn japhb: OK, sounds good. I bumped the version in META6.json also. 16:37
OK, away for a bit :) 16:39
japhb jnthn: I get the following during oo-monitors testing: 16:53
Useless use of constant value not-empty in sink context (lines 15, 20)
Useless use of constant value not-full in sink context (lines 12, 22)
I doubt that makes much of a difference, but figured you should know.
Also, the current oo-monitors version does not work for me, same old 'Cannot invoke this object (REPR: Null; VMNull)' when I try to use it from Terminal-Print. 16:57
So let's see if I understand: You've ruled out everything you can do on the oo-monitors side, now I get to refocus on nine for the precomp stuff? :-) 16:58
17:21 geekosaur joined 17:31 pyrimidine joined 17:41 pyrimidine joined
nwc10 jnthn: on your branch, ASAN is friends with that spectest 18:31
18:34 stmuk joined 18:43 domidumont joined 18:50 pyrimidine joined
jnthn japhb: Well, at least, if it's OO::Monitors related then I could do with a golf (or - even better - a failing test case in t/precomp.t) 19:15
SmokeMachine I received a response of my bug report #130379 but Im trying to reply... but looks that not working... 19:22
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130379
SmokeMachine is the actual moar version 2016.12-18-ga645d7e? 19:23
japhb jnthn: Fair enough. 19:24
SmokeMachine synopsebot6: thanks! 19:27
but this is what happens when I clink on the response link, I get this: ibin.co/36Afzkjv3dvV.png 19:30
ok, I got... it's a bot... :( 19:33
jnthn japhb: I guess I coulda added some precomp tests for cond-var-using code too, thinking about it. 19:34
The warnings are also a macro issue 19:35
(And related to using cond-vars)
But don't break functionality
timotimo brought home some gyoza 19:39
jnthn mmm 19:41
jnthn just cooked/ate kofta 19:42
notviki giggles
You're not supposed to eat it!
timotimo is kofta a swear word where you're from? :) 19:49
notviki timotimo: no, it means "sweater" 19:52
dalek arVM/even-moar-jit: 7223dea | brrt++ | / (8 files):
Move tree node extraction to tiling step

As a result, can remove the template pointer from the tile. The unfortunate side-effect is that debug logging has become somewhat harder.		 20:13
[Coke] everything's a swear if you're mad enough.
20:14 pyrimidine joined
brrt has just tried out a new espresso machine. it was.... interesting 20:15
timotimo haha 20:16
brrt alright, i'm going to remove the MVMJitValue silliness 20:17
20:20 pyrimidine joined
brrt hmm. I recently argued at work that polymorphism and encapsulation had side-effect of reducing the set of interesting things you can do to a set of objects 20:21
because it reduces the set of useful assertions that can be made of objects
now I want to generalise that a bit
i hate 'polymorphic value objects'
MVMJitValue is like that 20:22
stack location, registers address, moar virtual register address, all rolled in one
that's a mistake
different things ought to be treated differently
in fact 20:23
we can interpret an object only by it's location
so it's location is as good a way to discriminate as any
i'm not sure if i'm making a ton of sense there 20:25
20:34 pyrimidine joined 21:17 pyrimidine joined 21:56 pyrimidine joined
jnthn japhb: At the end of the day, though, the more general pre-comp closure bug will need addressing. It looks non-trivial to solve alas, but maybe once I've had my winter rest it'll seem be less so. :) 22:57
(And even if it still looks non-trivial, at least I'll have had a rest. :)) 23:00
japhb jnthn: True enough. :-) 23:05
jnthn sleep & 23:23

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!