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.
Geth rakudo: 5603128e01 | (Petr Rockai)++ | src/core/VM.pm6
Ignore shared library versions on OpenBSD.

Shared library version numbers in OpenBSD rarely match those provided by upstream, breaking many packages which specify them.		 00:44
rakudo: 313170011d | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | src/core/VM.pm6
Merge pull request #2530 from mornfall/fix-openbsd-libs

Ignore shared library versions on OpenBSD.
AlexDaniel timotimo: what's that (last)? Docs? Tests? 00:48
timotimo oh, i was about to test my tests, but got distracted after building newest moarvm (and still have to build a new nqp and rakudo), but i also want to go to sleep soon 00:49
m: react { whenever Supply.interval(0.3) { say "B1: $_"; last if $_ > 5; LAST { say "last B1" } }; whenever Supply.interval(0.6) { say "beep $_"; last if $_ > 5; LAST { say "last beep" } } }; say "finished" 00:50
camelia B1: 0
beep 0
B1: 1
beep 1
B1: 2
B1: 3
beep 2
B1: 4
B1: 5
beep 3
B1: 6
last B1
beep 4
beep 5
beep 6
last beep
finished
timotimo this is new ^
AlexDaniel ahhh I see 00:51
Geth rakudo: Kaiepi++ created pull request #2536:
Add Kaiepi to CREDITS		 01:01
rakudo: e3ab2f9ed5 | (Ben Davies)++ (committed using GitHub Web editor) | CREDITS
Add Kaiepi to CREDITS
 01:02
rakudo: a63c2ba837 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | CREDITS
Merge pull request #2536 from Kaiepi/patch-1

Add Kaiepi to CREDITS
lizmat Files=1256, Tests=81562, 338 wallclock secs (15.03 usr 5.32 sys + 2403.78 cusr 208.67 csys = 2632.80 CPU) 10:13
jnthn Huh, how could `$result ~~ Rat && $result.denominator == 0` ever result in "No such method denominator for invocant of type Num"? 10:15
|Tux| system-load during build is ultra-high again: tux.nl/Files/20181211114336.png 10:43
lizmat [Tux]: any idea when that changed ? 10:48
|Tux| nope
Rakudo version 2018.11-28-ga63c2ba83 - MoarVM version 2018.11-19-g0d5f389c3
csv-ip5xs0.905 - 0.931
csv-ip5xs-207.227 - 7.264
csv-parser21.491 - 22.327
csv-test-xs-200.419 - 0.420
test7.788 - 8.616
test-t1.799 - 1.807
test-t --race0.770 - 0.779
test-t-2030.262 - 30.477
test-t-20 --race9.066 - 10.908
 10:50
Ulti |Tux|: out of curiosity which Perl 5 are you using? 11:03
lizmat .ask jnthn are dynamic variable lookups cached and if so, OOC how? 11:04
yoleaux lizmat: I'll pass your message to jnthn.
lizmat m: for ^1_000 { for ^2 { if $*FOO { } } }; say now - INIT now 11:10
camelia 0.1114137
lizmat m: for ^1_000 { my $FOO := $*FOO; for ^2 { if $FOO { } } }; say now - INIT now
camelia 0.07577071
lizmat currently it makes sense to cache a single (failing) dynamic var lookup if you would look it up *twice* in the same scope 11:12
even for successful lookups it makes sense: 11:14
m: my $*FOO = 42; for ^10_000 { for ^2 { if $*FOO { } } }; say now - INIT now
camelia 0.02156946
lizmat m: my $*FOO = 42; for ^10_000 { my $FOO := $*FOO; for ^2 { if $FOO { } } }; say now - INIT now
camelia 0.021713
lizmat m: my $*FOO = 42; for ^10_000 { for ^2 { if $*FOO { } } }; say now - INIT now
camelia 0.021828006
lizmat m: my $*FOO = 42; for ^10_000 { my $FOO := $*FOO; for ^2 { if $FOO { } } }; say now - INIT now
camelia 0.02200071
lizmat ok, I guess it is within noise then 11:15
also: running a profile on "for ^1_000 { for ^2 { if $*FOO { } } }" creates a huge, broken profile 11:17
timotimo ^^^ ideas, opinions? 11:19
|Tux| Ulti, at that box, or anywhere? 11:20
on tux (the test box) I use 5.28.0 (x86_64-linux-thread-multi-ld) 11:21
Ulti on the test box for the output 11:24
ok thats cool
timotimo oh, i hope that's not another incarnation of the "we generate gotos across 'prof_leave' and the tree grows sideways" problem 11:37
lizmat timotimo: should I ticket it ? 11:45
Geth nqp: a50a2a6ee7 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Fix label
 12:03
nqp: f8e87c58cd | (Elizabeth Mattijsen)++ | docs/ops.markdown
Add constants to list of constants
 12:06
