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.
japhb I just decided to try it, and it seems to be working, thanks! 00:08
00:17 dogbert17 left 00:19 lucasb left
japhb Yay, finally have first complete Rakudo-and-modules update in a while. 00:24
Geth rakudo/release-2018.12: 38e12bda79 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 2 files
Log all changes (+ announcement)

Deliberately not logged:
2dbef993 adda0683 07d95bf9 31317001 e3ab2f9e a63c2ba8 212193cb 543219c9 fd7f8b6d af96fbb4 91fd7cf8 9fe7d643 1d597fa5 9211b464 a87c27e4 19238b87 0f3c370a 5f3a955a c00aef29 e747b19a bca05ae5 203487f3 41d2da09 7f3f77d4 848932df eb31db95 e96b7ffe		 01:51
rakudo/release-2018.12: c73faad621 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Actual date, claim next release
rakudo/release-2018.12: 0b61f96927 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Fix release date
 04:03
timotimo can i change something in there before release? 04:17
Geth rakudo/release-2018.12: dce81aea03 | timo++ (committed using GitHub Web editor) | docs/ChangeLog
add a missing closing `
 04:19
rakudo/release-2018.12: 104c6b6e48 | timo++ (committed using GitHub Web editor) | docs/announce/2018.12.md
add a missing closing ` in here as well
04:21 AlexDaniel left 04:22 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
AlexDaniel ===> Install [FAIL] for zef:ver<0.6.0>:auth<github:ugexe>:api<0>: ===SORRY!=== 05:08
Cannot invoke this object (REPR: Null; VMNull)
hmmmmmmmmm
interesting, it passed the second time 06:24
would love to know what went wrong that previous timeā€¦
06:27 ufobat_ joined
Geth nqp: 8a664f3149 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[release] Bump MoarVM revision to 2018.12
 06:28
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2......2018.12
6f0dd0d60a | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
rakudo/release-2018.12: 4b7cbd7e61 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[release] Bump NQP revision to 2018.12
rakudo/release-2018.12: eb08bd11eb | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
[release] Bump VERSION to 2018.12
06:28 p6bannerbot sets mode: +v ufobat_
Geth rakudo/master: 8 commits pushed by (Aleks-Daniel Jakimenko-Aleksejev)++, timo++ 06:31
Ā¦ rakudo/master: version bump brought these changes: github.com/perl6/nqp/compare/2018.......2018.12
AlexDaniel timotimo: thanks for taking a look! 06:32
somehow I missed your question, but yes, of course! 06:33
undersightable6: status 06:35
undersightable6 AlexDaniel, OK! Working on itā€¦
AlexDaniel, 1 error, 19 warnings: gist.github.com/9e3b12fc3296b2aae1...b6ac7aa384 06:36
AlexDaniel ahhh undersightable6, you silly 06:37
it didn't pull rakudo yet, and it looks like it never pulls nqpā€¦ 06:38
weekly: (writing this ahead of time in case I forget) Merry Christmas! ā€¦ or Happy Diwali!? to debian users, rakudo 2018.12 is now in debian unstable (and hopefully debian testing soon), meaning that the next debian release will most likely come with v6.d-capable rakudo 06:42
notable6 AlexDaniel, Noted!
AlexDaniel it should happen unless we introduced more big endian issuesā€¦
07:26 robertle joined, p6bannerbot sets mode: +v robertle 08:06 dct left 08:12 robertle left 08:14 robertle joined 08:15 p6bannerbot sets mode: +v robertle 08:38 robertle left 09:03 epony joined, p6bannerbot sets mode: +v epony 10:25 robertle joined, p6bannerbot sets mode: +v robertle 10:58 robertle left 11:26 lizmat joined, p6bannerbot sets mode: +v lizmat
lizmat AlexDaniel++ # release! 11:26
yoleaux 20 Dec 2018 18:51Z <japhb> lizmat: Actually, I think `my int $bits = 65; dd 1 +< $bits` ==> 2 is in fact a bug, unless we have decided +< on int has rotation semantics, rather than shift. Otherwise it should be 0 (all 1 bits have shifted entirely off to the left, rather than reappearing on the right when they exited on the left)
lizmat .tell japhb i"m not sure it's rotation semantics or masking semantics on the $bits value 11:28
yoleaux lizmat: I'll pass your message to japhb.
11:53 lucasb joined, p6bannerbot sets mode: +v lucasb
lucasb Thanks for the release you awesome team o/ 12:33
Geth rakudo: 45a945b5b6 | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Introducing buf8/blob8.read-(u)bits/write-(u)bits

