22 Jan 2019
lizmat checks for repeatability 14:24
leont Essentially all IO is Proc::Async, which doesn't have a close method. 14:25
lizmat hmmm.... 14:26
leont If something has to be closed, I wouldn't know where in my code that could happen
lizmat good point
leont Also, I don't remember seeing that error previously (though I haven't tried in a while), so that's smelling like a regression in rakudo/moarvm
lizmat yeah, repeatable 14:27
b2gills To close Proc::Async you close all of the handles 15:26
lizmat b2gills: and how do you do that? $proc.stdout.tap.close ? 15:42
leont That would certainly need to be documented 16:27
But it still doesn't make sense to me. The pipe should be closed automatically on EOF. Keeping it open never makes sense. 17:08
lizmat fwiw, I agree :-) 17:10
b2gills proc.stdout.close 17:33
lizmat b2gills: No such method 'close' for invocant of type 'Proc::Async::Pipe' 17:34
b2gills Actually proc.stdin.close usually is enough for the program to terminate
lizmat you probably meant: proc.stdout.tap.close ?
b2gills Maybe its Proc I'm thinking fo 17:35
of
lizmat that's nowadays a shim for Proc::Async
24 Jan 2019
leont Is there anything left in perl6-land that uses blib? If not I'll rip support for it out of prove6. 23:27
Is there anything left in perl6-land that uses blib? If not I'll rip support for it out of prove6. 23:35
6 Feb 2019
lizmat: I think I figured out where your out-of-filedescriptor bug with harness6 comes from, and the fix is fairly easy, though I haven't been able to reproduce it yet 19:49
lizmat leont++ 19:51
leont Unlike prove6, harness6 ignores stderr. To do this it opens /dev/null for every test, but doesn't close it.
Most obvious solution would be to open it only once, and reuse that handle 19:52
lizmat aha!
yup, that sounds like a plan: I guess multiple threads writing on that will not have any synchornization issues :-)
leont On second though, it's probably even better to write my own IO::Handle that noops. I don't think anything really depends on the handle being a true handle 19:53
Erm, no i can't, because it needs a real fd for Proc::Async. devnull it is… 20:05
7 Feb 2019
Crap, my fix doesn't appear to fix it 01:04
Though eliminating the :err('ignore') argument does seem to prevent the error (when I set ulimit -n to 64), so the problem analysis was probably correct. 01:05
It is kind of shocking how many warnings I see now though
It seems the state variable isn't doing what I expect, that is weird… 01:20
Found it. A rakudobug in state… 01:49
Either that, or state does something very different from what I expected it to do 01:50
lizmat leont: state wrt multithreading is known to be racy :-( 09:01
8 Feb 2019
leont So, the file descriptor issue is now definitely fixed 22:27
19 Feb 2019
TreyHarris If this should go to #perl6, please lmk, but I in starting to package up a module for upload, I noticed that my use of META6.pm6 meant that every time I made any change to my META6, the resulting json's order got shuffled. Is there an easy way to keep it stable so I don't have so many useless diff lines? Digging about the code in META6 didn't show me a 'sort' option or something... 21:29
Ah, I see it probably isn't the right channel. Sorry about that. 21:35
20 Feb 2019
tyil TreyHarris: if you manually update the META6.json, you can manually maintain the ordering 09:55
if you use a toold to update the META6.json, which tool are you using? 09:56
28 Feb 2019
TreyHarris tyil: sorry, I missed your question ("if you use a toold to update the META6.json, which tool are you using?") before. I'm using META6.pm 23:59
1 Mar 2019
tyil ah 08:05
I don't think it has an option to maintain the ordering
I just use JSON::Fast in App::Assixt to parse the META6.json structure, and added code to JSON::Fast to optionally sort the keys, so the order stays the same whenever it's updated 08:06
28 Aug 2019
domidumont Hi, On Debian/unstable with libuv 1.30.1, rakudo fails installation with "No writeable path found, /home/domi/debian-dev/build-area/rakudo-2019.07.1/debian/rakudo/usr/lib/perl6/core not writeable" 09:00
We've seen this problem occurs with rakudo 2018.12 and 2019.07
For instance see this build log buildd.debian.org/status/fetch.php...&raw=0 09:01
Note that rakudo 2018.12 did build fine with libuv 1.24.1 09:03
Any idea on how to fix this issue ?
kawaii domidumont: you may want to ask in #perl6 instead, this channel is unused :) 09:11
domidumont kawaii: ok, thanks 09:16
30 Sep 2019
tbrowder .seen ugexe 13:58