00:16 sxmx joined 00:40 squashable6 left, squashable6 joined 01:18 kvw_5 joined 01:21 kvw_5_ left 01:22 squashable6 left 01:24 squashable6 joined
releasable6 Next release in ≈6 days and ≈15 hours. 3 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
04:55 summerisle left 04:56 summerisle joined 05:11 softmoth left 05:28 epony left 05:29 epony joined 07:19 donaldh_ joined 07:21 donaldh left 09:11 benchable6 left, bloatable6 left, committable6 left, shareable6 left, nativecallable6 left, sourceable6 left, quotable6 left, bisectable6 left, evalable6 left, greppable6 left 09:12 coverable6 left, unicodable6 left, linkable6 left, squashable6 left, notable6 left, statisfiable6 left, tellable6 left, releasable6 left, bisectable6 joined, sourceable6 joined, shareable6 joined 09:13 linkable6 joined, quotable6 joined, nativecallable6 joined, committable6 joined 09:14 greppable6 joined, statisfiable6 joined, unicodable6 joined, coverable6 joined, releasable6 joined, notable6 joined, tellable6 joined, squashable6 joined, benchable6 joined, evalable6 joined 09:15 bloatable6 joined
Altai-man_ releasable6, status 11:00
releasable6 Altai-man_, Next release in ≈6 days and ≈7 hours. 3 blockers. Changelog for this release was not started yet
tellable6 2021-03-08T23:14:50Z #raku-dev <vrurg> Altai-man Blin at ugexe-path-1 branch fails for me: gist.github.com/vrurg/a40d86aa09a6...5b4df3355b Will run it on master.
2021-03-09T01:25:14Z #raku-dev <vrurg> Altai-man gist.github.com/vrurg/549778525019...782ad74e8b
releasable6 Altai-man_, Details: gist.github.com/1a23b8e4437bfe6ab4...66d7b86025
tellable6 2021-03-13T21:25:52Z #raku-dev <El_Che> Altai-man In case you're preparing 2020.03, the issue you raised may be a blocker: github.com/nxadm/rakudo-pkg/issues/81
14:20 MitarashiDango[m joined 15:30 domidumont joined 16:17 softmoth joined 17:17 softmoth_ joined 17:19 softmoth left 17:23 domidumont left 18:05 b2gills left 18:33 finsternis joined 20:28 squashable6 left 20:31 squashable6 joined 20:35 b2gills joined
japhb I'm having problems doing local multi-repo development. MUGS is split into different repos: MUGS-Core, MUGS-Games, MUGS-UI-CLI, etc. When I'm doing local development that involves API changes in progress (it's only version 0.1.x, so that's still to be expected), I need to `zef install . --force` repeatedly (the --force because I'm not changing version numbers until actual release). Sometimes it seems 21:02
not to actually install my changes, so I tried uninstalling the modules and then reinstalling. Doesn't seem to work reliably.
So now what? I mean, I could specify each of my checkouts in a huge lib path, but I'd rather figure out why uninstall/reinstall cycles don't work locally. 21:03
lizmat japhb: I've been putting hard links between libraries in the "lib" directory and adding them to .gitignore in the appropriate repos 21:05
japhb There's been a few times that I built a whole new Rakudo from scratch just to insure that I had clean installs, and that's just painful.
lizmat: Wait, you're working around the same problem?
lizmat well, just making it more convenient
japhb Well at least it's not just me. :-/
lizmat an alternative would be an elaborate RAKULIB= setting ? 21:06
but that is also just meh
japhb Oh, I see, so you don't have to worry about stuff installed into the site raku, because it appears to all be in the local lib. Hmmm.
lizmat the hard links / .gitignore make it opaque
so you can develop in parallel 21:07
japhb Yeah, though it feels like none of this should be necessary.
lizmat well, didn't think much of it
otoh, perhaps a dedicated REPO that takes a config could be helpful as well
japhb I'm trying to figure out what to tell forkers to do, since asking them to wire up hardlinks and gitignore seems a bit much ... unless I supply a script to do so, I suppose. 21:08
ugexe zef nuke site 21:09
japhb ugexe: Which means reinstalling *all* of my modules, yes? There are a lot that I keep installed all the time.
Though that does save having to build Rakudo from scratch just to ensure a really truly clean site tree. 21:10
ugexe you can uninstall as many modules as you want with a single command as well
japhb Is there a way to see which files are actually removed by the uninstall?
ugexe as for the root of your issue it smells precomp related (like how you can edit source files but the old precomp code still gets ran)
japhb Yeah, I would believe that.
Can you tell zef to nuke the precomp tree and re-precomp? 21:11
(I don't remember such a thing, but I'm sure I could have missed it too.)
ugexe no 21:12
CURI needs to expose an interface for doing precomp first 21:13
japhb nod
ugexe as for what files get deleted it should be listed in rakus copy of the META6.json under the files key, as well as the short-name-lookup stuff. see github.com/rakudo/rakudo/blob/a239...n.pm6#L293
the short-name-lookup is the sha1 precomp stuff 21:14
er wait, you didnt have a problem with uninstall
github.com/rakudo/rakudo/blob/a239...#L255-L288 21:15
this is the precompilation logic on install
so i think if you did RAKUDO_LOG_PRECOMP=1 you might be able to notice if it doesn't precompile certain modules when force installing 21:16
japhb OK, that's worth a try, thanks. 21:20
Once in a while (and just now, which is why I remembered) I get this while attempting to uninstall: Failed to get the directory contents of '.../rakudo-moar-2021.03-158-gda80b57cf/install/share/perl6/site/short/F278845DC0259ECFAFE6A1D4AE3387D9AE2FAEE5': Failed to open dir: Too many open files 21:22
But I can rerun and it appears to work fine.
ugexe yeah ive seen that more lately with osx 21:24
japhb Linux Mint here. 21:25
ugexe no idea where those handles would be getting left open though
japhb Just got it again, sigh.
ugexe the only thing i can guess is the internal rakudo file recursion routine 21:26
github.com/rakudo/rakudo/blob/a239....pm6#L1294 21:27
then again i dont think there should be any recursion involved in those directories 21:31
lizmat no recursion was intended in that code, au contraire :-) 21:33
afaik, it doesn't open any files either, just directories?
japhb OK, this is a bit weird -- I'm in the habit of running tests before doing the reinstall, using && to insure that failed tests abort the reinstall. When running the tests first, I'm way more likely to get that Too many open files error than if I just do the reinstall by itself.
lizmat and it does do the closedirs
japhb So `t && zef uninstall MUGS::Games && RAKUDO_LOG_PRECOMP=1 zef install .` --> Run tests, then BOOM on the uninstall, whereas `zef uninstall MUGS::Games && RAKUDO_LOG_PRECOMP=1 zef install .` --> Works first time. 21:34
ugexe the error is specifically about opening a directory 21:40
japhb Nope, red herring. Now I'm getting it every time even without running the tests first.
lizmat m: use nqp; dd nqp::closedir(nqp::opendir("lib")) 21:43
camelia ===SORRY!===
Unhandled arg type 0
lizmat that is... weird
aah.. the problem is in dd-ing the return value of closedir 21:44
japhb WTH? This is just acting too weird. I'm going to try going back to an earlier Rakudo and see if it's something recent. 21:50
ugexe my $cur = CompUnit::RepositoryRegistry.repository-for-name("site"); my $dist = $cur.candidates("MUGS::Games").head; say $cur.uninstall($dist); 21:51
i was expecting that to work, but it doesnt seem to do anything
japhb OK, error occurs with rakudo-moar-2021.03-1-gbccb2ce2d as well, but not every time. 21:52
ugexe might be worth trying a version pre-last libuv bump 21:56
japhb OK, looking for that 22:01
Oof, it's been a bit. 22:04
--> Building Rakudo 291cc5f39~1: 2020.12-128-g3235f3e42
22:45 evalable6 left 22:48 evalable6 joined
releasable6 Next release in ≈5 days and ≈19 hours. 3 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
japhb OK, so far can't trigger the "Too many open files" bug on 2020.12-128-g3235f3e42, after several test/uninstall/install cycles in several different trees. 23:19
When I install with RAKUDO_LOG_PRECOMP=1, I can see that editing a file, saving it, and doing a reinstall does NOT change the precompile ID. Shouldn't that change? 23:20
Or is it based on the long name instead of the file contents?
(Or short name, I suppose)
ugexe: ^^ 23:22
ugexe CURFS is based on sha1 of sources, CURI is based on long name 23:23
so no you wouldn't see it change if you are installing
japhb OK, well shoot, that brings me back to the difficulty of telling whether changes are *really* happening during precompt. 23:30
At least I have a non-crashy Rakudo, even if it is old. 23:33
ugexe fwiw sometimes you might want to do `raku --ll-exception -I. bin/zef uninstall ...` 23:45
since you can't do like `RAKUDO_LL_EXCEPTION=1 zef uninstall ...`