Interlisp.org
Replies: 14 comments 13 replies
-
|
A first thought is |
Beta Was this translation helpful? Give feedback.
-
|
I don’t see FUN1 defined in the filecoms for the file, so it isn’t being saved to the file.
… On Oct 7, 2023, at 3:50 PM, Paolo Amoroso ***@***.***> wrote:
A first thought is XCL:DEFINE-FILE-ENVIRONMENT doesn't evaluate any of the arguments, so I shouldn't pass (DEFPACKAGE "PKGTEST" (:USE "LISP" "XCL")) but "PKGTEST".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Anzus. I loaded the source in a new session and defined the function |
Beta Was this translation helpful? Give feedback.
-
|
I went through the same steps again, with a couple of differences. First, I defined the Here's the transcript of the first session When I load the symbolic file
Here's the symbolic file If I pass |
Beta Was this translation helpful? Give feedback.
-
|
What I’m trying to say is that looking at the files you’ve sent, the COMS variable for PKGTEST doesn’t contain a FUNCTIONS reference for FUN1 so it’s not getting saved to the file. When you load your file into a fresh sys out, FUN1 isn’t there in the new image. After defining FUN1 run (FILES?) again and it’ll ask you if you want to put it somewhere, add it to PKGTEST and then make the file again.
… On Oct 8, 2023, at 8:16 AM, Paolo Amoroso ***@***.***> wrote:
Thanks @Anzus. I loaded the source in a new session and defined the function FUN1. Calling FUN1 still yelds an error as the symbol isn't exported from PKGTEST, but this is likely due to the incorrect definition of the package:
3> (LOAD 'PKGTEST)
; Loading {DSK}<home>medley>il>PKGTEST.;3
; File created 7-Oct-2023 09:22:33
; IL:PKGTESTCOMS
IL:|{DSK}<home>medley>il>PKGTEST.;3|
4> (ED 'PKGTEST:FUN1 '(FUNCTIONS :DONTWAIT))
PKGTEST:FUN1 has no FUNCTIONS definition.
Select a definer to use for a dummy definition.
PKGTEST:FUN1
5> (PKGTEST:FUN1)
Undefined car of form
PKGTEST::CREATEW
6> (APROPOS "CREATEW" :PKGTEST)
PKGTEST::CREATEW
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You're right, I hadn't tried saving Here's the Since I imported the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight. I assumed that, once By the way, the Lyric Common Lisp implementation notes, on page 38 of the PDF, discuss an example of importing the |
Beta Was this translation helpful? Give feedback.
-
|
Yes, re page 38 - and notice that it imports IL:CREATEW, not CREATEW. |
Beta Was this translation helpful? Give feedback.
-
|
In the steps I described here I think I was careful to qualify |
Beta Was this translation helpful? Give feedback.
-
|
Look carefully at the text of the PKGTEST file - it's unclear to me which DEFPACKAGE is actually going to control the creation of the package - there are multiple definitions. |
Beta Was this translation helpful? Give feedback.
-
|
It's unclear to me too, I only add the package definitions I mentioned in the steps above. |
Beta Was this translation helpful? Give feedback.
-
|
@MattHeffron This is the Common Lisp package issue mentioned in the latest weekly meeting, I'd appreciate your feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Also,
(DEFPACKAGE "PKGTEST" (:USE "LISP" "XCL")
(:EXPORT FUN1)
(:IMPORT CREATEW))
Doesn’t say which package to import CREATEW from. What you probably want is
(DEFPACKAGE "PKGTEST" (:USE "LISP" "XCL")
(:EXPORT FUN1)
(:IMPORT IL:CREATEW))
… On Oct 9, 2023, at 5:32 PM, Nick Briggs ***@***.***> wrote:
Look carefully at the text of the PKGTEST file - it's unclear to me which DEFPACKAGE is actually going to control the creation of the package - there are multiple definitions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I actually do add the package qualifier when importing |
Beta Was this translation helpful? Give feedback.
-
|
@pamoroso I was digging around in the source code to see if I could find an easy way to make it work close to the way that you tried. I didn't really see it. What I did, way back in the mid 1980's, was to setup the DEFINE-FILE-INFO with the basic information in the DEFPACKAGE, such as NICKNAMES, PREFIX-NAME, and USE (and EXTERNAL-ONLY for some of my packages). Any other modification of the package was done as part of the COMS in a P command. (IL:RPAQQ IL:MPLOADCOMS
((IL:P (IL:|for| IL:S IL:|in|
'("\\GETWINDOWHEIGHT" "BITBLT" "BITMAPBIT" "BITMAPCREATE" "BITMAPHEIGHT"
"BITMAPWIDTH" "BKSYSCHARCODE" "BLTSHADE" "CHARCODE" "CHARWIDTH"
"CLEARBUF" "CONCAT" "DEL.PROCESS" "DSPCLIPPINGREGION" "DSPFONT"
"DSPRESET" "FIND-READTABLE" "FIXPXLS" "FONTHEIGHT" "FONTPROP"
"GETMOUSESTATE" "GETSTREAMPROP" "INPUT" "INSIDEP" "INTERRUPTCHAR"
"LASTMOUSEBUTTONS" "LASTMOUSEX" "LASTMOUSEY" "SHRINKW" "TAB"
"THIS.PROCESS" "WHITESHADE" "WINDOWPROP")
IL:|do|
(IMPORT (FIND-SYMBOL IL:S "IL")
"MP"))
(IL:* IL:|;;|
"Make sure the symbols already exist before they get loaded from in a KB. These are initially defined in other files.")
'(YES NO UNKNOWN PREMISE ANTECEDENT ACTION CURULE QUESTION.ANSWER.RECORD
ANTECEDENT-FOR-PARMS HALFTRACED TRACING DEFAULT ANTECEDENT-IN RULERECORD ASKED
TYPE-IN C.UPDATED-BY.FILE PROMPT PERMANENT.CONSTRAINTS TEXT WORKING.GOALS
ACTIVATED REPLAY.ANSWERS ANSWER.OR.CONCLUSION.CHANGED CHANGE.ANSWER POSNUMB
HOURS MINUTES EXPECT LEGALVALS YESNO YESNO.UNKNOWN FROMLEGALVALS RANGE
MULTIVALUED FACT.TABLE DOMAIN.VARIABLES SCRATCH.VARIABLES FACT.TABLES
ROOT-CONTEXT VALUE.TRANSLATIONS DOM.SCR.VARIABLES GOALS PARMS RULEGROUPS
NOTCOMPILEDRULES PRUNEDRULES UPDATED-BY USED-BY *PLAN-FILENAMES* *CPB.BUILT*
RIGHT MIDDLE LEFT ACTIVATED.BY RULESFILENAME *TOP-LEVEL-NAME* TRANS)
(IL:* IL:|;;| "Can't just call WINDOWPROP here or else the symbol gets created in the MP package when the COMS are read in, and then when the IMPORT above is done, you get a name conflict.")
(FUNCALL (FIND-SYMBOL "WINDOWPROP" "IL")
(IL:WFROMDS T T)
'IL:PAGE.WAIT-SECONDS 0))etc. |
Beta Was this translation helpful? Give feedback.
-
|
@MattHeffron Thanks for sharing your experience and insight, I'll study it and experiment further. In the meantime I'd like to clarify the intent behing the convoluted steps I described here. Since Lisp software is usually developed incrmentally in an exploratory process, I want to devise a workflow for evolving package definitions (e.g. adding and exporting symbols, importing useful symbols) along with the code in such a way that the File Manager keeps track of the changes. |
Beta Was this translation helpful? Give feedback.
-
|
@MattHeffron I have a few questions and comments on a couple of things you said.
How did you set up the
Reading the Medley documentation gave me the impression the File Manager notices package changes. For example, issue 5 of the HOTLINE! newsletter says on page 8 of the PDF:
On page 9 this and the text that follows:
|
Beta Was this translation helpful? Give feedback.
-
How did you set up the |
Beta Was this translation helpful? Give feedback.
-
|
I setup the |
Beta Was this translation helpful? Give feedback.
-
|
Does it make sense to provide a definition for PACKAGES as a FILEPKG command and as a FILEPKG type, like RECORDS, VARS etc.?
… On Oct 10, 2023, at 6:28 PM, Matt Heffron ***@***.***> wrote:
@pamoroso <https://github.com/pamoroso> I was digging around in the source code to see if I could find an easy way to make it work close to the way that you tried. I didn't really see it. What I did, way back in the mid 1980's, was to setup the DEFINE-FILE-INFO with the basic information in the DEFPACKAGE, such as NICKNAMES, PREFIX-NAME, and USE (and EXTERNAL-ONLY for some of my packages). Any other modification of the package was done as part of the COMS in a P command.
DEFPACKAGE is not defined in the same way as DEFUN, DEFMACRO, DEFPARAMETER, etc. The Interlisp File Package does not detect changes to the definition of a package, so whatever was used in the DEFINE-FILE-INFO will be what's written at the next MAKEFILE.
When the DEFINE-FILE-INFO specified a package other than IL, then the COMS are written in that package. HOWEVER, once symbols from IL have been imported into this package, then they will not be prefixed in the COMS the next time the file is written. So, when I wanted to IMPORT a symbol into my MP package from the IL package, I used a construct like:
(IL:RPAQQ IL:MPLOADCOMS
((IL:P (IL:|for| IL:S IL:|in|
'("\\GETWINDOWHEIGHT" "BITBLT" "BITMAPBIT" "BITMAPCREATE" "BITMAPHEIGHT"
"BITMAPWIDTH" "BKSYSCHARCODE" "BLTSHADE" "CHARCODE" "CHARWIDTH"
"CLEARBUF" "CONCAT" "DEL.PROCESS" "DSPCLIPPINGREGION" "DSPFONT"
"DSPRESET" "FIND-READTABLE" "FIXPXLS" "FONTHEIGHT" "FONTPROP"
"GETMOUSESTATE" "GETSTREAMPROP" "INPUT" "INSIDEP" "INTERRUPTCHAR"
"LASTMOUSEBUTTONS" "LASTMOUSEX" "LASTMOUSEY" "SHRINKW" "TAB"
"THIS.PROCESS" "WHITESHADE" "WINDOWPROP")
IL:|do|
(IMPORT (FIND-SYMBOL IL:S "IL")
"MP"))
(IL:* IL:|;;|
"Make sure the symbols already exist before they get loaded from in a KB. These are initially defined in other files.")
'(YES NO UNKNOWN PREMISE ANTECEDENT ACTION CURULE QUESTION.ANSWER.RECORD
ANTECEDENT-FOR-PARMS HALFTRACED TRACING DEFAULT ANTECEDENT-IN RULERECORD ASKED
TYPE-IN C.UPDATED-BY.FILE PROMPT PERMANENT.CONSTRAINTS TEXT WORKING.GOALS
ACTIVATED REPLAY.ANSWERS ANSWER.OR.CONCLUSION.CHANGED CHANGE.ANSWER POSNUMB
HOURS MINUTES EXPECT LEGALVALS YESNO YESNO.UNKNOWN FROMLEGALVALS RANGE
MULTIVALUED FACT.TABLE DOMAIN.VARIABLES SCRATCH.VARIABLES FACT.TABLES
ROOT-CONTEXT VALUE.TRANSLATIONS DOM.SCR.VARIABLES GOALS PARMS RULEGROUPS
NOTCOMPILEDRULES PRUNEDRULES UPDATED-BY USED-BY *PLAN-FILENAMES* *CPB.BUILT*
RIGHT MIDDLE LEFT ACTIVATED.BY RULESFILENAME *TOP-LEVEL-NAME* TRANS)
(IL:* IL:|;;| "Can't just call WINDOWPROP here or else the symbol gets created in the MP package when the COMS are read in, and then when the IMPORT above is done, you get a name conflict.")
(FUNCALL (FIND-SYMBOL "WINDOWPROP" "IL")
(IL:WFROMDS T T)
'IL:PAGE.WAIT-SECONDS 0))
etc.
Also, note that the (IMPORT ...) is the first thing in the COMS, so that it's done before the definitions that follow are printed to the file, because they will be printed without the IL: prefix, since when the file is next written, the IMPORT will have been done.
Once I figured this out (back in the ancient past) it has worked very well. I hope this helps.
—
Reply to this email directly, view it on GitHub <#1340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOWHSDPO4Z26MTAVZDX6XY5TAVCNFSM6AAAAAA5XB4KRCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TENBXGQYDO>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
Have a read through https://bitsavers.org/pdf/xerox/interlisp-d/hotline/05_19871016.pdf on packages. This touches on the issues that @MattHeffron noted above. |
Beta Was this translation helpful? Give feedback.
-
|
packages are probably not something you should define incrementally because many parts of the environment assume you can random access a source file knowing only the DEFINE-FILE-INFO at the top of the file. There is no per-funcdtion/per-definer variation supported. You can write such programs and import them if necessary. I think for the typical incremental development, you don't start with enough of an understanding of the program to predict. Why import IL:CREATEW -- maybe you save 3 keystrokes in SEdit -- but it adds to the complexity needed for anyone to understand. (There are a couple of other "gotcha"'s in Common LIsp that are difficult to deal with but not many; the one that comes to mind is #+ and #-. These things were issues in X3J13 ... |
Beta Was this translation helpful? Give feedback.
-
|
I will echo the comment about not doing package stuff incrementally. I’m afraid that package manipulation was easier with non-resident environments. One other “hack” to handle this is to have a non-Medley-managed file (i.e., a lisp source file that has been edited with a text editor) that has all the package definition/manipulation stuff in pure CL that is loaded before the collection of Medley files, so that all the symbols you need to cross package boundaries are defined before they get created in the wrong place. Looking at things like PKG.LISP in the PCL sources, I suspect this is not that unusual a technique in the pure-CL world, and it’s probably where I picked up the habit. Matt’s solution is more true to the Interlisp way of life.
… On Oct 12, 2023, at 7:14 PM, Larry Masinter ***@***.***> wrote:
packages are probably not something you should define incrementally because many parts of the environment assume you can random access a source file knowing only the DEFINE-FILE-INFO at the top of the file. There is no per-funcdtion/per-definer variation supported. You can write such programs and import them if necessary.
I think for the typical incremental development, you don't start with enough of an understanding of the program to predict. Why import IL:CREATEW -- maybe you save 3 keystrokes in SEdit -- but it adds to the complexity needed for anyone to understand.
(There are a couple of other "gotcha"'s in Common LIsp that are difficult to deal with but not many; the one that comes to mind is #+ and #-.
These things were issues in X3J13 ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
My solution is as Arun noted. The package definition is all in the xxLOAD file for the project. If I need to modify a package definition, I can edit the xxLOADCOMS, write a new xxLOAD file, and then exit, spin up a clean sysout, and re-LOAD the project; and I'm back "in business". (It's so much faster now, vs. then, that it's hardly worth thinking about finding a "more efficient" way to do it.) (Hi Arun. I'm not sure if we've communicated since AAAI-91 in Anaheim, when I brought you to visit our "AI Lab" at Beckman!) |
Beta Was this translation helpful? Give feedback.
-
|
Another thing ... is that within a "project", whenever I create a new file I just copy the |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Arun, that the way that packages are incorporated into Medley’s residential programming model with managed files is not well thought out, cumbersome, and error prone (also see previous comments in #474).
The intuitive scenario in the simplest case would be that a file FOO that wants to be loaded with unqualified symbols in a package FOOPKG defines that package in its commands FOOCOMS, so that everything is self-contained. FOO’s DEFINE-FILE-INFO would simply say that FOO uses package FOOPKG, no need for a little file off to the side that exists just to provide the package that the DEFINE-FILE-INFO of FOO can load before FOO itself is read.
The (or at least one) problem is what in linguistics is called an ordering paradox. If FOOPKG is specified inside FOOCOMS and appears later in the file, DEFINE-FILE-INFO can’t get to that specification without crossing over lots of symbols that can’t be interpreted without already having obtained that specification.
A possible solution is to arrange it so that DEFINE-FILE-INFO can get to and execute the package specification locally in FOO without first tripping over other symbols, storing other data, evaluating other expressions etc.
So here’s a proposal, based on the way that the EXPORTS filepkg command and GATHER-EXPORTS work for extracting declarations from a collection of source files without loading anything else from those files.
1. Introduce a filepkg command PACKAGES that puts out code that, when executed, defines all of the properties that currently exist in memory for whatever packages are specified. E.g. Putting (PACKAGES “FOOPKG") in FOOCOMS would produce code that recreates FOOKPKG on loading.
But: in front of all the FOOKPGG-defining code, also put out a magical comment string “DEFINITION FOR FOOPKG” (or maybe there is just some recognizable part of the code (like (DEFPACKAGE FOOPKG…) that will serve the intended purposes). That purpose is to be able to find the FOOPKG specification in the file by a simple string search that doesn’t need to interpret any other characters that come before or after it in the file.
2. Extend DEFINE-FILE-INFO (actually, the function \DO-DEFINE-FILE-INFO) to deal with the case that the file’s package (identified simply by its name, no complicated or redundant expression) doesn’t already exist. In that case, if it doesn’t see a form to EVAL, it would scan the file for the magical string, execute the defining code to create the package on the fly, and then loads the rest of the file.
In other words, with this setup the DEFINE-FILE-INFO can find and create the needed package before it looks at any other symbols in the file—the package will always be created first.
3. It might also help to define a FILEPKGTYPE for packages, so that all the properties for a package can be brought up for editing in the obvious way.
A little more complicated is the case of a multi-file application, like TEDIT, where the package is defined in one of the files but is required before any of the others can be loaded. Each of them could specify its DEFINE-FILE-INFO with a form that indicates the package name and the file it is contained in, and DEFINE-FILE-INFO would do the scan on that other file, again without having to deal with anything else on that file. This is like the current mode of having a separate little package-file, except that the package does not have to be isolated in its own stand-alone file.
BTW, the HOTLINE also has examples of creating the makefile environment on the property list of the file, and preserving that property explicitly on the file. I think that the various reader environment elements can be included in the OPTIONS to the original MAKEFILE, and that afterwards they are automatically carried along to new versions. The first argument of CLEANUP, if it's a list, is also passed down as options to the makefile. That seems like a more coherent way of interacting with this stuff.
… On Oct 12, 2023, at 5:58 PM, Arun Welch ***@***.***> wrote:
I will echo the comment about not doing package stuff incrementally. I’m afraid that package manipulation was easier with non-resident environments. One other “hack” to handle this is to have a non-Medley-managed file (i.e., a lisp source file that has been edited with a text editor) that has all the package definition/manipulation stuff in pure CL that is loaded before the collection of Medley files, so that all the symbols you need to cross package boundaries are defined before they get created in the wrong place. Looking at things like PKG.LISP in the PCL sources, I suspect this is not that unusual a technique in the pure-CL world, and it’s probably where I picked up the habit. Matt’s solution is more true to the Interlisp way of life.
> On Oct 12, 2023, at 7:14 PM, Larry Masinter ***@***.***> wrote:
>
>
> packages are probably not something you should define incrementally because many parts of the environment assume you can random access a source file knowing only the DEFINE-FILE-INFO at the top of the file. There is no per-funcdtion/per-definer variation supported. You can write such programs and import them if necessary.
> I think for the typical incremental development, you don't start with enough of an understanding of the program to predict. Why import IL:CREATEW -- maybe you save 3 keystrokes in SEdit -- but it adds to the complexity needed for anyone to understand.
> (There are a couple of other "gotcha"'s in Common LIsp that are difficult to deal with but not many; the one that comes to mind is #+ and #-.
> These things were issues in X3J13 ...
> —
> Reply to this email directly, view it on GitHub, or unsubscribe.
> You are receiving this because you were mentioned.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub <#1340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLBBBPDQITKZBKE36DX7CG5BANCNFSM6AAAAAA5XB4KRA>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
To adapt my Interlisp development workflow to Common Lisp I'm putting together a test case of a simple Common Lisp program, which just calls
IL:CREATEWfrom a functionFUN1, coded across a number of Medley sessions.However, my understanding of how Medley manages packages is still incomplete and the program doesn't work as I expect. Here are the steps I go through.
In a XCL Exec of a Common Lisp Interlisp Online session I define the file environment of the program and create the coms file:
I can now edit the coms to add the export to the package definition:
The modified coms looks like this:
and I can save it:
Next, in a XCL Exec of a fresh session I load the new file and edit the coms to import
IL:CREATEW:At this point the coms looks like this:
Next, I evaluate the package definition to update the running image:
Finally, I define the function
PKGTEST:FUN1that callsIL:CREATEW:This is the code of
PKGTEST.FUN1:Calling
PKGTEST.FUN1opens a new window as expected and so I can save the updated file:Again at a XCL Exec of yet another session I load the file, call
PKGTEST:FUN1, and get this error:FUN1is apparently exported fromPKGTEST, so why can't I call it via the properly qualified name?Here is the
FILEPKGsource file:PKGTEST.TXT
Beta Was this translation helpful? Give feedback.
All reactions