Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:08 lizmat joined, p6bannerbot sets mode: +v lizmat 00:33 lizmat left 00:37 lizmat joined, p6bannerbot sets mode: +v lizmat 02:08 notable6 left, benchable6 left, bloatable6 left, squashable6 left, nativecallable6 left, quotable6 left, releasable6 left, statisfiable6 left, reportable6 left, committable6 left, undersightable6 left, bisectable6 left, evalable6 left, greppable6 left, shareable6 left, coverable6 left, unicodable6 left, nativecallable6 joined, ChanServ sets mode: +v nativecallable6, bloatable6 joined, quotable6 joined, ChanServ sets mode: +v quotable6, evalable6 joined, ChanServ sets mode: +v evalable6, notable6 joined, coverable6 joined, ChanServ sets mode: +v notable6, ChanServ sets mode: +v coverable6, greppable6 joined, ChanServ sets mode: +v greppable6, unicodable6 joined, bisectable6 joined, committable6 joined, benchable6 joined, ChanServ sets mode: +v committable6, ChanServ sets mode: +v benchable6, reportable6 joined, releasable6 joined, ChanServ sets mode: +v reportable6, ChanServ sets mode: +v releasable6, undersightable6 joined, undersightable6 left, unicodable6 left, bisectable6 left, bloatable6 left 02:09 p6bannerbot sets mode: +v nativecallable6, p6bannerbot sets mode: +v quotable6, p6bannerbot left, p6bannerbot joined, ChanServ sets mode: +o p6bannerbot 02:13 lizmat left 02:37 lizmat joined, p6bannerbot sets mode: +v lizmat
releasable6 Next release in ≈1 day and ≈15 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
03:09 bisectable6 joined, unicodable6 joined, bloatable6 joined, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v unicodable6 03:10 p6bannerbot sets mode: +v bloatable6 03:11 undersightable6 joined, p6bannerbot sets mode: +v undersightable6, ufobat_ joined 03:12 p6bannerbot sets mode: +v ufobat_ 03:15 ufobat___ left 03:20 MasterDuke left 06:13 statisfiable6 joined 06:14 p6bannerbot sets mode: +v statisfiable6 07:15 dct joined, p6bannerbot sets mode: +v dct 07:28 ZzZombo left
lizmat Files=1255, Tests=76369, 365 wallclock secs (16.12 usr 5.65 sys + 2413.97 cusr 226.88 csys = 2662.62 CPU) 08:42
not sure whether that delay is a fluke or not
jnthn: perhaps something for you? stackoverflow.com/questions/533317...sing-react 08:56
jnthn: re implementing 6.d functionality: would it make sense to have a MOP method to replace one candidate by another in a dispatchee list ? 09:06
case in point: I realized that my %h<a b> 5x improvement has a slight semantic difference in case someone added their own postcircumfix:<{ }> candidates 09:07
that made sense before we completely fleshed out the AT-KEY interface, it does so less now 09:08
so I was thinking: I'll simply add the new version to 6.d, but then we get an ambiguous call error :-( 09:09
[Tux] Rakudo version 2018.10-145-gf7007ac0e - MoarVM version 2018.10-78-gc130b7cdb
csv-ip5xs0.923 - 0.923
csv-ip5xs-207.132 - 7.269
csv-parser22.706 - 25.099
csv-test-xs-200.435 - 0.465
test8.412 - 8.953
test-t1.812 - 1.850
test-t --race0.845 - 0.856
test-t-2032.156 - 32.707
test-t-20 --race10.470 - 11.534
 09:16
