Geth rakudo/ugexe-patch-3: ca0b8fcd02 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.pm6
Fix 'too many open files' during module uninstall

Recently uninstalling modules might give a 'too many open files' error. By making a call to `.dir` eager this error goes away, although I'm not clear why or what changed in e.g. libuv that would require this now.		 00:09
rakudo: ugexe++ created pull request #4333:
Fix 'too many open files' during module uninstall		 00:10
00:55 japhb left, japhb_ joined 01:11 kvw_5 joined 01:14 kvw_5_ left 01:30 japhb_ left 01:32 japhb joined 01:34 lucasb left 01:48 MasterDuke left 02:51 japhb left 02:53 japhb joined 03:56 sivoais left 04:08 sivoais joined 06:06 softmoth left
Geth rakudo: 62c976a43c | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Oops, forgot to close the dir handle

For the case of a IO::Path.dir with an explicit test in e.g. a for loop or anything else that would call .pull-one on the iterator.
Related to #4333		 08:08
08:08 linkable6 left
nwc10 Well d'oh! I expect that explains a lot :-) 08:09
lizmat actually, no 08:10
but it was at least an oversight
it does *not* fix #4333 08:11
08:11 linkable6 joined
lizmat question is really: if a Rakudo::Iterator::Dir object gets garbage collected, will it properly garbage collect $!dirhandle if it is still open 08:13
nwc10: any ideas on how to check that ?
or do we need a DESTROY method on it ? 08:14
if it does garbage collect the $!dirhandle correctly even when it's open, then we don't need a DESTROY method
nwc10 it's a good question, and I don't know 08:16
nine If I'm reading the code correctly, the answer is a bit surprising: we do close a directory handle when it's garbage collected but do not do so with file handles. 08:18
lizmat that feels like an even bigger oops ?
nine Not necessarily. IO::Handle does have a DESTROY that closes. And that may show us why we leave that to the HLL: it doesn't close STDIN, STDOUT and STDERR. 08:19
Which is a good thing I dare say 08:20
lizmat so that would mean the dir iterators do *not* need a DESTROY 08:23
although one could argue that maybe HLL should also be responsible for this?
in which case a DESTROY method *would* be necessary ?
08:28 MasterDuke joined
Geth rakudo: e9e3b5fba6 | (Elizabeth Mattijsen)++ | src/core.c/SetHash.pm6
Fix #4332