timotimo yeah, if you want to 12:07
lizmat will do 12:08
Geth rakudo/master: 8 commits pushed by (Paweł Murias)++ 13:32
travis-ci Rakudo build failed. Paweł Murias '[js] Adapt to using a p6$ prefix on methods' 14:35
travis-ci.org/rakudo/rakudo/builds/466512550 github.com/rakudo/rakudo/compare/a...59f9d72936
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 14:35
lizmat restarted the failing job: probably a flapper 14:37
Geth rakudo: 4f14d7134c | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Initial implementation of Blob.readint / Buf.writeint

As more or less described in
   gist.github.com/jnthn/1e865a06d213...2908858a57
This commit implements:
... (19 more lines)		 14:39
releasable6 Next release in ≈4 days and ≈3 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
lizmat travis build is green after restart of job 15:10
m: my $b = Blob[int8].new(-1); dd $b.read-int8(0) 15:18
camelia 255
lizmat that feels wrong
m: my $b = Blob[int8].new(-1); dd $b.read-int8(0); dd $b[0] 15:19
camelia 255
-1
lizmat nine ^^ 15:20
Geth roast: f08f4a4008 | (Elizabeth Mattijsen)++ | S03-buf/read-int8.t
Add test file for testing Blob.read-int8

Created a new directory for these tests. Also, did not add this to rakudo's
  spectest.data as it presently still has quite a number of failures.		 15:25
lizmat m: my $b = Blob[uint8].new(255); dd $b.read-int8(0) # sorta expected to see -1 there, am I wrong ? 15:30
camelia 255
|Tux| Rakudo version 2018.11-37-g4f14d7134 - MoarVM version 2018.11-19-g0d5f389c3
csv-ip5xs0.915 - 0.937
csv-ip5xs-206.992 - 7.543
csv-parser21.928 - 22.270
csv-test-xs-200.424 - 0.434
test7.225 - 7.989
test-t1.709 - 1.714
test-t --race0.789 - 0.791
test-t-2029.292 - 30.499
test-t-20 --race9.709 - 9.812
 15:38
(the system-load was now more or less as expected: tux.nl/Files/20181211163914.png)
lizmat that looks a lot better
|Tux| indeed
lizmat the MoarVM version is the same, and the other commits either only just add stuff or are JS specific 15:42
so I can't explain the difference... :-(
nine lizmat: that's....odd. If anything I'd expect it to faultily interpret something as singed, not unsigned. 15:47
lizmat nine: well, writing tests now... so that's how I found out :-) 15:48
Geth rakudo: 011c6f11d4 | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
The endianness parameter of read-int8/uint8 is meaningless

So ignore its value and just go for native		 15:52
lizmat afk for a bit&
nine nqp: my $b := MAST::Bytecode.new; nqp::bindpos_i($b, 0, -1); note(nqp::readint($b, 0, 1)) 15:53
camelia 255
nine lizmat: same here ^^^
Ooooooh, I get it
It's missing the sign extension when reading less than 64 bits. While 255 and -1 are indeed represented exactly the same in a byte, there's a whole lot of difference in a 64 bit number. There 255 is not the highest possible unsigned value 15:56
lizmat so it is a bug ? 15:57
afk for a bit for real& 16:05
lizmat hmmm... so do we have a constant somewhere that indicates whether we're running on a little-endian or big-endian system ? 18:00
samcv lizmat, no 18:02
i want one though
lizmat too 18:03
I guess the new read-int8 will give us a way to do it...
samcv lizmat, you can hack it though. by encoding something with utf16 18:04
and seeing if it matches with utf16le encoder :P
what's the new read-int8?
lizmat m: say Blob[uint16].new(256).read-int8(0) # 1 means big-endian 18:05
camelia 0
lizmat samcv: implementation of gist.github.com/jnthn/1e865a06d213...2908858a57 18:06
but instead of named params, use a optional positional of the Endian enum
samcv ah nice
lizmat m: dd Endian.^enum_values
camelia Hash element = {:big-endian(2), :little-endian(1), :native-endian(0)}
samcv i always wanted to read a blob as an int 18:07
well actually whichever bits i wanted
arbitrary bits
but mostly just as byte or multibyte numbers
lizmat well, this is byte level, not bit level
or actually, element level, as the offset indicates the element in the underlying buf 18:08
*not* byte offset
not sure I like that, but that's the way it is currently implemented
nine lizmat: you're the first one to try it on anything but a uint8 buffer 18:09
samcv so basically casts it as a 8bit array?
lizmat m: say Blob[uint16].new(256).read-int8(0,little-endian) # should probably be specific
camelia 0
lizmat nine: actually, that's a good point 18:10
the spec only specifies methods for blob8/buf8
nine Which probably is the most natural representation of a mixed size memory region 18:11
mixed element size
lizmat ok, that simplifies matters a bit :-) 18:12
lizmat is having a tough time mixing in read-int/write-int just into the blob8/buf8 roles 18:45
lizmat gives up for now 19:02
lizmat feels like I'm moving into "here be dragons" area: 20:02
m: my uint64 $a = 9223372036854775807; say $a; say $a.fmt("%x")
camelia 9223372036854775807
7fffffffffffffff
lizmat m: my uint64 $a = 9223372036854775808; say $a; say $a.fmt("%x")
camelia -9223372036854775808
-8000000000000000
lizmat first of all: that should not be negative
secondly: wtf with the .fmt("%x") ???
ah, that's actually correct 20:03
no, why the - ???
m: my int8 $a = 255; say $a; say $a.fmt("%x") # is this to be expected? I would have expected "ff" ? 20:05
camelia -1
-1
Geth rakudo/cur-candidates: 709 commits pushed by 26 authors
review: github.com/rakudo/rakudo/compare/3...1bc6dd2452		 20:40
AlexDaniel releasable6: status 21:34
releasable6 AlexDaniel, Next release in ≈3 days and ≈21 hours. 4 blockers. 0 out of 38 commits logged
AlexDaniel, Details: gist.github.com/04e24e6347a0239bb0...72be51c416
gfldex m: given True { when :so { say 'outtahere' }; say 'not saying!'; CONTROL { default { say .^name; .resume } } } 21:42
camelia outtahere
gfldex m: given True { when :so { say 'outtahere' }; say 'not saying!'; CONTROL { default { say .^name; .resume } } }
camelia outtahere
CX::Succeed
not saying!
gfldex please not the flapping ^^^
*note
lizmat gfldex: flapping confirmed 21:45
and I'm not seeing any potential for a race there
gfldex filed as #2538 21:46
gfldex tries not to dream of flapping bugs 21:47
lucasb R#2538 21:53
Geth roast: ee604e4bc4 | (Elizabeth Mattijsen)++ | S03-buf/read-int8.t
All possible read-int tests