09:50 dogbert11 joined 09:51 p6bannerbot sets mode: +v dogbert11 09:53 dogbert17 left 10:38 brrt joined, p6bannerbot sets mode: +v brrt
brrt \o 10:50
I believe I fixed the JIT register type match issue
It may be time for a moarvm bump 10:51
dogbert11 hi brrt, nice job 10:58
lizmat jnthn: sanity check: inside a react block, only one whenever runs at any time, right ? 11:17
jnthn Correct 11:24
lizmat oki 11:32
11:41 brrt left
timotimo that's also why having lexicals in a react or supply block is just fine, because concurrent access is prevented 12:16
12:47 lizmat left 12:49 lizmat joined, p6bannerbot sets mode: +v lizmat
Geth nqp: c210057164 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 2 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...gdd27d548a dd27d548a [JIT] Fix signedness issues c130b7cdb [jit-bisect.pl] Give a --nodelay flag		 12:59
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...gdd27d548a
rakudo: 21f11a3f02 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] c21005716 [MoarVM Bump] Brings 2 co […]

NQP bump brought: github.com/perl6/nqp/compare/2018....gc21005716
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....gc21005716
c4da4c7eab | (Elizabeth Mattijsen)++ | src/core/hash_slice.pm6

Fixes R#2490, SqrtNegInf++
SqrtNegInf Regarding the hash assignment changes: 13:12
m: my @b; @b[0]<a> = 42; @b[0]<b> = 47; dd @b; # this is fine
camelia Array @b = [{:a(42), :b(47)},]
SqrtNegInf m: my @a; @a[0]<a b> = 42, 47; dd @a; # this stopped working
camelia Array @a = []
SqrtNegInf I don't know if this was ever something that was documented to work or not... 13:13
jnthn I think it should work 13:15
I'm a bit surprised we don't have tests covering it
13:21 pmurias joined, p6bannerbot sets mode: +v pmurias 13:36 lizmat left 13:42 lizmat joined, p6bannerbot sets mode: +v lizmat
lizmat is going to revert the 5x faster %h<a b> 13:43
hmmm... maybe not 13:45
SqrtNegInf: looking at the issue, could you please make a ticket ?> 13:47
SqrtNegInf Will do that. 13:48
lizmat SqrtNegInf: I have a fix ready and tested, but would like to refer to issue in commit message... 13:58
if you're not doing it already, I could make the issue
SqrtNegInf Just a sec...
GH#2490 14:00
synopsebot GH#2490 [open]: github.com/rakudo/rakudo/issues/2490 Assignment to hash via array subscript fails
lizmat SqrtNegInf++ 14:02
synopsebot R#2490 [open]: github.com/rakudo/rakudo/issues/2490 Assignment to hash via array subscript fails
lizmat hmmm.... this needs additional fixing... 14:06
bisectable6: old=2018.10 my @a; dd @a[0]<a b>
bisectable6 lizmat, On both starting points (old=2018.10 new=21f11a3) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «(Any, Any)␤»
lizmat bisectable6: old=2018.10 my @a; dd @a[0]<a b>; dd @a 14:07
bisectable6 lizmat, On both starting points (old=2018.10 new=21f11a3) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «(Any, Any)␤Array @a = []␤»
Geth rakudo: 9a2c4b447b | (Elizabeth Mattijsen)++ | src/core/hash_slice.pm6
We shouldn't auto-vivify on access

Fix for R#2490 was a bit too enthusiastic		 14:11
synopsebot R#2490 [open]: github.com/rakudo/rakudo/issues/2490 Assignment to hash via array subscript fails
14:27 shareable6 joined 14:28 p6bannerbot sets mode: +v shareable6 14:37 reportable6 left 14:38 reportable6 joined, squashable6 joined, ChanServ sets mode: +v squashable6, p6bannerbot sets mode: +v reportable6, p6bannerbot sets mode: +v squashable6
Geth rakudo: dc67ee75b1 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Make %h >>op<< %h about 30% faster

