[racket] racket loader/vm detecting out-of-date cached compiled files

I also get similar "bad variable linkage" errors frequently with Racket. Deleting the "compiled" folder is always the cure. But it's not obvious from the error message why that should be so.


On Sep 9, 2014, at 1:33 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:

> Is there any low-hanging fruit for making the command-line Racket detect more cases in which some of the compiled files are out-of-date?
> 
> Details...
> 
> I have run into a few instances of undetected out-of-date compiled Racket code a few times in the last year.
> 
> For example, today, after sys-admin did a code patch a production server, one part of the system gave this error when it was run:
> 
>    link: bad variable linkage; reference to a variable that has the wrong procedure or structure-type shape
> 
> My guess in this case is that either the code was not recompiled (though it should be when they do "make run" of the system), or that the compile was wrong because the file mtimes were wrong (such as might happen with SVN with clock skew, or with "tar").  This was with Racket 5.3.4.  (Incidentally, this particular system has a large number of files and a somewhat funny dependency graph, possibly bigger than DrRacket's or any other core Racket code.  But my guess is that's not the cause of this problem.)
> 
> We also ran into out-of-date compiled files once before in production, in the last year.  Also involving some kind of update to the source files.
> 
> And I have run into out-of-date compiles in development of my open source code and personal apps, perhaps several times in recent years.  Usually when using DrRacket (perhaps alternating between DrRacket and command-line "racket"), and probably when I was doing heavy syntax transformer work (especially when the module-file graph was messier, before submodules simplified that greatly).  Sometimes, it was obvious from things in error messages that an old compiled version of the code was being picked up from somewhere.
> 
> This is not a huge problem, but if there's some easy and efficient checks that could be added, that would be a win.  (Maybe there's already something like a file "stat" of source and corresponding compiled files, and some knowledge of the dependency graph that's consulted.  If that's bulletproof, then I wonder whether it would make sense to supplement the mtime checking with checking embedding timestamps embedded *within* the compiled files, consulted separately from the mtimes.  Though embedded timestamps might be significant work to do, when it's unclear whether bad mtimes are actually a problem for anyone in practice.)
> 
> Neil
> 
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users