Block compile

[Ron Kaplan]

I saw this in the Fathom summary:

• Block Recompiles Cause Bugs: b-comple is creating a mismatch between source and compiled code, causing bugs. The fix is to recompile the entire system from scratch to ensure consistency.

I don't think that's the problem. BCOMPL and BRECOMPILE are equivalent to TCOMPL and RECOMPILE if the file doesn't have block declarations--i.e. run the same code. And there aren't that many block declarations floating around. (It would be good to eliminate those that are left, since the original performance advantage has disappeared and packages are a better way of dealing with runtime name hiding--but that's a separate issue)

There have been longstanding problems in the interactions of SEDIT, EDITDATE, DWIM, and FILEPKG. For example, SEDIT sometimes shows you have made a change, but the underlying data structure doesn't have the modification. Sometimes the underlying data structure simply disappears. I think that's what we need to address.

It would be good to recompile the whole system, but I don't think that would change the behavior that raised this concern.

[Larry Masinter]

We have the risk of compiled code not matching the source code in Medley files.

There are several ways in which that mismatch might be introduced, one of which is the use of "recompile" where the recompile list isn't complete.   There are quite likely several ways which would lead to a mismatch, but determining how it happened in the past doesnt seem to be as important as insuring that it doesn't happen in the future -- e.g., by instituting a workflow or process steps prior to compile sources fully (no RECOMPILE or BRECOMPILE).  

Ways of missing out functions/code that need recompiling include changing values marked CONSTANT, changing macros, changing variables whose value is used by a DEFMACRO definition.

When a current file has a LCOM or a DFASL where the compiled code doesn't match the source, it's a kind of mine ... where the loadup works but if you compile from scratch you'll get a failure unrelated to anything in source file.

https://LarryMasinter.net  https://interlisp.org

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/8A0CFD45-036B-4656-9B31-7768840394F4%40post.harvard.edu.

[Ron Kaplan]

There may a problem of compile vs recompile, but I don't think it's block vs nonblock.

If we always compile everything (no recompile), we should change the compiler printing (also for DFASL) so that it doesn't bury exceptional information (unbound variables, unknown functions...) in a long list of function names and redefine messages.   (I think there is an email from Danny in the archives, from the 70's or 80's, complaining about the junk that we see).

To view this discussion visit https://groups.google.com/d/msgid/lispcore/CAKq15vfSymuHUg7yOJnHcfGzM44XZCo-MsoKi%3DsewTdT2YT72Q%40mail.gmail.com.