Because we don't need to go through creating Lists, but instead directly use the iterator		 16:11
16:22 trnh joined, p6bannerbot sets mode: +v trnh 16:30 trnh left
lizmat timotimo: is there something obvious as to why the following doesn't JIT? 17:18
method pull-one() { nqp::if( $!iter, nqp::iterkey_s(nqp::shift($!iter)), IterationEnd) }
could it be that the $!iter is from a role ?
17:36 robertle left
timotimo well, what does the spesh log say? 17:51
it could be it gets inlined into an outer and that outer is preventing jitting 17:54
lizmat I haven't looked at the spesh log yet... I just see yellow with --profile :-) 18:21
could it be that nqp::iterkey_s is not jitted ? 18:33
timotimo let me have a look 18:37
well, it is in graph.c 18:38
lizmat what should I be looking for in the spesh log ? 18:40
expr bail ?
n
timotimo BAIL is for a complete bail 18:41
lizmat something like: Unexpected opcode in invoke sequence: <speshresolve> ?
timotimo i just saw that in my log, too
lizmat yup, that's the difference
timotimo ah, that's one message that has uppercase bail 18:42
lizmat that seems odd
timotimo there is also "JIT: bailed completely"
speshresolve should be acceptable to just jit the exact same way as sp_speshresolve, tbh
nope, wrong 18:43
lizmat that looks really weird for a simple piece of code like: my %h = "a".."z" Z=> 1..26; for ^10_000 -> int $_ { Nil for %h.keys }
18:45 dct left
timotimo it surprises me that a speshresolve would survive spesh without being turned into an sp_speshresolve 18:45
maybe there is no MVMSpeshPlanned available 18:46
that could be an explanation in theory
or if it came from an inline i guess? 18:47
that's probably what
lizmat well, the .value version of the code above is clean 18:48
the implementation of the two iterators is identical except that one does iterkey_s
and the other does iterval
timotimo in that case it's probably important what it inlines
lizmat just before the BAIL, is that a normal set of PHI's for such simple code ? 18:50
timotimo oh, i'm looking at a spesh log for completely different code 18:51
lizmat I mean: if the only difference in the executing code is nqp::iterkey_s vs iterval 18:53
shouldn't the spesh log be more or less the same ?
also: spesh log for .keys: 10273469 , for .values 10040117 19:02
timotimo lines or bytes or what? 19:05
i'm distracted with $grant stuff at the moment, but if you send me the files - they should compress very well with something like lzma -9 or so :) - i can have a look 19:06
b2gills m: #`( lizmat: ) my %h = a => 1, b => 2; %h >>+=<< (1,2) 19:18
camelia Ambiguous call to 'infix(Hyper: Hash, List)'; these signatures all match:
:(Hyper: Associative:D \left, Iterable:D \right, *%_)
:(Hyper: Iterable:D \left, Iterable:D \right, *%_ --> Iterable:D)
in block <unit> at <tmp> line 1
lizmat b2gills: grrr 19:20
b2gills I know right?
lizmat timotimo: bytes
timotimo: I'll compress even better: 19:22
perl6 --profile -e 'my %h = "a".."z" Z=> 1..26; for ^10_000 -> int $_ { Nil for %h.keys }'
MVM_SPESH_LOG=keys perl6 --profile -e 'my %h = "a".."z" Z=> 1..26; for ^10_000 -> int $_ { Nil for %h.keys }'
MVM_SPESH_LOG=values perl6 --profile -e 'my %h = "a".."z" Z=> 1..26; for ^10_000 -> int $_ { Nil for %h.values }'
how's that for compression :-) 19:23
timotimo haha
lizmat b2gills: the thing is that that should not work 19:24
because you cannot know the order of the keys in the hash
so the offending multi is just for dieing 19:25
timotimo gotta go AFK for a bit, though
lizmat ok... have fun being afk
b2gills That's fair. I was just trying to break your code, and found something that didn't work. 19:26
jnthn lizmat: I finally got a moment to write an answer on that SO question; thanks for the pointer to it. I'd kinda stopped checking often there, there's been not so many new ones of late. 19:28
lizmat jnthn++ 19:29
b2gills: please keep those breakages coming! :-)
b2gills I always keep a tab openned to stackoverflow.com/questions/tagged...ageSize=50 19:35
Geth rakudo: cae9847e46 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
foo
 20:38
