medley
medley copied to clipboard
Interlisp
NIL is not a NUMBER in FFILEPOS
The problem isn't that BYTECOUNTER is initialized to NIL in \SLOWFILEPOS. The problem is in \XCCSINCCODE, the function that reads character codes in files in external format :XCCS. If that function is called with COUNTP T, which it is, then it is assumed that it will set BYTECOUNTER to the number of bytes it read to produce the character.
In this case, for this file, it is not setting that variable. And that's because the file is not a valid XCCS file. At the byte position 619579 where I see the failure, there is a string of about 40 255 bytes all in a row.
I would have expected to see an error in that case, but I don't think I checked for that bogus configuration. I suppose the solution when it can't interpret an initial 255 as a valid shift is to return 255 as the character, and say that it took only one byte?
(FILESLOAD GREP) cd medley/docs/medley-irm/ (GREP 'LISPXHIST "*.TEDIT)
gives an error. The medley-irm isn't a XCCS file??
Presumably the plaintext parts of IRM Tedit files are XCCS, but the binary formatting parts are not. (BTW, Tedit can now produce UTF-8 plaintext parts).
Apropos of the discussion about exposing the byte pointer to the beginning of the format information, GREP could stop searching at that point.
On Jan 15, 2024, at 1:43 PM, Larry Masinter @.***> wrote:
(FILESLOAD GREP) cd medley/docs/medley-irm/ (GREP 'LISPXHIST "*.TEDIT)
gives an error. The medley-irm isn't a XCCS file??
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1496#issuecomment-1892794120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJYX3Y3GZQKF5EYYTDYOWPGNAVCNFSM6AAAAABBXCDLY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSG44TIMJSGA. You are receiving this because you commented.
With respect to having GREP do something useful on (most) Tedit files, if TEDIT.FORMATTEDFILEP is available, either because it is dummied to NILL or 4th-round Tedit is loaded, then calling FFILEPOS with (CAR (TEDIT.FORMATTEDFILEP stream)) as the END argument should cause it to stop searching before it enters the binary formatting part of the stream. NIL is returned if stream is not a Tedit-formatted file, so in that case it will go to the EOF.
The only glitch is the fact that since 1985 Tedit has been writing what may be binary imageobject descriptions in the plaintext part. Eventually I want to change it so the plaintext part contains the object's preprint characters, with the binary description stored in the formatting part, but that file-format won't be backward compatible.