GETFN reports error can't read GETFN image object on many files #1652
Comments
|
At least in the SEDIT case, the GETFN is trying to do a simple READ at a given byte position (138210) in the backing file 16-SEDIT.TEDIT (actually in {MEDLEY}/docs/medley-ifrm/).
At that position the bytes are for the characters
(## (Function) NIL NIL (NIL) 60) COM1 COM2 ... COMN)
The read is giving an error
#NIL# encountered before #NIL=
Maybe it is reading with the wrong readtable? # is a macro in Interlisp, just OTHER in OLD-INTERLISP-FILE. With OLD-INTERLISP-FILE it returns
(## (Function) NIL NIL (NIL 60))
and maybe the ## has some particular meaning for the index.
… On Apr 6, 2024, at 9:55 PM, Larry Masinter ***@***.***> wrote:
the following files all report a GETFN error if I just call TEDIT on them.
i.e. (SETQ BADFILES (READFILE 'BADFILES.TXT))
(MAPCAR BADFILES 'TEDIT)
it seems to load the GETFN but not succeed in applying it?
it took me a long time with git bisect to convince myself that the problem was introduced in TEdit Round 4.
44e4294 <44e4294>
{MEDLEY}medley-irm>09-conditionals.TEDIT;1
{MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
{MEDLEY}medley-irm>09-conditionals.TEDIT;1
{MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
{MEDLEY}medley-irm>16-SEDIT.TEDIT;1
{MEDLEY}medley-irm>09-conditionals.TEDIT;1
{MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
{MEDLEY}medley-irm>16-SEDIT.TEDIT;1
{MEDLEY}medley-irm>09-conditionals.TEDIT;1
{MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
{MEDLEY}medley-irm>16-SEDIT.TEDIT;1
—
Reply to this email directly, view it on GitHub <#1652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO4AEOZW4VKYBWVH63Y4DGSRAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZDSNJWGI2DAMY>.
You are receiving this because you are subscribed to this thread.
|
|
conditionals and EXECUTIVE are both looking for a non-existent font, TITAN 6, so that’s causing an error when the file’s are opened, independent of the image objects. The smallest Titan is 12.
Some sort of coercion must have been happening before, I don’t remember how that is supposed to be handled, or what might have changed.
FONTSAVAILABLE returns NIL, but then what?
… On Apr 6, 2024, at 11:21 PM, Ron Kaplan ***@***.***> wrote:
At least in the SEDIT case, the GETFN is trying to do a simple READ at a given byte position (138210) in the backing file 16-SEDIT.TEDIT (actually in {MEDLEY}/docs/medley-ifrm/).
At that position the bytes are for the characters
(## (Function) NIL NIL (NIL) 60) COM1 COM2 ... COMN)
The read is giving an error
#NIL# encountered before #NIL=
Maybe it is reading with the wrong readtable? # is a macro in Interlisp, just OTHER in OLD-INTERLISP-FILE. With OLD-INTERLISP-FILE it returns
(## (Function) NIL NIL (NIL 60))
and maybe the ## has some particular meaning for the index.
> On Apr 6, 2024, at 9:55 PM, Larry Masinter ***@***.***> wrote:
>
>
> the following files all report a GETFN error if I just call TEDIT on them.
>
> i.e. (SETQ BADFILES (READFILE 'BADFILES.TXT))
> (MAPCAR BADFILES 'TEDIT)
>
> it seems to load the GETFN but not succeed in applying it?
>
> it took me a long time with git bisect to convince myself that the problem was introduced in TEdit Round 4.
> 44e4294 <44e4294>
> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
>
> —
> Reply to this email directly, view it on GitHub <#1652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO4AEOZW4VKYBWVH63Y4DGSRAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZDSNJWGI2DAMY>.
> You are receiving this because you are subscribed to this thread.
>
|
|
I think TITAN is an NS font, and may have been coerced to TERMINAL for non-existant sizes (and we do have TERMINAL 6)
When I try to set a piece of text as TITAN font, TEdit breaks trying to set the font to new looks (FONT NOBIND)
… On Apr 7, 2024, at 10:52 AM, rmkaplan ***@***.***> wrote:
conditionals and EXECUTIVE are both looking for a non-existent font, TITAN 6, so that’s causing an error when the file’s are opened, independent of the image objects. The smallest Titan is 12.
Some sort of coercion must have been happening before, I don’t remember how that is supposed to be handled, or what might have changed.
FONTSAVAILABLE returns NIL, but then what?
> On Apr 6, 2024, at 11:21 PM, Ron Kaplan ***@***.***> wrote:
>
> At least in the SEDIT case, the GETFN is trying to do a simple READ at a given byte position (138210) in the backing file 16-SEDIT.TEDIT (actually in {MEDLEY}/docs/medley-ifrm/).
>
> At that position the bytes are for the characters
> (## (Function) NIL NIL (NIL) 60) COM1 COM2 ... COMN)
>
> The read is giving an error
> #NIL# encountered before #NIL=
>
> Maybe it is reading with the wrong readtable? # is a macro in Interlisp, just OTHER in OLD-INTERLISP-FILE. With OLD-INTERLISP-FILE it returns
> (## (Function) NIL NIL (NIL 60))
> and maybe the ## has some particular meaning for the index.
>
>> On Apr 6, 2024, at 9:55 PM, Larry Masinter ***@***.***> wrote:
>>
>>
>> the following files all report a GETFN error if I just call TEDIT on them.
>>
>> i.e. (SETQ BADFILES (READFILE 'BADFILES.TXT))
>> (MAPCAR BADFILES 'TEDIT)
>>
>> it seems to load the GETFN but not succeed in applying it?
>>
>> it took me a long time with git bisect to convince myself that the problem was introduced in TEdit Round 4.
>> 44e4294 <44e4294>
>> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
>> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
>> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
>> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
>> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
>> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
>> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
>> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
>> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
>> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
>> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
>>
>> —
>> Reply to this email directly, view it on GitHub <#1652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO4AEOZW4VKYBWVH63Y4DGSRAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZDSNJWGI2DAMY>.
>> You are receiving this because you are subscribed to this thread.
>>
>
—
Reply to this email directly, view it on GitHub <#1652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWNGJIGEBPRKINAQHTDY4GBXLAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGU2DIMRUGY>.
You are receiving this because you are subscribed to this thread.
|
|
The NOBIND was a parenthesis typo.
But there is still the question of how/where the coercion is supposed to happen, if somewhere it is defined that non-existent Titan goes to Terminal or somewhere there is a more general coercion pathway.
Otherwise, I can fix the Tedit reader so that it maps any nonexistent font to DEFAULTFONT, with an alert message instead of a break.
What I also don’t understand is how these Titan 6 references got into these old IRM files. The font must have existed at the time these files were created, else there would have been an error when it was specified. So either we had the font and it disappeared, or these files are corrupted in some way.
… On Apr 7, 2024, at 11:45 AM, Nick Briggs ***@***.***> wrote:
I think TITAN is an NS font, and may have been coerced to TERMINAL for non-existant sizes (and we do have TERMINAL 6)
When I try to set a piece of text as TITAN font, TEdit breaks trying to set the font to new looks (FONT NOBIND)
> On Apr 7, 2024, at 10:52 AM, rmkaplan ***@***.***> wrote:
>
>
> conditionals and EXECUTIVE are both looking for a non-existent font, TITAN 6, so that’s causing an error when the file’s are opened, independent of the image objects. The smallest Titan is 12.
>
> Some sort of coercion must have been happening before, I don’t remember how that is supposed to be handled, or what might have changed.
>
> FONTSAVAILABLE returns NIL, but then what?
>
>
> > On Apr 6, 2024, at 11:21 PM, Ron Kaplan ***@***.***> wrote:
> >
> > At least in the SEDIT case, the GETFN is trying to do a simple READ at a given byte position (138210) in the backing file 16-SEDIT.TEDIT (actually in {MEDLEY}/docs/medley-ifrm/).
> >
> > At that position the bytes are for the characters
> > (## (Function) NIL NIL (NIL) 60) COM1 COM2 ... COMN)
> >
> > The read is giving an error
> > #NIL# encountered before #NIL=
> >
> > Maybe it is reading with the wrong readtable? # is a macro in Interlisp, just OTHER in OLD-INTERLISP-FILE. With OLD-INTERLISP-FILE it returns
> > (## (Function) NIL NIL (NIL 60))
> > and maybe the ## has some particular meaning for the index.
> >
> >> On Apr 6, 2024, at 9:55 PM, Larry Masinter ***@***.***> wrote:
> >>
> >>
> >> the following files all report a GETFN error if I just call TEDIT on them.
> >>
> >> i.e. (SETQ BADFILES (READFILE 'BADFILES.TXT))
> >> (MAPCAR BADFILES 'TEDIT)
> >>
> >> it seems to load the GETFN but not succeed in applying it?
> >>
> >> it took me a long time with git bisect to convince myself that the problem was introduced in TEdit Round 4.
> >> 44e4294 <44e4294>
> >> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> >> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> >> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> >> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> >> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
> >> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> >> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> >> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
> >> {MEDLEY}medley-irm>09-conditionals.TEDIT;1
> >> {MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
> >> {MEDLEY}medley-irm>16-SEDIT.TEDIT;1
> >>
> >> —
> >> Reply to this email directly, view it on GitHub <#1652>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO4AEOZW4VKYBWVH63Y4DGSRAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZDSNJWGI2DAMY>.
> >> You are receiving this because you are subscribed to this thread.
> >>
> >
>
> —
> Reply to this email directly, view it on GitHub <#1652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWNGJIGEBPRKINAQHTDY4GBXLAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGU2DIMRUGY>.
> You are receiving this because you are subscribed to this thread.
>
—
Reply to this email directly, view it on GitHub <#1652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL5AP4NXKXKJOZAMKTY4GH3FAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGU2TQOJUGU>.
You are receiving this because you commented.
|
rmkaplan
added a commit
that referenced
this issue
Apr 8, 2024
|
In PR #1649 the put and get functions for the index object now explicit specify the readtable, no accidental inheritance from current environment. |
|
The Medley 2.0 collection of fonts seems likely to be QA'd than the hodge-podge of fonts we picked up from here and there. |
|
I found titan 6 and 9 in fonts>other>co>.
fonts>other is in DISPLAYFONTDIRECTORIES, so I don’t understand why the Titan font couldn’t be found.
DANCER 10 and 12 and SIGMA 20 are also there, other fonts that have given us trouble.
… On Apr 7, 2024, at 7:03 PM, Larry Masinter ***@***.***> wrote:
image.png (view on web) <https://github.com/Interlisp/medley/assets/1116587/73edc645-75b1-41d2-b573-228de50d4ba7>
The Medley 2.0 collection of fonts seems likely to be QA'd than the hodge-podge of fonts we picked up from here and there.
—
Reply to this email directly, view it on GitHub <#1652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL2S7ZMZM3S4SLNRXLY4H3IBAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRG4ZTKNBVGQ>.
You are receiving this because you commented.
|
|
Given that these particular Titan fonts exist, the problem is in the way that NSDISPLAYSIZES attempts to find reasonable display sizes. The patch that was done several months ago assumed that size Titan 8 existed, but it doesn’t. I think this was a mistaken extension from what existed for Terminal to what actually existed for Titan.
Apart from updating all of this to modern font technology, what we need is a function that returns the size of the next largest font that is available (which would also be useful for the Tedit “Larger” button). But the convoluted logic has to be revised to make sure that it avoids a looping recursion.
I will first patch again to do a better approximation, given that we now see which Titan fonts do exist. Titan and Terminal should have different size coercions.
Separately, why don’t we move the fonts in fonts/other to fonts/displayfonts ?
… On Apr 7, 2024, at 11:31 PM, Ron Kaplan ***@***.***> wrote:
I found titan 6 and 9 in fonts>other>co>.
fonts>other is in DISPLAYFONTDIRECTORIES, so I don’t understand why the Titan font couldn’t be found.
DANCER 10 and 12 and SIGMA 20 are also there, other fonts that have given us trouble.
> On Apr 7, 2024, at 7:03 PM, Larry Masinter ***@***.***> wrote:
>
>
> image.png (view on web) <https://github.com/Interlisp/medley/assets/1116587/73edc645-75b1-41d2-b573-228de50d4ba7>
> The Medley 2.0 collection of fonts seems likely to be QA'd than the hodge-podge of fonts we picked up from here and there.
>
> —
> Reply to this email directly, view it on GitHub <#1652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL2S7ZMZM3S4SLNRXLY4H3IBAVCNFSM6AAAAABF3ADQUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRG4ZTKNBVGQ>.
> You are receiving this because you commented.
>
|
masinter
pushed a commit
that referenced
this issue
Apr 30, 2024
… close the index file (#1649) * IMINDEX: The displayfn of index image objects sets AFTERHARDCOPYFN to close the index file Removes the need for advising the Tedit hardcopy function. This won't have an effect until a separate PR (after rmk7 is merged) that updates the hardcopy function. * Index image object explicitly uses OLD-INTERLISP-FILE for printing and reading (cf #1652)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the following files and many more report a GETFN error if I just call TEDIT on them.
i.e. (SETQ BADFILES (READFILE 'BADFILES.TXT))
(MAPCAR BADFILES 'TEDIT)
it seems to load the GETFN but not succeed in applying it?
it took me a long time with git bisect to convince myself that the problem was introduced in TEdit Round 4.
44e4294
{MEDLEY}medley-irm>09-conditionals.TEDIT;1
{MEDLEY}medley-irm>13-EXECUTIVE.TEDIT;1
{MEDLEY}medley-irm>16-SEDIT.TEDIT;1
(at least 3)
The text was updated successfully, but these errors were encountered: