WINDOWOBJ: READIMAGEOBJ doesn't ask for permission

[rmkaplan]

If the image object is on a hyphenated file and it can find a nonhyphenated sister, it loads that. If that doesn't provide the getfn, it tries the original file.

It tries to find a compiled version, goes to source if a compiled doesn't exist.

When it fails, it also tries to be more informative about the problem, to indicate whether the getfn is unknown, or there was an error in its execution.

This latter is not completely right: if an image object (sketch) contains another image object (say an LFG object), it will find the sketch getfn (when the Sketch-renaming PR is merged). But it won't find the getfn for the embedded LFG object because LFG is not in the WHEREIS database. It's really the lower getfn that is unknown, but I don't see how to propagate that fact to the upper sketch-object. So the label says that it's the sketch function is unknown.

It ought to say either that there was an error in executing the sketch function or, better, that the LFG function was unknown. I don't know how to propagate the signal to the top-level call.

[masinter]

I am uncomfortable having it automatically load because we haven't extended WHEREIS with notecards, and notecards has its own imageobject definitions. So HCFILES will work differently if you HCFILES notecards. I'd like to set up a breakpoint if it can't find the GETFN.

[rmkaplan]

Notecards has alternative definitions of the same imageobjs?

…

On Dec 9, 2023, at 6:55 AM, Larry Masinter ***@***.***> wrote: I am uncomfortable having it automatically merge because we haven't extended WHEREIS with notecards, and notecards has its own imageobject definitions. So HCFILES will work differently if you HCFILES notecards. I'd like to set up a breakpoint. — Reply to this email directly, view it on GitHub <#1449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJONWP5QNGH3HSABBJTYIR3V3AVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGQZTCMJTHA>. You are receiving this because you authored the thread.

[masinter]

i don't think so, but WHEREIS will respond differently if you don't have notecards loaded and you don't have the notecards-whereis.hash.

…

On Sat, Dec 9, 2023 at 8:42 AM rmkaplan ***@***.***> wrote: Notecards has alternative definitions of the same imageobjs? > On Dec 9, 2023, at 6:55 AM, Larry Masinter ***@***.***> wrote: > > > I am uncomfortable having it automatically merge because we haven't extended WHEREIS with notecards, and notecards has its own imageobject definitions. So HCFILES will work differently if you HCFILES notecards. I'd like to set up a breakpoint. > > — > Reply to this email directly, view it on GitHub < #1449 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AQSTUJONWP5QNGH3HSABBJTYIR3V3AVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGQZTCMJTHA>. > You are receiving this because you authored the thread. > — Reply to this email directly, view it on GitHub <#1449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIQTK42IUVCUV6GQCGEAJ3YISIFZAVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGU3DAOJQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

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

[rmkaplan]

But, if the Notecards whereis doesn’t know about the getfn Y of an imageobj in file X, why would it matter whether it is present or not? Either the main database knows where Y is, or it doesn’t. Perhaps the proper refinement would be to ask explicitly if whereis says that Y exists on more than one file, and to be sure to ask the user to make an explicit selection in ithat case.

…

On Dec 9, 2023, at 10:34 AM, Larry Masinter ***@***.***> wrote: i don't think so, but WHEREIS will respond differently if you don't have notecards loaded and you don't have the notecards-whereis.hash. On Sat, Dec 9, 2023 at 8:42 AM rmkaplan ***@***.***> wrote: > Notecards has alternative definitions of the same imageobjs? > > > On Dec 9, 2023, at 6:55 AM, Larry Masinter ***@***.***> wrote: > > > > > > I am uncomfortable having it automatically merge because we haven't > extended WHEREIS with notecards, and notecards has its own imageobject > definitions. So HCFILES will work differently if you HCFILES notecards. I'd > like to set up a breakpoint. > > > > — > > Reply to this email directly, view it on GitHub < > #1449 (comment)>, > or unsubscribe < > https://github.com/notifications/unsubscribe-auth/AQSTUJONWP5QNGH3HSABBJTYIR3V3AVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGQZTCMJTHA>. > > > You are receiving this because you authored the thread. > > > > — > Reply to this email directly, view it on GitHub > <#1449 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAIQTK42IUVCUV6GQCGEAJ3YISIFZAVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGU3DAOJQGQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- https://LarryMasinter.net https://interlisp.org — Reply to this email directly, view it on GitHub <#1449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMED7GJ4JOAT6QWWNLYISVLTAVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGYYDQOJXGY>. You are receiving this because you authored the thread.

[masinter]

Unknown GETFN should only auto-load if explicitly set up to do so (a global AUTOLOADONCALLFLG?

I also don't like extending the two-level directory structure into code all over the place. It's an ugly hack to solve an organiational problem for the short-term but let's not make other parts of the system depend on it.

[masinter]

what's going on here is that one of the 'imrovements' we made was when there is an unknown GETFN, you call WHEREIS T to see if you can load it. We're kind of backing into an 'autoload' feature which Interlisp didn't have.... but learn from history. It's a DWIM feature where things can go awry badly and unnoticed if you LOAD the wrong file.

Yes, there are cases where autoload on function call is fine, but it shoudln't be the default. Explicitly setting up an autoload list of known GETFNs would be better, and a BREAK or askuser on unknown GETFN and ERROR if not found would be better.

[rmkaplan]

It can be conditioned on a flag, but then, what should the default be?

WRT the two-level directory structure: it's either a bug or a feature. Do you have a proposal for a better way of organizing and relating the subfiles that make up a larger application?

The current "hack" puts some order on the top-level directories (what goes with what), and also provides a mapping from a subfile to the main file.

[masinter]

I started down a path to share the GETFN code with HPRINT (with the idea of finishing the Common Lisp integration so that once again HRPINT can print anything in a way that it can be read in.

#1436 (review)

In particular, HPRINT should be able to print a bitmap and a font -- then EQUALALL could default to "print to string and string-compare".

I backed off but now we really need font-compare to deal with all the CHM-Parc font files and start to make progress on the "better fonts for high-res displays" we postponed.

[rmkaplan]

Font-compare is probably a small matter of programming. I think I already did a bitmap equal, the other pieces are probably also there. Maybe it needs a block-compare? Having a single strategy for finding missing pieces is a good goal, but I think it would be better to approach it bottom up. Get an HPRINT thing to work first, maybe sharing pieces of the GETFN strategy, then seeing how much they really have in common.

…

On Dec 9, 2023, at 11:48 AM, Larry Masinter ***@***.***> wrote: I started down a path to share the GETFN code with HPRINT (with the idea of finishing the Common Lisp integration so that once again HRPINT can print anything in a way that it can be read in. #1436 (review) <#1436 (review)> In particular, HPRINT should be able to print a bitmap and a font -- then EQUALALL could default to "print to string and string-compare". I backed off but now we really need font-compare to deal with all the CHM-Parc font files and start to make progress on the "better fonts for high-res displays" we postponed. — Reply to this email directly, view it on GitHub <#1449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPBSQY5U2G42H4A5HLYIS6B5AVCNFSM6AAAAABAI2CW32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGY2DKNRYGA>. You are receiving this because you authored the thread.

[masinter]

I'd prefer a more general AUTOLOAD approach, but ... this is the Interlisp way.