EDITINTERFACE--ED searches for symbols, no error when declining a loadfns #2301
Conversation
|
On Linux Mint 22.1 Cinnamon this PR no longer generates the same error it does on master when saying no after But |
|
ED does better when the OPTIONS argument includes the possible types. Try This has been hanging around in my working directory since late last year. I thought I had also tried to set up a menu of types in addition to searching in a package-independent way. I'll look again. |
|
Including the type yields the expected behavior: |
…lifiers have different types
|
The symbol x type menu is what I was really aiming at last year. Matt reminded me that MKSTRING with flag T retained the package qualifer in the menu, but I never got back to it. If FIE exists in different packages with different types, the user can choose a symbol/type combination to edit. |
|
I updated to commit cea05f9 and 
Evaluating 
|
|
Please try again.
I'm having a lot of trouble working on this--my first DEFUN with a mixture of CL code with a lot of IL:for stuff.
Local variables don't seem to be bound in the breaks, even with full package qualifiers.
… On Sep 30, 2025, at 2:07 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2301)
<#2301 (comment)>
I updated to commit cea05f9 <cea05f9> and (ED 'GET-INDENT) yields the error:
INTERLISP-ERROR
In ERROR:
DIVIDE-BY-ZERO
0
ed-error1.png (view on web) <https://github.com/user-attachments/assets/d4ffacb7-7766-4c69-a9ba-2a65f8542d99>
5_: BTV
MESS1 "DIVIDE BY ZERO"
MESS2 0
NOBREAK NIL
ERROR
IQUOTIENT
GRIDYCOORD
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (& &)
MENU.HANDLERA0001A0003
SI::*CLEANUP-FORMS* SI::RESETUNWIND
MOUSEDOWN NIL
MOVEDLEFT "NESTED"
LASTBUTTONSTATE 0
MGRIDSPEC (0 0 250 0)
HOLDTIMER -1809309526
HELDFN DEFAULTMENUHELDFN
NROWS 0
NCOLUMNS 1
LOCALMENUHELDWAIT 1200
ITEM NIL
SUBITEMS NIL
SUBMENURESULT NIL
OLDBOXX NIL
OLDBOXY NIL
BOXX NIL
BOXY NIL
HELDSTATE NIL
SUBMENUWINDOW NIL
SUBMENU NIL
SI::NLSETQ-VALUE NIL
*PROCEED-CASES* (& &)
SI::*NLSETQFLAG* NIL
SI::*UNWIND-PROTECT*
MENU {MENU}#131,107130
DSP #<Output Display Stream/167,122300>
KEEPCONTROLIFOUTFLG T
CHANGEOFFSETFLG T
NESTEDFLG NIL
LISPXHIST ((&) (3 "" . "_ ") "<not yet evaluated>"
NIL)
SI::*RESETFORMS* ((& NIL))
RESETSTATE NIL
MENU.HANDLER
SI::*CLEANUP-FORMS* SI::RESETUNWIND
SI::*UNWIND-PROTECT*
MENU {MENU}#131,107130
RELEASECONTROLFLG NIL
NESTEDFLG NIL
IMAGE {WINDOW}#156,165170
DSP #<Output Display Stream/167,122300>
LISPXHIST ((&) (3 "" . "_ ") "<not yet evaluated>"
NIL)
SI::*RESETFORMS* ((& {WINDOW}#156,165170))
RESETSTATE NIL
MENU
ED
*FORM* (ED (QUOTE GET-INDENT))
*ARGVAL* NIL
*TAIL* NIL
*FN* ED
\EVALFORM
FAULTEVAL
*FORM* (UNDOABLY (ED &))
\EVALFORM
\INTERNAL NIL
EVAL
EVAL-INPUT
RETRYFLAG NIL
HELPCLOCK 838
DO-EVENT
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (&)
LISPXHIST ((&) (3 "" . "_ ") "<not yet evaluated>"
NIL)
HELPCLOCK 0
XCL::EXECA0001A0002
*CURRENT-EVENT* ((&) (3 "" . "_ ")
"<not yet evaluated>" NIL)
SI::NLSETQ-VALUE NIL
*PROCEED-CASES* (&)
SI::*NLSETQFLAG* NIL
XCL::EXECA0001
\PROGV
XCL::TOP-LEVEL-P T
XCL::WINDOW {WINDOW}#156,165664
XCL::TITLE-SUPPLIED NIL
XCL::TITLE NIL
*THIS-EXEC-COMMANDS* (#<Hash-Table @ 166,33666>)
XCL::ENVIRONMENT NIL
XCL::PROMPT NIL
XCL::FN EVAL-INPUT
XCL::PROFILE "XCL"
*EXEC-ID* ""
XCL::PROFILE-CACHE (XCL::*PROFILE-NAME* "XCL"
XCL:*EVAL-FUNCTION* CL:EVAL *PACKAGE* #<Package XCL-USER> *READTABLE* #<ReadTable XCL/174,56634> XCL:*EXEC-PROMPT* "> " --)
EXEC
\PROC.REPEATEDLYEVALQT
*FORM* (\PROC.REPEATEDLYEVALQT)
*ARGVAL* NIL
*TAIL* NIL
*FN* \PROC.REPEATEDLYEVALQT
\EVALFORM
%#FORM# (\PROC.REPEATEDLYEVALQT)
*CURRENT-PROCESS* #<Process EXEC/174,13204>
HELPFLAG BREAK!
\CURRENTDISPLAYLINE 0
\#DISPLAYLINES 20
\LINEBUF.OFD #<IO Linebuffer Stream/167,124600>
*READTABLE* #<ReadTable INTERLISP/174,56714>
\PRIMTERMTABLE {TERMTABLEP}#174,51740
\PRIMTERMSA {CHARTABLE}#174,52000
TtyDisplayStream #<Output Display Stream/146,32100>
SI::*RESETFORMS* NIL
\INTERRUPTABLE T
\TTYWINDOW NIL
READBUF NIL
\TERM.OFD #<Output Display Stream/167,122500>
*STANDARD-OUTPUT* #<Output Display Stream/167,122500>
*STANDARD-INPUT* #<IO Linebuffer Stream/167,124600>
\MAKE.PROCESS0
T
Evaluating (DF GET-INDENT) yields the error:
INTERLISP-ERROR
unrecognized manager definition type
SEDIT::GET-INDENT
ed-error2.png (view on web) <https://github.com/user-attachments/assets/e4fd5770-6831-480b-829d-86abff9319dd>
5_: BTV
MESS1 "unrecognized manager definition type"
MESS2 SEDIT::GET-INDENT
NOBREAK NIL
ERROR
GETFILEPKGTYPE
GETFILEPKGTYPE
GETFILEPKGTYPE
SOURCE NIL
EDITDEF
ED
FN (GET-INDENT)
*EDITMODE* DISPLAY
ARGS (GET-INDENT)
DF
CL:FUNCALL
*FORM* (CL:FUNCALL (FUNCTION DF) (QUOTE &))
*ARGVAL* NIL
*TAIL* NIL
*FN* CL:FUNCALL
\EVALFORM
FAULTEVAL
*FORM* (UNDOABLY (DF GET-INDENT))
\EVALFORM
\INTERNAL NIL
EVAL
EVAL-INPUT
RETRYFLAG NIL
HELPCLOCK 322
DO-EVENT
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (&)
LISPXHIST ((&) (3 "" . "_ ") "<not yet evaluated>"
NIL)
HELPCLOCK 0
XCL::EXECA0001A0002
*CURRENT-EVENT* ((&) (3 "" . "_ ")
"<not yet evaluated>" NIL)
SI::NLSETQ-VALUE NIL
*PROCEED-CASES* (&)
SI::*NLSETQFLAG* NIL
XCL::EXECA0001
\PROGV
XCL::TOP-LEVEL-P T
XCL::WINDOW {WINDOW}#156,165664
XCL::TITLE-SUPPLIED NIL
XCL::TITLE NIL
*THIS-EXEC-COMMANDS* (#<Hash-Table @ 166,33666>)
XCL::ENVIRONMENT NIL
XCL::PROMPT NIL
XCL::FN EVAL-INPUT
XCL::PROFILE "XCL"
*EXEC-ID* ""
XCL::PROFILE-CACHE (XCL::*PROFILE-NAME* "XCL"
XCL:*EVAL-FUNCTION* CL:EVAL *PACKAGE* #<Package XCL-USER> *READTABLE* #<ReadTable XCL/174,56634> XCL:*EXEC-PROMPT* "> " --)
EXEC
\PROC.REPEATEDLYEVALQT
*FORM* (\PROC.REPEATEDLYEVALQT)
*ARGVAL* NIL
*TAIL* NIL
*FN* \PROC.REPEATEDLYEVALQT
\EVALFORM
%#FORM# (\PROC.REPEATEDLYEVALQT)
*CURRENT-PROCESS* #<Process EXEC/174,13204>
HELPFLAG BREAK!
\CURRENTDISPLAYLINE 0
\#DISPLAYLINES 20
\LINEBUF.OFD #<IO Linebuffer Stream/167,124600>
*READTABLE* #<ReadTable INTERLISP/174,56714>
\PRIMTERMTABLE {TERMTABLEP}#174,51740
\PRIMTERMSA {CHARTABLE}#174,52000
TtyDisplayStream #<Output Display Stream/146,32700>
SI::*RESETFORMS* NIL
\INTERRUPTABLE T
\TTYWINDOW NIL
READBUF NIL
\TERM.OFD #<Output Display Stream/167,122500>
*STANDARD-OUTPUT* #<Output Display Stream/167,122500>
*STANDARD-INPUT* #<IO Linebuffer Stream/167,124600>
\MAKE.PROCESS0
T
—
Reply to this email directly, view it on GitHub <#2301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJHS2JHZUXX6BWFAJL3VJB6TAVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJQHA2DKNBRG4>.
You are receiving this because you authored the thread.
|
|
Commit a296c4e fixes the But I still get the same error with |
|
If you run symbolic, you get an error that there is a missing argument, which is correct. Compiled code is wrong, as I mentioned yesterday. I'll put up an issue on that. But I'll also put a check so that it doesn't try to build an empty menu (and also an issue that MENU on an empty menu (MENU (create MENU)) shouldn't divide by 0).
I, personally, don't yet understand how to work with DEFUN/commonlisp code. Usual Interlisp techniques don't seem to work (e.g UNSAVEDEF to switch back and forth between code and expr without reloading the dfasl each time, getting the value of a local variable in a break). I probably need to read the primer.
… On Sep 30, 2025, at 8:09 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2301)
<#2301 (comment)>
Commit a296c4e <a296c4e> fixes the DF issue:
6_ (DF GET-INDENT)
SEDIT::GET-INDENT is contained on SEDIT-INDENT.
Shall I load this file PROP? Y
{DSK}<home>paolo>medley>medley>sources>SEDIT-INDENT.;1
File created 17-May-90 11:03:43
IL:SEDIT-INDENTCOMS
{DSK}<home>paolo>medley>medley>sources>SEDIT-DECLS.LCOM;1
compiled on 1-Dec-2021 23:12:16
File created 1-Dec-2021 20:02:36
EXPORTS.ALL must be loaded to compile SEdit
SEDIT-ACCESS must be REMADE NEW if you change a record
SEDIT::GET-INDENT
But I still get the same error with ED:
4_ (ED 'GET-INDENT)
In ERROR:
DIVIDE BY ZERO
0
—
Reply to this email directly, view it on GitHub <#2301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOFSHQGWY5G62NNV233VKMJHAVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJSGY3DCOBSHA>.
You are receiving this because you authored the thread.
|
|
I confirm that, on this branch, passing the type as the second argument works as expected: In case it's useful I posted some notes on working with managed Common Lisp code on Medley. |
|
My problem isn't so much the interaction with the file manager. Apart from the UNSAVEDEF, what makes it hard to debug is that I can't set up a call to HELP, get a break window, and then copy expressions from the code into the break to do step-wise, form-at-a-time debugging. None of the local variables are bound, even when running the code symbolically.
Isn't that supposed to work?
… On Sep 30, 2025, at 9:02 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2301)
<#2301 (comment)>
I confirm that, on this branch, passing the type as the second argument works as expected:
5_ (ED 'GET-INDENT 'FUNCTIONS)
SEDIT::GET-INDENT
In case it's useful I posted some notes on working with managed Common Lisp code <https://write.as/paoloamoroso/a-single-package-common-lisp-workflow-for-medley> on Medley.
—
Reply to this email directly, view it on GitHub <#2301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJI56JJ5GX2UMOBLIVT3VKSSLAVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJSHA3TINBSGU>.
You are receiving this because you authored the thread.
|
|
I updated to commit 46c3c08 and tested the |
|
The APPEND case is the old behavior--the user has typed a symbol (with implicit package), and that symbol is known and has the various types of definitions. The new behavior is for when the user doesn't know or bother with the package, or whether the symbol is internal or external. In that case it is supposed to offer a choice of all the symbols in any package (internal or external) that have definitions of any of the specified (if any) types. (If the user clicks away from the menu, it current brings up the old prototype menu--maybe it should do nothing in that case?) If there is a single symbol with multiple types, it is supposed to bring up a menu with just the types of that symbol, with the title showing the package qualifier. There should be a difference between (ED 'GET-INPUT NIL) (no types specified in the call, brings up a menu of SETFS and FUNCTIONS) |
|
My head is: But I still get the old behavior when no types are specified: 
|
|
Try GET-INDENT instead of GET-INPUT ? |
|
|
|
I updated to commit f91e993 and when I call 
|
|
Commit 60a6f0a fixes the issue. |
@rmkaplan this works in simple cases: (defun test (x y z) (/ y z)) x. => X-VALUE it picks up the lexical context from the CL:EVAL call. |
|
I appears that this only works if the break happens under an XCL exec, not an Interlisp exec. If a defun is called somewhere under an Interlisp exec and it gets an error break or it calls HELP, the variables appear not to be bound. |
There was a problem hiding this comment.
Before I officially "review" this per GitHub, I need to know what this is promising.
I tried my usual define/edit flow, in which I defined a function by
ED(MY-NEW-FUNCTION)
then selecting FUNCTIONS from the pop-up and defining the function in SEdit. That worked fine - no change from the behavior in master.
Editing the function, now that it exists, also worked as it did before:
ED(MY-NEW-FUNCTION
HTMLSTREAM declares U-PNG as a dependency using FILES.
I loaded HTMLSTREAM.DFasl, after which U-PNGCOMS has the expected value.
The file U-PNG defines a package, also named U-PNG, with a mix of public (e.g., WRITE-BITMAP) and internal (e.g., TEST-IT) symbols. I was hoping that ED would now be able to find those without further work.
In an Interlisp exec I typed
ED(WRITE-BITMAP)
and got the "dummy def'n" popup. I received the same result for
ED(TEST-IT)
GETD returns Compiled Function objects for both.
I went into the FileBrowser and did an explicit LOAD PROP of U-PNG. Now things worked as I had hoped: both ED(WRITE-BITMAP) and ED(TEST-IT) found the symbols in the U-PNG package and edited the expected definittions.
So ED did not intuit the need to ask me whether to LOAD U-PNG PROP. If this PR was supposed to enable that, it didn't succeed. If not, then I'd say it works fine (but I wish it had the extra logic I envisioned), and I will approve it.
|
@hjellinek , all (or many) bets are off with DFASL files. As noted in #2310 , they are implicitly loaded SYSLOAD, so the coms don't exist after the load. If your functions are not in WHEREIS, then it is not known where their editable definitions are until you load the symbolic file. It may be that the DFASL loader can be fixed up so that it interacts better with the FILEPKG and managed files. But it seems that this is another example of only partial integration of common Lisp with the Medley residential programming style. What would happen if we used FAKE-COMPILE-FILE for all managed files and reserved CL:COMPILE-FILE for unmanaged pure common Lisp text files? |
Relegating CL:COMPILE-FILE to only handling unmanaged pure CL source code would mean losing functionality. Loading DFASL files directly works as you'd expect w/r/to the file manager. As I mentioned in my comments, the COMS did exist after the I'm also not sure how common it is to try to compile pure CL source code. But it seems that loading a DFASL via FILES wasn't expected to work as I'd hoped, so my testing verifies that this PR works. |
|
It appears that LOAD(HTMLSTREAM.DFASL) does make the FUNCTIONS on that file known to the file package and therefore to ED. But HTMLSTREAM loads U-PNG and BASE64 SYSLOAD, so the items on those files are not known. |
|
In general loading of other files should not be done SYSLOAD…LÒADFLG is inherited--On Oct 6, 2025, at 2:15 PM, rmkaplan ***@***.***> wrote:rmkaplan left a comment (Interlisp/medley#2301)
It appears that LOAD(HTMLSTREAM.DFASL) does make the FUNCTIONS on that file known to the file package and therefore to ED.
But HTMLSTREAM loads U-PNG and BASE64 SYSLOAD, so the items on those files are not known.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
Herb's file has (FILES BASE64 U-PNG) command, doesn't specify SYSLOAD. What seems to be happening is that BASE64.DFASL is loaded, its coms are there, but it is not on FILELST so the file package doesn't know to look for the coms. It is not on SYSFILES, but it does appear on LOADEDFILELST. Is SYSFILES just set at the end of the load up, to represent what's in the makesys, without updating for new SYSLOADed files?
… On Oct 6, 2025, at 3:07 PM, Larry Masinter ***@***.***> wrote:
masinter
left a comment
(Interlisp/medley#2301)
<#2301 (comment)>In general loading of other files should not be done SYSLOAD…LÒADFLG is inherited--On Oct 6, 2025, at 2:15 PM, rmkaplan ***@***.***> wrote:rmkaplan left a comment (Interlisp/medley#2301)
It appears that LOAD(HTMLSTREAM.DFASL) does make the FUNCTIONS on that file known to the file package and therefore to ED.
But HTMLSTREAM loads U-PNG and BASE64 SYSLOAD, so the items on those files are not known.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub <#2301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ2I4MXF5KSHL7FYKL3WLRY3AVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZUGQZDMOJZGA>.
You are receiving this because you were mentioned.
|
How does that happen? |
I do not know, but it would be great if it worked as I had expected it to. |
|
Is the issue with BASE64.DFASL and |
|
I think Herb's problem is that BASE64 is loaded from a FILES command inside a DFASL. The DFASL loader FASL:PROCESS-FILE rebinds a bunch of variables as if the LDFLG argument to LOAD was SYSLOAD. That includes one (FILEPKGFLG) that tells any files loaded underneath it to not be noticed by the file package. (See man SYSLOAD, also #2310).
If your WEB-EDITOR is also loaded from a FILES command in another DFASL, that might explain it. The coms are there as a variable, but the file itself isn't known.
… On Oct 7, 2025, at 11:35 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2301)
<#2301 (comment)>
Is the issue with BASE64.DFASL and FILELST related to discussion #2308 <#2308>? WEB-EDITOR is a managed file.
—
Reply to this email directly, view it on GitHub <#2301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMTFGWVQFTZ7MS2KST3WSWB7AVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZZHEYDMMRZG4>.
You are receiving this because you modified the open/close state.
|
4 participants
More intuitive behavior when you call ED on something without the right package qualifier. E.g. if you (ED 'GET-INDENT) it now asks whether you want SEDIT::GET-INDENT instead of always bringing up the new-function-template menu.
Also, this removes the call to ERROR when it asks you whether you want to load a function to edit and you say No.