Read any sequence of bits from any *bit* position in a buffer for any number of *bits*, and interprete the result as a big-endian Int:D or UInt:D.
Write any Int:D / UInt:D value to any *bit* position in a buffer for any number of *bits*.
Does *not* use any of the new read-/write- methods, so should work on any backend that supports nqp::atpos_i and bit-shifting and masking operations.		 13:00
roast: c2c741668b | (Elizabeth Mattijsen)++ | S03-buf/read-write-bits.t
Tests for blob8/buf8.read-(u)bits/write-(u)bits
 13:01
lizmat ^^^ not added to spectest.data yet because this feature might still get reverted 13:02
afk&
Geth roast: 333581c9a3 | (Zoffix Znet)++ (committed using GitHub Web editor) | docs/release-guide.md
List VERSION File in Release Guide
 13:24
13:53 stmuk joined 13:54 p6bannerbot sets mode: +v stmuk 13:58 stmuk left
dogbert2_ .seen AlexDaniel 14:43
yoleaux I saw AlexDaniel 06:42Z in #perl6-dev: <AlexDaniel> it should happen unless we introduced more big endian issuesā€¦
15:02 Ven`` joined 15:03 p6bannerbot sets mode: +v Ven`` 15:40 Ven`` left
AlexDaniel . 16:01
dogbert2_ AlexDaniel: do you want a gig? 16:03
AlexDaniel yes!
dogbert2_ ok, can you bisect 'MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S32-list/sort.t'
problem is probably less than a week old 16:04
AlexDaniel ouch
let's seeā€¦
dogbert2_ it should SEGV
AlexDaniel c: HEAD MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 run <perl6 sandbox/roastt/spec/S32-list/sort.t> for ^5 16:05
committable6 AlexDaniel, gist.github.com/4b74ff2b3bf899c3df...353a519b9e
AlexDaniel oops
c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD run <perl6 sandbox/roastt/spec/S32-list/sort.t> for ^5
committable6 AlexDaniel, Ā¦HEAD(45a945b): Ā«Could not open sandbox/roastt/spec/S32-list/sort.t. Failed to stat file: no such file or directoryā¤The spawned command 'perl6' exited unsuccessfully (exit code: 1)ā¤ in block <unit> at /tmp/Z9JQX2zQZL line 1ā¤ā¤ Ā«exit code = 1Ā»Ā»
AlexDaniel c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD run <perl6 sandbox/roast/spec/S32-list/sort.t> for ^5
committable6 AlexDaniel, Ā¦HEAD(45a945b): Ā«Could not open sandbox/roast/spec/S32-list/sort.t. Failed to stat file: no such file or directoryā¤The spawned command 'perl6' exited unsuccessfully (exit code: 1)ā¤ in block <unit> at /tmp/m5nvdDwEia line 1ā¤ā¤ Ā«exit code = 1Ā»Ā»
dogbert2_ no roast installed?
AlexDaniel wrong pathā€¦
c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD run <perl6 sandbox/roast/S32-list/sort.t> for ^5
dogbert2_ it does not fail on 32 bit systems 16:06
committable6 AlexDaniel, gist.github.com/e60bb076a9cc9e5074...752cdbe556
dogbert2_ that didn't give much 16:07
it should SEGV on test #27
AlexDaniel e: chdir ā€˜sandbox/roast/ā€™; run <git pull>
evalable6 From github.com/perl6/roast
 cc378eca0..333581c9a master -> origin/ā€¦
