Interlisp
Problems with ACE LispUsers MENU code -- works in MEDLEY 1.0
@mdenber reports
Still trying to figure out why ACE doesn't work. I tried it on a Medley 1 ldex and it works fine there. I think something changed in ADDMENU between Medley 1 and 3.
How can I get access to Medley 1?
When you start ACE up, it writes on the background rather than in the window.
you have to be careful debugging things that might be used y the debugger. if you (NREAK ADDMENU) you can get a stack overflow. (BREAK (ADDMENU IN AVE)) might help localize this problem.
this is a bug in BITBLT(!). There's the image of the menu in SS and a window DST.
if I make a new window of the same width and height 568v450 and add USERDATA
....
@masinter - I think part of that message got lost. If it's a basic BITBLT operation, that would be implemented in the Maiko C code, and I would be quite surprised that this was the first time such a problem had shown up.
When I run it, I see a variety of bad behaviors. Sometimes it draws the menu and sometimes it doesn't. ACE caches several values, so running it the second and subsequent time don't execute the exact same code path as the first time. I've observed it writing to the screen background and also breaking in ACE.QUICKDRAW&UPD in DSPCLIPPINGREGION with \ILLEGAL.ARG NIL when attempting to loop an animation, but after the first instance of this, it's not clear that we're seeing anything other than side-effects of a previous bug.
On 3/26/2023 4:19 PM, John D. Corbett wrote:
When I run it, I see a variety of bad behaviors. Sometimes it draws the menu and sometimes it doesn't. ACE caches several values, so running it the second and subsequent time don't execute the exact same code path as the first time. I've observed it writing to the screen background and also breaking in ACE.QUICKDRAW&UPD in DSPCLIPPINGREGION with \ILLEGAL.ARG NIL when attempting to loop an animation, but after the first instance of this, it's not clear that we're seeing anything other than side-effects of a previous bug.
That's all true. I've witnessed it myself. I must though humbly reiterate that it all worked fine in Medley 1.0. I don't think there's any code in there that explicitly draws on the screen bitmap.
- Michele
Are there any screen images of what the ACE many window is supposed to look like?
ADDMENU clobbers various window properties to make the menu work. ACE clobbers them back. Wondering if somewhere a display stream is now somehow defaulting to the the screen background because some function that used to return the application window now returns NIL or something like that.
Understood that it works in Medley 1.0 and whatever version of Interlisp-D it was developed in.
I fiddled around a bit. I made some dribble logs of log.txt log2.txt it looks like the clipping is offset from where it should be, and so the BITBLT writes outside the menu-window's boundaries. i ran new ace in loadups/lisp.venuesysout and old ace in current.
On 3/26/2023 8:20 PM, John D. Corbett wrote:
Are there any screen images of what the ACE many window is supposed to look like?
Like this:
This is in a Medley 1.0 sysout with a MAKESYSDATE of 28-Aug-91 running with the Solaris SPARC ldex I found on the PARC server, file size 2278016.
- Michele
Was trying to familiarize myself with ADDMENU and all the rest. Recreating the initial appearance is easy and doesn't show the bug. I added a few menu items for convenience while playing around.
The ACE code calls ADDMENU with the location (0 . 0) but I'm not sure how this could be right, (actually not right but lower left).
@Michele31415, now I see it. So, (0 . 0) is correct. Maybe the buggy x-coordinate the menu gets rendered at is related to the text starting location for the directory prompt.
I wonder if there's a reason for shading the title bar. I don't recall that being a common thing.
When I change the ADDMENU location to (0 . 0), and change the window border size to 1, the menu is drawn exactly as in Michele's screenshot.
It calls BKBITBLT to put up the menu image --
and it looks as though it's trying to call it with the correct location (0 . 0) but we'll need to look at what BKBITBLT should be doing.
I discovered a way to recreate the problem. If we call (DSPXOFFSET X STREAM) or (DSPYOFFSET Y STREAM) the menu renders outside the window and when the window is moved, it redisplays offset by the change in position of the window.
The ACE code does manipulate the window's clipping region despite the caution in the IRM.
The code in \BITBLT.DISPLAY does take into account the offsets --
(SETQ DESTINATIONLEFT (\DSPTRANSFORMX DESTINATIONLEFT DESTDD))
and likewise for the bottom, so if under Medley 1.0 the offsets were ignored, but then that "bug" was fixed, we'd see this change. I can't find a copy of LLDISPLAY from Medley 1.0 to check.
@Michele31415,
I wonder if there's a reason for shading the title bar. I don't recall that being a common thing.
I hadn't even noticed that. I checked a screenshot of Lisp running on the D0 and it's not that way there. It's also just a solid line in Medley 3.5. It's a mystery.
I found lots of versions of LLDISPLAY, removing duplicates
(FILECREATED "13-Jun-90 13:28:33" {DSK}<home>ringneck>takeshi>M1.2>ARFIX>LLDISPLAY.;2 159403 ./history/1990s/1993-envos/extra-lispcore-sources/LLDISPLAY:
(FILECREATED "26-Apr-91 17:00:45" |{PELE:MV:ENVOS}<LISPCORE>LIBRARY>LLDISPLAY.;1| 161932 ./history/1990s/1993-envos/LISPCORE/library/LLDISPLAY:
(FILECREATED "28-Jan-93 17:38:44" {DSK}<python>lde>lispcore>sources>LLDISPLAY.;2 249157 ./history/1990s/1993-envos/LISPCORE/sources/LLDISPLAY:
(FILECREATED "18-Apr-94 00:20:42" {DSK}<users>nilsson>mnw>LLDISPLAY.;7 267646 ./history/202011-lisp/sources/LLDISPLAY:
(FILECREATED " 9-Jul-2022 12:08:02" ./medley/sources/LLDISPLAY:
I think BKBITBLT did it in the (STORAGE) (L:ROOM) with a Clipping Region
@pictographer wrote:
Are there any screen images of what the ACE many window is supposed to look like?
The ACE documentation contains a screenshot of the control window:
and the main menu:
As discussed in the Jul 31, 2024 external meeting, to isolate the issue I'll test ACE on Medley for DOS which I managed to run under DOSBox-X as reported in #1790. It has a Medley 2 sysout dated Sep 1992.
To run ACE on Medley for DOS I downloaded the compiled files from the Medley repo, renamed them from .LCOM to .LCO, and copied them to C:\MEDLEY\ACE. Then from Medley for DOS I changed to the directory medley>ace, evaluated (il:filesload ace), and got this error:
Bad compiled function
ACE
It's probably better to build ACE from source on DOS. Can I just FILE-COMPILE every source file? Any required compilation order?
One of the ACE source files, ACEIMAGEOBJ, has a name longer than the 8+3 DOS format (and there's no compiled version). How should I handle it?
I'm not sure of the timeline of introducing new features in Maiko, but there were incompatible changes between Medley 1.0 and Medley 3.5 (which we started with in current Medley/Maiko):
- Bigger Add space (28 bit pointers)
- first 3-byte atoms, then 4-byte atoms
but in any case Medley 2.0 compiled files and Medley 3.5 current repo compiled files are incompatible. You can't use current medley LCOMs or DFASLsin Medley 2.0. You can use IL:BCOMPL or CL:COMPILE-FILE on each file.
I made some progress with compiling ACE.
I downloaded the source files and renamed ACEIMAGEOBJ to ACEIMGOB to fit the DOS format, then compiled them with CL:COMPILE-FILE. The following files compiled with no errors:
- ACE
- ACEIMGOB
- ACE-PRIM
The compilation of ACE-EDIT broke into the debugger with the error The form 16, appearing in a functional context, is neither a symbol nor a LAMBDA-form:
Compiling ACE-MAIN broke into the debugger with the same error The form 16, appearing in a functional context, is neither a symbol nor a LAMBDA-form:
I'd BCOMPL them rather than use the CommonLisp compiler. Also, when you get a break like that, don't just stop... use the backtrace, look back up the stack, look at the form it was compiling, where did it come from, does it make sense?
I compiled each ACE file separately with BCOMPL and for all of them the build completed with no errors. Then I loaded the compiled ACE file with (il:filesload ace) and evaluated (il:ace). ACE opened the main window but the program broke into the debugger with the error:
In IL:OLDFAULT1:
IL:DON\'T is an undefined function
The backtrace:
17: bt
IL:OLDFAULT1
IL:NEWFAULT1
IL:FAULTAPPLY
IL:DON\'T
IL:DOUSERFNS2
SI::*UNWIND-PROTECT*
IL:REDISPLAYW
IL:MOVEW
IL:ACE
APPLY
XCL::NOHOOK
(IL:ACE)
EVALHOOK
XCL::UNDOHOOK
XCL::|interpret-UNDOABLY|
(UNDOABLY (IL:ACE))
IL:EVAL-INPUT
IL:DO-EVENT
XCL::EXECA0001A0002
XCL::EXECA0001
EXEC
T
Some more debugger commands:
21: ?=
FAULTX = IL:DON\'T
FAULTARGS = (#<IL:WINDOW @ 65,150234> (299 0 162 ...) NIL ...)
FAULTAPPLYFLG = T
22: pb faultx
bindings for FAULTX:
@ TOP : IL:NOBIND
23: pb faultargs
bindings for FAULTARGS:
@ TOP : IL:NOBIND
24: pb faultapplyflg
bindings for FAULTAPPLYFLG:
@ TOP : IL:NOBIND
25: btv
IL:FAULTX IL:DON\'T
IL:FAULTARGS (#<IL:WINDOW @ 65,150234> (299 0 162 99)
NIL NIL)
IL:FAULTAPPLYFLG T
IL:OLDFAULT1
IL:NEWFAULT1
IL:FAULTFN IL:DON\'T
IL:FAULTARGS (#<IL:WINDOW @ 65,150234> (299 0 162 99)
NIL NIL)
IL:DEF NIL
IL:%LEXICAL-ENVIRONMENT% NIL
IL:TRAN NIL
IL:TRANFN NIL
IL:FAULTAPPLY
IL:DON\'T
IL:FNLST IL:DON\'T
IL:WINDOW #<IL:WINDOW @ 65,150234>
IL:ARG1 (299 0 162 99)
IL:ARG2 NIL
IL:ARG3 NIL
IL:DOUSERFNS2
SI::*CLEANUP-FORMS* SI::RESETUNWIND
SI::*UNWIND-PROTECT*
IL:WINDOW #<IL:WINDOW @ 65,150234>
IL:REGION (299 0 162 99)
IL:ALWAYSFLG NIL
IL:DSP #<Output Display Stream/56,7700>
IL:REPAINTFN IL:DON\'T
IL:CLIPREG (0 0 461 125)
IL:LISPXHIST ((#) (12 "" . "> ")
"<not yet evaluated>" NIL IL:SIDE (1 #))
SI::*RESETFORMS* ((# NIL) (# NIL) (# NIL))
IL:RESETSTATE NIL
IL:REDISPLAYW
IL:WINDOW #<IL:WINDOW @ 65,150234>
IL:|POSorX| NIL
IL:Y NIL
IL:OLDREGION (500 500 463 139)
IL:USERMOVEFN NIL
IL:OPEN? T
IL:OLDSCREEN #<IL:SCREEN @ 65,151740>
IL:POS (233 . 100)
IL:NEWREGION (233 100 463 139)
IL:OLDLEFT 500
IL:OLDBOTTOM 500
IL:OLDWIDTH 463
IL:OLDHEIGHT 139
IL:OLDCLIPREGION (0 0 299 99)
IL:LFT NIL
IL:BTM NIL
IL:REG NIL
IL:FN NIL
IL:NEWCLIPPINGREGION (0 0 461 125)
IL:NCL 0
IL:OCL 0
IL:NCB 0
IL:OCB 0
IL:OCR 299
IL:NCR 461
IL:OCW 299
IL:NCW 461
IL:OCH 99
IL:NCH 125
IL:OCT NIL
IL:NCT NIL
IL:MOVEW
SEQUENCE NIL
IL:WINDOW NIL
IL:POSITION NIL
IL:APPLICATION NIL
IL:FONT #<IL:FONTDESCRIPTOR @ 74,73464>
IL:TEMP.REGION NIL
IL:ACE
APPLY
*EVALHOOK* NIL
XCL::NOHOOK
*APPLYHOOK* NIL
(IL:ACE)
*EVALHOOK* XCL::UNDOHOOK
CL::*SKIP-EVALHOOK* NIL
*APPLYHOOK* XCL::NOHOOK
CL::*SKIP-APPLYHOOK* NIL
EVALHOOK
*APPLYHOOK* NIL
XCL::UNDOHOOK
XCL::|interpret-UNDOABLY|
(UNDOABLY (IL:ACE))
IL:EVAL-INPUT
IL:RETRYFLAG NIL
IL:HELPCLOCK 527559884
IL:DO-EVENT
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (#)
IL:LISPXHIST ((#) (12 "" . "> ")
"<not yet evaluated>" NIL IL:SIDE (1 #))
IL:HELPCLOCK 0
XCL::EXECA0001A0002
*CURRENT-EVENT* ((#) (12 "" . "> ")
"<not yet evaluated>" NIL IL:SIDE (1 #))
SI::NLSETQ-VALUE NIL
IL:*PROCEED-CASES* (#)
SI::*NLSETQFLAG* NIL
XCL::EXECA0001
IL:\\PROGV
XCL::TOP-LEVEL-P T
XCL::WINDOW #<IL:WINDOW @ 65,150640>
XCL::TITLE-SUPPLIED NIL
XCL::TITLE NIL
IL:*THIS-EXEC-COMMANDS* (#<Hash-Table @ 70,37614>)
XCL::ENVIRONMENT NIL
XCL::PROMPT NIL
XCL::FN IL:EVAL-INPUT
XCL::PROFILE "XCL"
IL:*EXEC-ID* ""
XCL::PROFILE-CACHE (XCL::*PROFILE-NAME* "XCL"
*EVAL-FUNCTION* EVAL *PACKAGE* #<Package XCL-USER>
*READTABLE* #<ReadTable XCL/74,146670> *EXEC-PROMPT*
"> " ...)
EXEC
IL:\\PROC.REPEATEDLYEVALQT
IL:*FORM* (IL:\\PROC.REPEATEDLYEVALQT)
IL:*ARGVAL* NIL
IL:*TAIL* NIL
IL:*FN* IL:\\PROC.REPEATEDLYEVALQT
IL:\\EVALFORM
IL:\#FORM# (IL:\\PROC.REPEATEDLYEVALQT)
IL:*CURRENT-PROCESS* #<Process EXEC/74,107300>
IL:HELPFLAG IL:BREAK!
IL:\\CURRENTDISPLAYLINE 0
IL:\\#DISPLAYLINES 25
IL:\\LINEBUF.OFD #<IO Linebuffer Stream/71,106430>
*READTABLE* #<ReadTable INTERLISP/74,146726>
IL:\\PRIMTERMTABLE #<IL:TERMTABLEP @ 74,141740>
IL:\\PRIMTERMSA #<IL:CHARTABLE @ 74,142000>
IL:|TtyDisplayStream|
#<Output Display Stream/71,106520>
SI::*RESETFORMS* NIL
IL:\\INTERRUPTABLE T
IL:\\TTYWINDOW NIL
IL:READBUF NIL
IL:\\TERM.OFD #<Output Display Stream/71,106610>
*STANDARD-OUTPUT* #<Output Display Stream/71,106610>
*STANDARD-INPUT* #<IO Linebuffer Stream/71,106430>
IL:\\MAKE.PROCESS0
T
It's putting a DON'T atom on the ACE.CONTROL.WINDOW's RESHAPEFN, REPAINTFN, and in some cases, the MOVEFN properties - this is standard, see the IRM (DINFO) entry for SHAPEW. Not sure how it got to the point of trying to call DON'T.
You could exit the break with (RETFROM 'DON\'T NIL) and see what happens after that.
BTW - I would definitely not compile or run this from an XCL exec - it's Interlisp so use an Interlisp exec.
From an Interlisp Exec I recompiled the ACE sources with BCOMPL, loaded the ACE file with (FILESLOAD ACE), evaluated (ACE), and got the same error. I executed (RETFROM 'DON\'T NIL) from the debugger and got the error:
Illegal stack arg: DON\'T
The context of the error:
2/8_: BT
OLDFAULT1
NEWFAULT1
FAULTAPPLY
DON'T
DOUSERFNS2
SI::*UNWIND-PROTECT*
REDISPLAYW
MOVEW
ACE
FAULTEVAL
EVAL
EVAL-INPUT
DO-EVENT
XCL::EXECA0001A0002
XCL::EXECA0001
EXEC
T
2/9_:
2/10_: ?=
FAULTX = DON'T
FAULTARGS = ({WINDOW}#65,150000 (299 0 --) NIL --)
FAULTAPPLYFLG = T
2/11_: PB FAULTX
bindings for FAULTX:
@ OLDFAULT1 : DON'T
@ TOP : NOBIND
2/12_: PB FAULTARGS
bindings for FAULTARGS:
@ OLDFAULT1 : ({WINDOW}#65,150000 (299 0 --) NIL --)
@ FAULTAPPLY : ({WINDOW}#65,150000 (299 0 --) NIL --)
@ TOP : NOBIND
2/13_: PB FAULTAPPLYFLG
bindings for FAULTAPPLYFLG:
@ OLDFAULT1 : T
@ TOP : NOBIND
2/14_: BTV
FAULTX DON'T
FAULTARGS ({WINDOW}#65,150000 (299 0 162 99) NIL NIL)
FAULTAPPLYFLG T
OLDFAULT1
NEWFAULT1
FAULTFN DON'T
FAULTARGS ({WINDOW}#65,150000 (299 0 162 99) NIL NIL)
DEF NIL
%%LEXICAL-ENVIRONMENT%% NIL
TRAN NIL
TRANFN NIL
FAULTAPPLY
DON'T
FNLST DON'T
WINDOW {WINDOW}#65,150000
ARG1 (299 0 162 99)
ARG2 NIL
ARG3 NIL
DOUSERFNS2
SI::*CLEANUP-FORMS* SI::RESETUNWIND
SI::*UNWIND-PROTECT*
WINDOW {WINDOW}#65,150000
REGION (299 0 162 99)
ALWAYSFLG NIL
DSP #<Output Display Stream/71,106250>
REPAINTFN DON'T
CLIPREG (0 0 461 125)
LISPXHIST ((&) (5 "2" . "_ ") "<not yet evaluated>"
NIL SIDE (1 &))
SI::*RESETFORMS* ((& NIL) (& NIL) (& NIL))
RESETSTATE NIL
REDISPLAYW
WINDOW {WINDOW}#65,150000
POSorX NIL
Y NIL
OLDREGION (500 500 463 139)
USERMOVEFN NIL
OPEN? T
OLDSCREEN {SCREEN}#65,151740
POS (301 . 368)
NEWREGION (301 368 463 139)
OLDLEFT 500
OLDBOTTOM 500
OLDWIDTH 463
OLDHEIGHT 139
OLDCLIPREGION (0 0 299 99)
LFT NIL
BTM NIL
REG NIL
FN NIL
NEWCLIPPINGREGION (0 0 461 125)
NCL 0
OCL 0
NCB 0
OCB 0
OCR 299
NCR 461
OCW 299
NCW 461
OCH 99
NCH 125
OCT NIL
NCT NIL
MOVEW
SEQUENCE NIL
WINDOW NIL
POSITION NIL
APPLICATION NIL
FONT {FONTDESCRIPTOR}#74,73464
TEMP.REGION NIL
ACE
*FORM* (ACE)
*ARGVAL* NIL
*TAIL* NIL
*FN* ACE
\EVALFORM
FAULTEVAL
*FORM* (UNDOABLY (ACE))
\EVALFORM
\INTERNAL NIL
EVAL
EVAL-INPUT
RETRYFLAG NIL
HELPCLOCK 601376304
DO-EVENT
SI::*DUMMY-FOR-CATCH* T
SI::*CATCH-RETURN-FROM* (&)
LISPXHIST ((&) (5 "2" . "_ ") "<not yet evaluated>"
NIL SIDE (1 &))
HELPCLOCK 0
XCL::EXECA0001A0002
*CURRENT-EVENT* ((&) (5 "2" . "_ ")
"<not yet evaluated>" NIL SIDE (1 &))
SI::NLSETQ-VALUE NIL
*PROCEED-CASES* (&)
SI::*NLSETQFLAG* NIL
XCL::EXECA0001
\PROGV
XCL::TOP-LEVEL-P T
XCL::WINDOW {WINDOW}#65,150150
XCL::TITLE-SUPPLIED NIL
XCL::TITLE NIL
*THIS-EXEC-COMMANDS* (#<Hash-Table @ 70,37614>)
XCL::ENVIRONMENT NIL
XCL::PROMPT NIL
XCL::FN EVAL-INPUT
XCL::PROFILE "INTERLISP"
*EXEC-ID* "2"
XCL::PROFILE-CACHE NIL
EXEC
*FORM* (EXEC :TOP-LEVEL-P T :PROFILE (QUOTE
"INTERLISP") :ID (QUOTE NIL))
*ARGVAL* NIL
*TAIL* NIL
*FN* EXEC
\EVALFORM
*TAIL* ((EXEC :TOP-LEVEL-P T :PROFILE & :ID &))
PROGN
*FORM* (PROGN (TTYDISPLAYSTREAM &) (PROCESSPROP & & &
) (EXEC :TOP-LEVEL-P T :PROFILE & :ID &))
\EVALFORM
%#FORM# (PROGN (TTYDISPLAYSTREAM &) (PROCESSPROP & & &) (EXEC :TOP-LEVEL-P T :PROFILE & :ID &))
*CURRENT-PROCESS* #<Process EXEC#2/74,107000>
HELPFLAG BREAK!
\CURRENTDISPLAYLINE 0
\#DISPLAYLINES 24
\LINEBUF.OFD #<IO Linebuffer Stream/74,23070>
*READTABLE* #<ReadTable INTERLISP/74,146726>
\PRIMTERMTABLE {TERMTABLEP}#74,141740
\PRIMTERMSA {CHARTABLE}#74,142000
TtyDisplayStream #<Output Display Stream/71,106520>
SI::*RESETFORMS* NIL
\INTERRUPTABLE T
\TTYWINDOW NIL
READBUF NIL
\TERM.OFD #<Output Display Stream/71,106340>
*STANDARD-OUTPUT* #<Output Display Stream/71,106340>
*STANDARD-INPUT* #<IO Linebuffer Stream/74,23070>
\MAKE.PROCESS0
T