What is the best way to flush precompiled perl6 modules?

Question

I am trying to refactor some code. My approach (using vi) is to copy my old libraries from /lib to /lib2. That way I can hack out big sections, but still have a framework to refactor.

So I go ahead and change mymain.p6 header from use lib '../lib'; to use lib '../lib2';. Then I delete a chunk of the lines in ../lib2/mylibrary.pm6 and make darn sure :w is doing what I expect.

Imagine my surprise when my program still works perfectly despite having been largely deleted. It even works when I rm -R /lib, so nothing back there is persisting.

Is there a chance that I have a precomp of the old lib module lying around? If so, how can I flush it?

This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03 implementing Perl 6.d.

Hallel

Please consider being more explicit even if @ValleLukas' answer gives you what you need so this question records something understandable by future readers. "I can delete all the lines in the lib2 version and it still works!" isn't as clear as I'm guessing you think it is. If by "the lib2 version" you mean the main program file, say main2.p6, and you're invoking perl6 main2.p6 at the command line, then what happens if main2.p6 is just use v6.c; no precompilation; say 42? – Cyndie

Hi @p6steve. In rereading my prior comment I see I expressed myself very poorly. I didn't mean to suggest your overall question, as summarized in the title, wasn't understandable. You clearly wanted a way to flush precompiled modules. What I meant was the detail in the body. As it stands I don't think your SO will help those improving Rakudo have a shot at fixing Rakudo so whatever went wrong with precompilation in your case stops happening. While you've got what you wanted, and that's what SO is meant for, it is nevertheless better for everyone if SO questions like this drive work on Rakudo. – Cyndie

hi @Cyndie - I agree - I have edited original question, so hopefully is now clear – Hallel

Answer 1

Precompiled modules are stored in the precomp directory. You can try to rename or delete the ~/.precomp directory.

See also this SO question here.

Agnate

Hi @valle - thanks for your prompt and correct answer. I first found and nuked the main perl6 install /users/me/.perl6/precomp but still that didn't do the trick. Then I noticed ../lib2/.precomp directory - so realised library precomps are stored in the library folder. That did the job! – Hallel

Answer 2

Update. Well I thought I'd replicated the scenario. It was reliably showing the bug during a one hour period. But now it isn't. Which is pretty disturbing. Investigation continues...

---

I've replicated @p6steve's scenario in case someone wishes to report this as a bug. At the moment I'm with @p6steve (per comment below) in that I'm going to treat this as a DIHWIDT rather than a reportable bug. That said, now we have a golf'd summary.

Original main program using path1 followed by the module it uses directly and then the one that uses:

use lib 'path1';
use lib1;
say $lib1::value;

unit module lib1;
use lib2;
our $value = $lib2::value;

unit module lib2;
our $value = 1;

This displays 1.

If the libs are copied to a fresh directory, including the .precomp directory, and then the lib2 is edited but the lib1 is not, the change to lib2 is ignored.

Here it is on glot.io before and after copying the libs and their .precomp directory and then editing the libs.

Original answer

Thank you for editing your question. That gives us all more to go on. :)

I'd like to try to get to the bottom of it and hope you're willing to have a go too. This (n)answer and comments below it will record our progress.

From your comment on @ValleLukas' answer:

Then I noticed ../lib2/.precomp directory - so realised library precomps are stored in the library folder. That did the job!

Here's my first guess at what happened:

You copied lib en masse to lib2. This copied the precomp directory with it.

You modified the use lib ... statement in mymain.p6 to refer to lib2.

Your mymain.p6 code includes a use module-that-directly-or-indirectly-uses-mylibrary.

You modify mylibrary.pm6.

But nothing changes! Why not?

You haven't touched module-that-directly-or-indirectly-uses-mylibrary, so Rakudo uses the precompiled version of that module from the lib2/.precomp directory.

Speculating...

Perhaps the fact that that precompiled version exists leads the precompilation logic to presume that if it also finds a precompiled version of a module that's used by module-that-directly-or-indirectly-uses-mylibrary then it can go ahead and use that and not even bother to check how its timestamp compares to the source version.

Does this match your scenario? If not, which bits does it get wrong?

Cyndie

yes - that's my understanding of what happened - I suppose I expected the cached /lib/.precomp to be invalidated when I copied it to /lib2/.precomp and then changed /lib2/mylibrary.pm6 source - so I would perhaps suggest the compiler precomp handler can grok copied lib file trees and compares to checksum of the copied source as some future enhancement - I see that mine is a bit of a corner case, so wouldn't elevate to the status of bug unless others see it that way – Hallel

Hi again @p6steve. Thanks for following up. As you can see I've now replicated it with an MRE. I'm not inclined to report it as a bug atm (and maybe it's even already been reported) but I've had my fill of it for now. :) – Cyndie