AlexDaniel, Full output: gist.github.com/273bac7089db769a73...34ab522123
AlexDaniel c: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 HEAD run <perl6 sandbox/roast/S32-list/sort.t> for ^10 16:08
dogbert2_: how often does that happen?
dogbert2_ always for me
committable6 AlexDaniel, gist.github.com/b4a8be898ca37d9f91...af1dfc845e
dogbert2_ nwc10++ got it as well, see #moarvm 16:09
does commitable honor the env vars?
AlexDaniel dogbert2_: ah there it is 16:10
if you look closely 16:11
sometimes it stops on test 26
just not always
dogbert2_ yes, for me that implies test #27 :-)
AlexDaniel c: HEAD %*ENV<MVM_SPESH_NODELAY>=1; %*ENV<MVM_SPESH_BLOCKING>=1; for ^5 { exit 42 if (run <perl6 sandbox/roast/S32-list/sort.t>).signal != 0 } 16:12
committable6 AlexDaniel, gist.github.com/52002b45571042b451...570549dfb9
AlexDaniel bisect: old=2018.10 new=HEAD %*ENV<MVM_SPESH_NODELAY>=1; %*ENV<MVM_SPESH_BLOCKING>=1; for ^5 { exit 42 if (run <perl6 sandbox/roast/S32-list/sort.t>).signal != 0 }
bisectable6 AlexDaniel, Bisecting by exit signal (old=2018.10 new=45a945b). Old exit signal: 1 (SIGHUP) 16:13
AlexDaniel that'sā€¦ not right
it timed out on old revision
maybe it will give the right answer, but most likely not
dogbert2_ how could it time out 16:15
I 'suspect' that the problem is newer than 2018.10
bisectable6 AlexDaniel, bisect log: gist.github.com/d125099465d75d3ff9...2a00a52f62
AlexDaniel, (2017-07-30) github.com/rakudo/rakudo/commit/2d...2da0e5bdae
AlexDaniel bisect: old=2018.10 new=HEAD %*ENV<MVM_SPESH_NODELAY>=1; %*ENV<MVM_SPESH_BLOCKING>=1; for ^3 { exit 42 if (run <perl6 sandbox/roast/S32-list/sort.t>).signal != 0 } 16:16
that sounds about right, actually
bisectable6 AlexDaniel, Bisecting by exit code (old=2018.10 new=45a945b). Old exit code: 0
AlexDaniel dogbert2_: it did 5 runs but the timeout is 10 seconds I think
bisectable6 AlexDaniel, bisect log: gist.github.com/1fce2286e6aab1c356...b7e0ded1e7 16:18
AlexDaniel, (2018-12-11) github.com/rakudo/rakudo/commit/d4...6c737078c6
dogbert2_ that commit is immense 16:19
AlexDaniel dogbert2_: github.com/rakudo/rakudo/pull/1812/commits 16:20
bisectable probably got confused on one of the points
but
c: 6e7893bd3a5,bfff01a55a %*ENV<MVM_SPESH_NODELAY>=1; %*ENV<MVM_SPESH_BLOCKING>=1; for ^5 { exit 42 if (run <perl6 sandbox/roast/S32-list/sort.t>).signal != 0 } 16:21
committable6 AlexDaniel, gist.github.com/49a48d9ef2745fdd16...e93cebacd7 16:22
AlexDaniel dogbert2_: OK I have to run now, but TL;DR it's the result `cur-candidates` branch merge 16:23
possibly indirect and the actual issue can be in moar 16:24
dogbert2_ AlexDaniel: thx
AlexDaniel but yes, it appeared yesterday, but the release was cut exactly from the commit before the merge :)
so plz file a ticket and mark it as a blocker, we need to fix that for the release in January 16:25
dogbert2_ ok, will do when I get home
16:42 lucasb left
[Tux] Rakudo version 2018.12-37-g45a945b5b - MoarVM version 2018.12
csv-ip5xs0.942 - 0.960
csv-ip5xs-206.896 - 7.184
csv-parser22.970 - 23.621
csv-test-xs-200.435 - 0.443
test7.288 - 7.423
test-t1.834 - 1.848
test-t --race0.820 - 0.827
test-t-2030.329 - 30.590
test-t-20 --race9.511 - 9.557
 18:19
