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:17 dct left 00:34 thundergnat left 01:27 lizmat left 01:33 lucasb left 02:10 AlexDani` joined 02:11 p6bannerbot sets mode: +v AlexDani` 02:15 AlexDaniel left
Geth roast/cur-candidates: 4317fb4039 | (Nick Logan)++ | S11-repository/cur-candidates.t
Add basic tests for .files and .run-script
 02:18
02:48 AlexDani` is now known as AlexDaniel 03:17 ufobat_ joined 03:18 p6bannerbot sets mode: +v ufobat_ 03:21 ufobat___ left
Geth rakudo: e2e5cc53c7 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationRepository.pm6
Use absolute path when spawning $*EXECUTABLE

perl6 might have been invoked as e.g. 'install/bin/perl6', which is what $*EXECUTABLE would stringify to. But if the cwd gets changed at run time then the command for precompiling would fail.		 04:40
05:03 cognomin_ joined 05:04 p6bannerbot sets mode: +v cognomin_ 05:06 cognominal left 06:54 reportable6 left 06:55 reportable6 joined, ChanServ sets mode: +v reportable6 06:56 p6bannerbot sets mode: +v reportable6 07:58 dct joined, p6bannerbot sets mode: +v dct 08:10 dct left 08:57 lizmat joined, p6bannerbot sets mode: +v lizmat
jnthn mornfall: Why would on-close not be a right way? 09:49
I mean, if using a supply block then the `CLOSE` phaser is probably more natural 09:50
mornfall jnthn: no idea, but apparently it has to do with multiple taps... can you look at the PR?
github.com/rakudo/rakudo/pull/2529 09:51
jnthn Which PR?
Oh, I see 09:52
Yeah, `on-close` is per tap, the resource here is not being created per tap, which is a problem
I'd rewrite it using the `Supply.on-demand` method so it does one nqp::watchfile per tapping, and then it'll be fine. 09:53
There's generally an expectation that each tapping is a new subscription/resource.
So it's not the on-close that's wrong, so much as everything else there :) 09:54
mornfall okay, i can have a look at that, presumably it's not urgent
jnthn Only if it's urgent for something else you're doing ;) 09:55
10:01 brrt joined 10:08 brrt left 10:18 Tux__ is now known as |Tux|
|Tux| Rakudo version 2018.11-76-ge2e5cc53c - MoarVM version 2018.11-38-gfa3411007
csv-ip5xs0.924 - 0.935
csv-ip5xs-207.152 - 7.238
csv-parser21.662 - 21.948
csv-test-xs-200.431 - 0.433
test6.969 - 7.277
test-t1.727 - 1.730
test-t --race0.770 - 0.775
test-t-2029.724 - 30.706
test-t-20 --race9.190 - 9.426
 10:19
Ulti snap my tests take 1.71s to run :D 10:40
it can also take that long to just do `say ""` at the moment on my machne so its probably running really quite fast 10:41
10:42 dogbert2_ left
lizmat .tell nine stackoverflow.com/questions/538126...er-program 10:43
yoleaux lizmat: I'll pass your message to nine.
11:54 dogbert2_ joined 11:55 p6bannerbot sets mode: +v dogbert2_ 11:58 lucasb joined, p6bannerbot sets mode: +v lucasb
lizmat notable6: weekly 13:58
notable6 lizmat, No notes for “weekly”
lizmat wow
Geth rakudo: 631940c7be | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Make all read/write-int offsets uint

This has no runtime meaning yet, but it possibly could in the future. For now it just shows intent.		 14:43
rakudo: 38afa2d6f0 | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Some more type tightening
 14:56
lizmat m: blob8.new(255).read-int8(0,1) # one of the weirder error messages I've ever seen 16:27
camelia Lexical with name '$offset' has a different type in this frame
in block <unit> at <tmp> line 1
lizmat m: sub a(uint $foo, Endian $) { }; a 0, 1 # golf 16:28
camelia Lexical with name '$foo' has a different type in this frame
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a(uint $foo, Bool $) { }; a 0, 1 # further golf 16:29
camelia Lexical with name '$foo' has a different type in this frame
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: sub a(int $foo, Bool $) { }; a 0, 1 # seems to be related to the use of "uint"
camelia Type check failed in binding to parameter '<anon>'; expected Bool but got Int (1)
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
Geth rakudo: lizmat self-assigned Custom multi infix:<~> not working as expected github.com/rakudo/rakudo/issues/2548
848932df2b | (Elizabeth Mattijsen)++ | src/core/Buf.pm6

Weird error occurs when specifying the endianness as an integer if the first parameter is a "uint".
   sub a(uint $foo, Bool $) { }; a 0, 1
   # Lexical with name '$foo' has a different type in this frame		 16:34
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/12/17/...-designed/ 16:46
moritz: ^^ 16:55
nine Very odd indeed 17:09
yoleaux 10:43Z <lizmat> nine: stackoverflow.com/questions/538126...er-program
Geth roast: d91dcd8512 | (Elizabeth Mattijsen)++ | S03-buf/write-num.t
First batch of buf8.writenum32/64 tests

They mostly fail :-(		 17:33
lizmat nine: ^^^ I would almost come to the point of removing read-num/write-num from the release as they're severely broken 17:34
m: my $b = buf8.new; $b.write-num64(0,1e0); say $b.read-num64(0) # this does not round-trip 17:35
camelia 4.6071824188000174e+18
jnthn Given we're managing to assemble bytecode with nums in, I'd guess its' something about read-num64 that's wrong. 17:39
m: my $b = buf8.new; $b.write-num64(0,1e0); dd $b
camelia Buf[uint8] $b = Buf[uint8].new(0,0,0,0,0,0,240,63)
jnthn Yeah, those seem correct 17:42
lizmat m: my $b = buf8.new; $b.write-num32(0,1e0); dd $b # jnthn, does that look ok to you > 17:49
camelia Buf[uint8] $b = Buf[uint8].new(0,0,0,0,0,0,240,63)
jnthn Yes. 17:50
lizmat m: my $b = buf8.new; $b.write-num32(0,1e0); dd $b # jnthn, does that look ok to you? looks like it's writing 64bit ?
camelia Buf[uint8] $b = Buf[uint8].new(0,0,0,0,0,0,240,63)
jnthn It's the read that's the problem and I can kind of see why
Oh
Yeah, actually the 32-bit num writing doesn't seem to be implemented on either side
lizmat ah, ok, well that explains then :-)
jnthn I can at least fix the 64-bit one to round-trip though :)
lizmat that would be nice :-) 17:51
jnthn I wonder if endianness matters for floating point... 17:52
lizmat has no idea 17:53
AlexDaniel reportable6: 2018-12-10T00:00:00Z 2018-12-17T00:00:00Z 18:04
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel lizmat: maybe this can be added for completeness ↓
although I'm not sure how empty it is too!
reportable6 AlexDaniel, gist.github.com/b2e6e94e44296220e8...d456b4d767 18:05
AlexDaniel that's a lot of stuff :)
Kaiepi: github.com/rakudo/rakudo/issues/25...-447941959 18:09
lizmat AlexDaniel: added, thanks! 18:12
Kaiepi commented AlexDaniel
AlexDaniel oh. 18:14
Kaiepi: if it no longer happens then personally I don't care! :)
jnthn lizmat: Running spectest, but think I've got it at least a bit better for 64-bit read and 32-bit read/write
lizmat jnthn: the read-num/write-num tests are not part of t/spectest.data yet, you will need to run them manually 18:15
jnthn I'll leave that to you :)
lizmat oki
jnthn github.com/MoarVM/MoarVM/commit/987269ea9f 18:16
I'm off home, just thought I'd have a poke before I go. :)
AlexDaniel samcv: alright then, we're ready. I'll give Blin another chance to find something (should be ready in ≈1 hour then), but otherwise there are no blockers left
wait did that moarvm commit just land on master? :) 18:17
jnthn Sure
AlexDaniel “This might need tweaking for big endian platforms”?
jnthn It's touching stuff that didn't exist in the last release :)
So there's no way it can be a regression.
AlexDaniel alright 18:19
Geth nqp: 6e229d8d2f | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] 987269ea9 Get readnum working, t […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g987269ea9
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g987269ea9
rakudo: eb31db95b6 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] 6e229d8d2 [MoarVM Bump] 987269ea9 G […]

NQP bump brought: github.com/perl6/nqp/compare/2018....g6e229d8d2
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g6e229d8d2
lizmat AlexDaniel++ 18:20
lucasb
.oO( How big are those endians anyway?! )
 18:21
timotimo would you rather fight a hundred small endian chickens or one really big endian chicken?
er
jnthn oh, right, chicken...I was meant to go for dinner :)
timotimo would you rather fight a hundred little endian chickens or one really big endian chicken?
jnthn bbl 18:22
lizmat
.oO( big endian chickens give larger eggs )
Geth roast: 77da1465dd | (Elizabeth Mattijsen)++ | S03-buf/read-num.t
Remove now unnecessary try's
 18:27
lizmat jnthn++ looking good!
Geth rakudo: e96b7ffed4 | (Elizabeth Mattijsen)++ | t/spectest.data
Run read-num/write-num tests also

As they are clean now		 18:35
nine Ah, of course. C is just too magical. We need a real low level language :) 18:49
lizmat: btw. still working on the writeint fix I promised on Saturday. Fighting with a regression on Big Endian machines. 18:50
Good thing I got a PowerPC VM running, so I can debug such things
AlexDaniel nine: awesome 18:57
nine: just to clarify, everything is fine on HEAD, right?
nine AlexDaniel: writeint/writeuint don't behave correctly in an error condition. But nothing bad 19:18
AlexDaniel samcv: yeah, Blin is clean 20:02
mmm hooold on… 20:25
AlexDaniel checks r-j again after pulling… 20:26
not that it matters to moar, but still :) 20:27
lizmat AlexDaniel: ah, perhaps we need to guard the read/write-int methods with a #if ? 20:43
AlexDaniel lizmat: here's the error: gist.github.com/AlexDaniel/1f7cb74...d33cf0db68 20:52
lizmat yeah, that needs a guard :-(
gimme a mo
Geth rakudo: e7b61aff7b | (Elizabeth Mattijsen)++ | src/core/Buf.pm6
Implement read-int/write-int and friends only on MoarVM

As the underlying nqp:: ops don't exist yet on other backends		 20:58
lizmat AlexDaniel: ^^^
AlexDaniel lizmat: thanks, testing 20:59
lizmat it should not die on that error anymore
japhb .tell jnthn I can install IO::Socket::Async::SSL on mildly older Rakudos (such as 2018.10-191-ga0cb89a72), but on a current build it hangs during testing. 21:13
yoleaux japhb: I'll pass your message to jnthn.
AlexDaniel lizmat: yeah, it's good! 21:15
japhb: hmm can't reproduce 21:21
ahhhh maybe I can 21:22
21:25 ufobat_ left
AlexDaniel ok I don't know :) Its tests are weird 21:26
21:26 ufobat_ joined, p6bannerbot sets mode: +v ufobat_
AlexDaniel in Blin, it's in this list of modules “These seem to hang and leave some processes behind” 21:27
so I guess that was the case for a long time
21:28 lucasb left 21:33 ufobat_ left
timotimo AlexDaniel: have you considered cgroups for blin? %) 21:45
AlexDaniel timotimo: sure but someone needs to do it… 21:48
Geth nqp: 355847eca1 | (Stefan Seifert)++ | t/moar/13-writeint.t
Add tests for writeint of negative numbers
nine The regression was about writing negative 16 bit numbers. 21:49
timotimo of course, as always :)
lizmat hmmm... why didn't the rakudo write-int16 tests not pick that up ?
nine lizmat: do those tests involve endian switching? 21:50
lizmat yup all sorts of endians: native big little and no endian specified
when did this happen ? 21:51
nine It's possible that I didn't run these tests. The regression was in the unpushed fix for the bug you reported on Saturday 21:52
In the PowerPC VM I build and run only NQP. Don't have the patience for building rakudo :)
lizmat ah, ok, so I shouldn't worry about the tests missing cases ?
21:52 dct joined, p6bannerbot sets mode: +v dct
lizmat fwiw, I'm playing around with a generic read-bits functionality 21:53
nine tests are probably fine, yes 21:55
jnthn .
yoleaux 21:13Z <japhb> jnthn: I can install IO::Socket::Async::SSL on mildly older Rakudos (such as 2018.10-191-ga0cb89a72), but on a current build it hangs during testing.
jnthn I can repro this too :/
Is there any way to use bissectable to hunt this? 22:00
timotimo if not bisectable, then at least blin, right? 22:02
or is blin for bisecting the module only?
jnthn Dunno. 22:03
I'm now trying to do a build from just before the last change in that commit range to IO::Socket::Async, which is the first most likely candidate to suspect in recent commits
(Between the one mentioned as working)
timotimo you can definitely use whateverables builds 22:04
shareable6: HEAD~5 22:05
shareable6 timotimo, whateverable.6lang.org/HEAD~5
AlexDaniel timotimo: yeah you can use blin, if of course you uncomment that line that skips this module… 22:08
but if it hangs then I'm not sure if it's going to behave well 22:09
jnthn Darn it, for the commit I picked, I built the NQP_REVISION and MOAR_REVISION it suggested at that Rakudo commit, and all tests fail with Unhandled exception in code scheduled on thread 6 22:10
Too many positionals passed; expected 6 arguments but got 7
That's as much patience as I have this evening to look in to it.
timotimo can you tell us the commit? i can perhaps continue where you stopped?
though for the moment there's a cat on my lap that just five minutes ago demanded access 22:11
jnthn timotimo: I just picked one, 2fd90b1eccdb, which was before the merge commit that changed IO::Socket::Async
OK, I suspected it may be a4db91394f but reverting that doesn't help 22:20
(Had to do a MoarVM revert also to go with it, but even with that, still the hang) 22:21
Out of time for now...but at least we know what it isn't. I don't have any other commits that look likely candidates, so bissect is probably the best thing for it.
timotimo OK, the cat had enough, and i'm full of hair everywhere 22:45
AlexDaniel ===> Install [FAIL] for OpenSSL:ver<0.1.21>:auth<github:sergot>: No installing backend available
hmm what does that mean…
timotimo zef too old? :D 22:46
23:07 go|dfish left 23:12 go|dfish joined, p6bannerbot sets mode: +v go|dfish 23:20 dct left
AlexDaniel yeah that went away after upgrading zef 23:39
timotimo cool. 23:47
do we have something like a role i can just mix into an object and have every method call done to it written to the console? kind of like grammar::tracer?

Powered by Cro and the Raku® Programming Language.

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

Thank you!