With quite a lot of fails still, caused by 2 reasons:
   uint64 is not a uint:
   my uint64 $a = 0xffff_ffff_ffff_ffff; say $a # -1 instead of 2**63 - 1
   read-intx() does not extend sign bit:
   dd blob8.new(255).read-int8(0) # 255 instead of -1		 22:06
roast: 1a8e22df51 | (Elizabeth Mattijsen)++ | 2 files
Change name of file: not just about int8
 22:07
roast: 816f89299e | (Elizabeth Mattijsen)++ | S03-buf/read-int.t
Add some comments
 22:10
lizmat afk&
Geth roast: 5824d79954 | (Timo Paulssen)++ | S17-supply/syntax.t
add tests for "last" in whenever blocks
 22:36
timotimo e: use MONKEY; EVAL qq⟨class Test \{ { 'has $.attr_' ~ $_ ~ ';\n' for ^100_000 } \}.new ⟩ 22:46
evalable6 Use of Nil in string context
in block <unit> at /tmp/NthM6XedvL line 1
timotimo e: use MONKEY; say qq⟨class Test \{ { 'has $.attr_' ~ $_ ~ ';\n' for ^100_000 } \}.new ⟩ 22:47
evalable6 Use of Nil in string context
class Test { }.new
in block <unit> at /tmp/Z62Q3YHy7S line 1
timotimo e: use MONKEY; say qq⟨class Test \{ { join "", do 'has $.attr_' ~ $_ ~ ';\n' for ^100_000 } \}.new ⟩
e: use MONKEY; EVAL qq⟨class Test \{ { join "", do 'has $.attr_' ~ $_ ~ ';\n' for ^100_000 } \}.new ⟩
evalable6 class Test { has $.attr_0;\nhas $.attr_1;\nhas $.attr_2;\nhas $.attr_3;\nhas $.attr_4;\nha… 22:48
(exit code 1) 04===SORRY!04=== Error while compiling /home/bisectable/git/wh…
timotimo, Full output: gist.github.com/29d13d7588d4cdc1e3...f4ae924e3a
timotimo, Full output: gist.github.com/22af171b5ea746e1b7...9dda032b2c
timotimo oh, that \n became literal 22:53
e: use MONKEY; EVAL qq⟨class Test \{ { join ";\n", do 'has $.attr_' ~ $_ for ^100_000 } \}.new ⟩
m: say 2 ** 16 / 8 22:54
camelia 8192
evalable6 (signal SIGHUP) «timed out after 25 seconds»
timotimo e: use MONKEY; EVAL qq⟨class Test \{ { join ";\n", do 'has $.attr_' ~ $_ for ^10_000 } \}.new ⟩
evalable6

Powered by Cro and the Raku® Programming Language.

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

Thank you!