Turns out a check on number of elements was forgotten in this case.		 08:36
roast: dffc2a4cec | (Elizabeth Mattijsen)++ | S02-types/sethash.t
Add test for #4332
08:36 linkable6 left
nine The current implementation probably assumes that there is no good reason _not_ to close a dir handle in gc_free. 08:37
08:38 linkable6 joined
MasterDuke should gc_free check it's not STD(IN|OUT|ERR)? 08:40
nine lizmat: even if we close the dir handle when it's garbage collected, it's quite possible that we run out of file descriptors long before that GC run happens. Especially if those dir handles make it into the 2nd generation. 09:18
lizmat nine: but a DESTROY method wouldn't help with that, would it ? 09:20
nine no 09:21
lizmat so basically: if IO::Path.dir { 09:22
as a way to see if there are directory entries in there, is bad
otoh, if IO::Path.dir.elems {
nine Unless we can make it safe. You seem to have ideas on that already :) 09:23
lizmat is wasteful, because it would read all entries in the dir (potentially many)
well... it *could* still break code
my $dir = "foo".IO.dir; if $dir { for $dir -> $entries } 09:24
would break
unless, I guess, the iterator would know to re-open the dir
09:28 domidumont joined 10:07 patrickb joined
lizmat meh: you create specialized native candidates in a role, and then find out that all of the performance gained is lost in a repeated call to "accept_type" in the Metamodel :-) 10:40
:-( rather
11:03 patrickb left
lizmat afk& 11:22
13:05 frost-lab joined
MasterDuke DateTimes and Instants could/should be value types, right? 13:15
13:17 domidumont left 13:21 b2gills left 13:47 MasterDuke left 13:55 MasterDuke joined 14:01 b2gills joined 14:19 lucasb joined 14:40 frost-lab left 14:45 softmoth joined
[Coke] sees something about his module catching a bug? 14:51
looks like it's an actual bug and not "unicode added another cat emoji" 14:52
MasterDuke yeah 15:10
although writing to $sieve here github.com/coke/raku-uni/blob/mast...od#L36-L37 isn't safe 15:11
because of the hypers 15:12
[Coke] good catch 15:15
nine And what a bug it is...
[Coke] MasterDuke: addeed github.com/coke/raku-uni/issues/8 15:29
lizmat [Coke]: also of interest for raku-uni: modules.raku.org/dist/uniname-word...:ELIZABETH 15:55
[Coke] I glanced at it but didn't get it. 15:56
lizmat you can drop the main loop in raku-uni 15:57
or am I missing something ?
16:16 domidumont joined
[Coke] to wrap up here (accidentally continued this in the wrong window), I wouldn't expect it to be much faster since app::uni is a single loop, but it is, but it's not quite the same logic. 16:17
sena_kun rba, ping? 16:22
lizmat Coke: $sieve = 0..0x10FFFF, $sieve.grep(*.uniname... 16:23
that's a pretty big loop :-)
sena_kun .tell rba it seems there are issues with free space on the raku-infra-fsn1-01 server. I would run something like `docker rm (docker container ls -aq)` to cleanup unused containers (this is what I think the command does), but given other services are hosted there I don't want to risk too much. Can you please look into it?
tellable6 sena_kun, I'll pass your message to rba
lizmat m: sub foo(@a) { }; my str @b; foo(@b) for ^1000000; say now - INIT now; # pretty fast 16:34
camelia 0.014332003
lizmat m: sub foo(str @a) { }; my str @b; foo(@b) for ^1000000; say now - INIT now; # not so fast :-(
camelia 1.253426504
16:34 domidumont left
lizmat m: say 1.253426504 / 0.014332003 16:34
camelia 87.456477926
lizmat so dispatching a native array to a native array is about 87x as slow? 16:35
MasterDuke lizmat: another example of github.com/rakudo/rakudo/issues/4097 ? 16:39
lizmat MasterDuke: thanks for reminding me 16:40
m: sub foo(array[str] \a) { }; my str @b; foo(@b) for ^1000000; say now - INIT now; # much faster 16:41
camelia 0.015926053
lizmat Guess I will be using that
17:16 domidumont joined 17:25 domidumont left 17:26 domidumont joined
Geth rakudo: 74af72de24 | (Elizabeth Mattijsen)++ | src/core.c/Baggy.pm6
Make Baggy.AT-KEY about 60% faster

Turns out that having a BEGIN thunk in a block prevents it from being inlined: target has a :noinline instruction - ins: capturele. Move the constant code to a constant, and use that instead.		 17:32
rba sena_kun: I will look into the space issue. Thank you for letting me know. 17:38
tellable6 hey rba, you have a message: gist.github.com/36474196c89c27f831...6494d15a09
17:50 domidumont left
Geth rakudo: 0bbeb2de42 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make Rakudo::Iterator.Empty about 80x as fast

The BEGIN block prevented it from being inlined. Moved the compile time value into a constant, and now it does inline. And the bytecode being very small indeed (14 bytes) it will inline quickly.
This method is called in many places where it is clear from the beginning that an iterator will never produce any values.		 17:57
lizmat there were other cases in the core, but these would still not inline for other reasons either 17:58
rba sena_kun: freeed some space 18:03
sena_kun rba++ 18:23
lizmat
.oO( that sounded like a typical bofh response :-)
 18:24
afk again& 18:30
18:43 Geth left 19:39 patrickb joined 20:19 patrickb left
samcv Hi everyone. Just wanted to announce that the PaperCall for the 2021 Perl and Raku Conference is open. So far we only have 1 Raku talk, and we would really love if we got more submissions from the Raku community. Thanks www.papercall.io/tprcic21 20:35
21:44 lizmat left, lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!