AlexDaniel it's either 3a68cc9 or d41bc6d 18:45
github.com/rakudo/rakudo/commit/3a68cc9 github.com/rakudo/rakudo/commit/d41bc6d
weirdā€¦
ok nvm ignore what I just said 18:46
18:51 dogbert17 joined 18:52 p6bannerbot sets mode: +v dogbert17
dogbert17 AlexDaniel: so which commit should I mention in the issue? 18:54
AlexDaniel dogbert17: just mention cur-candidates merge, that's it 18:59
timotimo o/ 19:02
dogbert17 hi timotimo 19:04
AlexDaniel dogbert17: I don't think that there's a meaningful or helpful bisect result in this case 19:05
for example, github.com/rakudo/rakudo/commit/d41bc6d is bad
but both of its parents are good
timotimo spesh nodelay is kind of known to be explosive, i'm not entirely sure how best to handle it with regards to priorities
AlexDaniel timotimo: eh not really? IIRC the majority of roast passes with spesh nodelay 19:06
timotimo wow, when did that happen 19:07
cool
dogbert17 AlexDaniel, timotimo: github.com/MoarVM/MoarVM/issues/1027 19:08
AlexDaniel timotimo: that's why we get these bug reports :) 19:10
dogbert17: btw is there a superticket with remaining nodelay segfaults? 19:12
I remember asking for it once, but I don't know what happened afterā€¦
dogbert17 I don't think so, most of the time only two tests fail but they're supposed to fail so I ignore them. I can do a run now to see where we stand. 19:13
AlexDaniel these two are really annoying IMO 19:16
no tests should be supposed to failā€¦
dogbert17 one test which has a tendency to never complete is when using these flags is S07-slip/slip.t
AlexDaniel like, it'd be nice to declare it 100% clean and then any failure that appears we can just label as a blocker automatically 19:17
dogbert17 s/is//
Geth nqp/master: 13 commits pushed by (Paweł Murias)++
review: github.com/perl6/nqp/compare/6f0dd...f46c7d0988		 19:32
lizmat m: use v6.c; dd blob8.new(255,255).read-uint16(0) # should this work or not ? read-uint8 was added in 6.d, and not available before 6.2 19:35
camelia 65535
lizmat *6.d
dogbert17 AlexDaniel: looks quite good, ran a stresstest and if we ignore the two 'special cases' only 5 test files had failures 19:39
onw of which is t/spec/S32-list/sort.t
AlexDaniel lizmat: is there even a way to make it not work? 19:40
R#1289 ? 19:41
synopsebot R#1289 [open]: github.com/rakudo/rakudo/issues/1289 [6.e] Implement a Way to Know Caller's Language
lizmat AlexDaniel: not sure... my question was about correctness or not
dogbert17 the others are MISC/bug-coverage-stress.rakudo.moar (test #2), S02-types/isDEPRECATED.rakudo.moar (tests 8, 10-11, 13). S07-slip/slip.t and S17-procasync/nonexistent.t both hang ...
AlexDaniel eh, wellā€¦ usually we say that if it passes v6.c roast then it's OK 19:42
by that definiton you can add many things and it's ā€œokā€
that's LTA but unless R#1289 is resolved I don't think there's much we can do about it 19:43
synopsebot R#1289 [open]: github.com/rakudo/rakudo/issues/1289 [6.e] Implement a Way to Know Caller's Language
AlexDaniel dogbert17: can we have a ticket for each of them and + a superticket with links? Pleeeease :) 19:44
Geth nqp: da8da3fca7 | (Paweł Murias)++ | src/vm/js/Operations.nqp
[js] Add missing /*await*/ to nqp::chain
 19:54
