|
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 | ||
| yup | |||
| so you can develop in parallel | 21:07 | ||
| japhb | Yeah, though it feels like none of this should be necessary. | ||
| nodnod | |||
| 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 | |
| HOWEVER ... | |||
| 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 | |
| *precomp | |||
| 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 ...` | |||