rakudo: 481dbf9270 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Use List:D to dispatch on rather than Iterable

This appears to fix the MMD issue that Brad Gilbert++ found with:
   %h >>+<< (1,2)
lizmat argh 20:39
Commit message should have read: 20:40
Don't create the list of keys beforehand, as the .keys and .values functions are guaranteed to have the same order while the structure of the hash is untouched.
(for the "foo" one) 20:41
20:56 patrickb joined 20:57 p6bannerbot sets mode: +v patrickb
Geth rakudo: 64a47d8727 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Improve error message for Associative >>op<< Iterable§
 21:09
mst AlexDaniel: can I please have a list of all IPs your the *ables are coming from? we seem to be poking limits again 21:21
21:22 pmurias left 21:27 pmurias joined, p6bannerbot sets mode: +v pmurias
AlexDaniel mst: there are just two, one ipv4 and another ipv6 21:53
mst: 94.23.219.181 aaand… 21:54
mst ....ticipation 22:01
AlexDaniel mst: and 2001:41d0:2:5eb5:: which you can see also, I guess? About half of them are using one and about another half are using the other 22:03
mst: what do you mean by limits? IIRC the limit is 10 which is why I made them use two IPs… that said, I plan to shut down some of the bots relatively soon (though it's unlikely the total count will go below 10…) 22:06
22:07 [Tux] left
AlexDaniel let me know if I should change something on my end 22:07
22:28 [Tux] joined 22:29 p6bannerbot sets mode: +v [Tux]
Geth rakudo: c4445649f1 | (Elizabeth Mattijsen)++ | 2 files
Mark ops generated by METAOP_ASSIGN with the power of pod

Unfortunately, this also needed a tweak in Block.WHY to make the setting build (the nextsame during setting building went into laland).		 22:42
rakudo: 19f0c84276 | (Elizabeth Mattijsen)++ | src/core/Hyper.pm6
Optimize assigning metaops

If the metaop is one of the >>op=<< persuasion, then we don't need to build a result to return, as the left hand side of the op *is* the result. This makes >>+=<< about 8% faster.
22:52 pmurias left
releasable6 Next release in ≈19 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
japhb Something tells me 4 blockers are unlikely to fall in the next 19 hours 23:06
AlexDaniel hah 23:12
releasable6: status
releasable6 AlexDaniel, Next release in ≈19 hours. 4 blockers. 0 out of 154 commits logged
AlexDaniel, Details: gist.github.com/37a8e05565a3bbb78d...fead448df0
AlexDaniel japhb: releasable6 is very optimistic :)
but
IIRC GH#2477 is resolved
synopsebot GH#2477 [open]: github.com/rakudo/rakudo/issues/2477 [⚠ blocker ⚠] MoarVM panic: Register types do not match between value and node
AlexDaniel I'm not sure, haven't checked it yet 23:13
GH#2451 is kinda half done
synopsebot GH#2451 [open]: github.com/rakudo/rakudo/issues/2451 [⚠ blocker ⚠] Pre-2018.11 toasting
AlexDaniel GH#2113 can be postponed
synopsebot GH#2113 [open]: github.com/rakudo/rakudo/issues/2113 [⚠ blocker ⚠] Revisit bug compatibility unfix for returning Proxy
AlexDaniel fwiw I'm busy till tomorrow so will not be looking into things now 23:15
ok I don't know if GH#2477 is resolved or not. brrt fixed something but in the ticket there is no update yet 23:17
synopsebot GH#2477 [open]: github.com/rakudo/rakudo/issues/2477 [⚠ blocker ⚠] MoarVM panic: Register types do not match between value and node
23:27 j3nnn1 left 23:38 patrickb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!