20:33 robertle joined, p6bannerbot sets mode: +v robertle
japhb . 20:39
yoleaux 11:28Z <lizmat> japhb: i"m not sure it's rotation semantics or masking semantics on the $bits value
japhb .tell lizmat That's a decent point, though I'm not sure why we'd use masking semantics on $bits, unless we're trying to emulate a real-world processor that does that. To me it makes more sense to "mask" the result, so that ($int +< $large) is equivalent to ($Int +< $large) % 2**64, rather than ($Int +< ($large % 64)) % 2**64, which seems semantically needlessly complex 20:42
yoleaux japhb: I'll pass your message to lizmat.
timotimo it'll also be interesting for other sizes than 64 ... 20:49
lizmat . 20:57
yoleaux 20:42Z <japhb> lizmat: That's a decent point, though I'm not sure why we'd use masking semantics on $bits, unless we're trying to emulate a real-world processor that does that. To me it makes more sense to "mask" the result, so that ($int +< $large) is equivalent to ($Int +< $large) % 2**64, rather than ($Int +< ($large % 64)) % 2**64, which seems semantically needlessly complex
lizmat m: say 1 +< 255 # should this really be a very big number or not ? 20:58
camelia 57896044618658097711785492504343953926634992332820282019728792003956564819968
timotimo for an Int, sure 20:59
you get machine-style operations with native ints and otherwise big ints
Geth roast: ec149023f6 | (Elizabeth Mattijsen)++ | S03-buf/read-write-bits.t
Add bound checks for read-(u)bits/write-(u)bits
 21:00
lizmat then I think I don't agree with japhb 21:03
japhb lizmat: Why not? 21:23
lizmat japhb: if you use a native int to indicate number of bits shift, I can totally see the result being limited to native int size 21:35
if the number of bits is *not* a native int, all bets are off 21:36
it's maybe too subtle, but I can live with that :-)
japhb lizmat: I'm not sure I understand. Could you give an example of what you think should happen in each case?
lizmat m: say (1 +< 65).fmt("%065b") 21:42
camelia 100000000000000000000000000000000000000000000000000000000000000000
lizmat m: say (1 +< my int $ = 65).fmt("%065b")' 21:43
00000000000000000000000000000000000000000000000000000000000000010
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say (1 +< my int $ = 65).fmt("%065b")7ā5'
expecting any of:
infix
infix stopper
postfix
statement end
ā€¦
lizmat m: say (1 +< my int $ = 65).fmt("%065b")
camelia 00000000000000000000000000000000000000000000000000000000000000010
lizmat something screwy going on here: 21:45
m: say ((1 +< 31 - 1) +< my int $ = 65).fmt("%065b") # "wraps"
camelia 00000000000000000000000000000000011111111111111111111111111111110
lizmat m: say ((1 +< 32 - 1) +< my int $ = 65).fmt("%065b") # does not wrap 21:46
camelia 1111111111111111111111111111111100000000000000000000000000000000000000000000000000000000000000000
japhb Yeah, that does seem goofy.
lizmat so I guess the current semantics are: if both sides of +< are native values, we use masking semantics
and that it incorrectly assumes it's no longer native if left hand exceeds 32 bits 21:47
japhb FWIW, I think it only matters what's on the *left* side of +<, as that's the value to shift.
lizmat: Perhaps that's a smallint bug?
(At the Moar level, I mean)
lizmat japhb: well there's several odd things going on: 21:48
japhb As a side note: As soon as I spend a lot of time thinking about shift and rotate, I start wishing I had access to the carry flag. But that's a WHOLE other discussion. 21:49
japhb is listening
lizmat m: my int $a = 1 +< 63 21:50
camelia Cannot unbox 64 bit wide bigint into native integer
in block <unit> at <tmp> line 1
lizmat m: my uint $a = 1 +< 63
camelia ( no output )
lizmat who cares about a signed bit in that case ? 21:51
(please note I'm slightly distracted doing other stuff in between :-) 21:52
japhb Yeah, if you're shifting bits around, I wouldn't think 1 +< 63 should be a problem, it should just be -(2**63) as the bits show.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!