Byte compiler error

[rmkaplan]

I have been having trouble with the somewhat tricky algorithm that makes sure that multibyte characters in TEDIT pieces don't cross buffer boundaries of the underlying file.

I have finally determined that the code works interpreted and it works when compiled with the commonlisp compiler (DFASL). But it fails when compiled with the byte compiler (LCOM).

This is FNS and not FUNCTION, and doesn't use any special commonlisp facilities (other than CL:WHEN/UNLESS/IF).

Is there any point in someone looking at the compiled code, or are the code sequences generally so different that that would be useless.

Not sure how to proceed. I could work around this obstacle to pushing Tedit, by putting this particular function on a separate file in Tedit, and DFASL just that one. Otherwise, Tedit is all Interlisp/LCOM.

[masinter]

Pavel Curtis seems to have been the main author of the Medley Common Lisp compiler. I managed to get 10 minutes of Q&A and he said that the Common Lisp compiler was complete, and was intended to replace the old "Interlisp" compiler (it would compile Interlisp fine) and that any remaining LCOMs instead of DFASLs was there mainly because of bootstrapping. (At least that is my memory of what Pavel said in about 2022.)

I don't know how the two compilers differ -- I just haven't looked. Whether the code produced by the two are different or very similar is a good question.

I think one way to proceed is to CL:COMPILE-FILE TEdit and fix things that don't work.
That you can't LOADFNS from a DFASL shouldn't be that hard to overcome.

The main thing to check is the CALLSCCODE on the two compiler outputs -- if SPECVARS and GLOBALVARS are different, that might be a problem.

[rmkaplan]

This problem seems to have disappeared, I'll close it for now. If it recurs, it will probably show up by typing "man FOO" in the new Tedit. (man FOO in current Tedit is garbage because it's a 2-byte character straddling a buffer boundary)

[rmkaplan]

Comment above

[masinter]

I'd like to get into the position where we can compile EVERY source of Medley with "cross compilation" so that we can change the opcodes and move forward. Situations like this one should be avoided, where we don't know what caused the problem.

One of the difficulties is that in normal operation, we don't recomile everything that might have been affected by a changed macro -- which can lead to situations where the compiled version works fine until you recompile it, or vice versa.

In any case, if the situation isn't reproduceable any more it's fine to close the issue but "Close as not planned" is better than "Close as Completed"