Add :IMPORT-FROM option to DEFPACKAGE #2335

MattHeffron · 2025-10-30T07:07:53Z

This resolves #2334

pamoroso · 2025-10-30T10:09:34Z

When building this PR on Linux Mint 22.1 Cinnamon I get a blank Medley window and the following error:

paolo@lispmachine:~/medley/medley$ ./scripts/loadup-all.sh -apps
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
+++++ SUCCESS +++++
..... files created .....
-rw-rw-r-- 1 paolo paolo 4426752 Oct 30 11:03 /home/paolo/medley/medley/loadups/build/init.dlinit
-rw-rw-r-- 1 paolo paolo 150218 Oct 30 11:03 /home/paolo/medley/medley/loadups/build/init.dribble
-rw-rw-r-- 1 paolo paolo 4279808 Oct 30 11:03 /home/paolo/medley/medley/loadups/build/init.sysout
-rw-rw-r-- 1 paolo paolo 55826 Oct 30 11:02 /home/paolo/medley/medley/loadups/build/RDSYS
-rw-rw-r-- 1 paolo paolo 43012 Oct 30 11:02 /home/paolo/medley/medley/loadups/build/RDSYS.LCOM
-rw-rw-r-- 1 paolo paolo 89183 Oct 30 11:02 /home/paolo/medley/medley/loadups/build/I-NEW
-rw-rw-r-- 1 paolo paolo 70676 Oct 30 11:02 /home/paolo/medley/medley/loadups/build/I-NEW.LCOM
<<<<< END loadup-init

>>>>> START loadup-mid-from-init
"/home/paolo/bin/ldeinit" "/home/paolo/medley/medley/loadups/build/init.dlinit" -id "loadup_mid_from_init_1" -title "Medley::loadup_mid_from_init_1" -g 1024x768 -sc 1024x768 -noscroll -NF
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/home/paolo/medley/medley/loadups/build/loadup-mid-from-init.cm"
VMEM FILE: "/home/paolo/medley/medley/loadups/build/init-mid.sysout"
evaluating initial expressions:
PACKAGE-CONVERSION-TABLE.EXPRESSIONS
LLSUBRS.EXPRESSIONS
FILEIO.EXPRESSIONS
EXTERNALFORMAT.EXPRESSIONS

*Error* URAID Called:
Enter the URaid
#:CL::SYMBOL-PACKAGE

<

I'm at mth52--Add-IMPORT-FROM-to-DEFPACKAGE/c2d89e5 on Medley and nhb-rewrite-version-parser-v2/3d09555 on Maiko.

pamoroso · 2025-10-30T12:21:20Z

I forgot to include the dribble files, here they are from another build that failed in the same way: loadups.zip

nbriggs · 2025-10-30T16:37:59Z

Same.

>>>>> START loadup-mid-from-init
"/Users/briggs/Projects/maiko/darwin.x86_64/ldeinit" "/Users/briggs/Projects/medley/loadups/build/init.dlinit" -id "loadup_mid_from_init_1" -title "Medley::loadup_mid_from_init_1" -g 1024x768 -sc 1024x768 -noscroll -NF
MEDLEYDIR: "/Users/briggs/Projects/medley"
LOGINDIR: "/Users/briggs/Projects/medley/loadups/build/logindir"
GREET FILE: "/Users/briggs/Projects/medley/greetfiles/NOGREET"
REM.CM FILE: "/Users/briggs/Projects/medley/loadups/build/loadup-mid-from-init.cm"
VMEM FILE: "/Users/briggs/Projects/medley/loadups/build/init-mid.sysout"
evaluating initial expressions:
PACKAGE-CONVERSION-TABLE.EXPRESSIONS
LLSUBRS.EXPRESSIONS
FILEIO.EXPRESSIONS
EXTERNALFORMAT.EXPRESSIONS

*Error* URAID Called:
Enter the URaid
#:CL::SYMBOL-PACKAGE

< l u
  0 :    0x11934 : #:RAID
  1 :    0x1191e : #:FAULTAPPLY
  2 :    0x118d2 : #:\INTERPRETER
  3 :    0x11898 : #:U-CASE
  4 :    0x11880 : #:\DEFINEDEVICE
  5 :    0x11868 : #:\NULLDEVICE
  6 :    0x11848 : #:\EVALFORM
  7 :    0x11834 : #:EVAL
  8 :    0x11814 : #:INITIALEVALQT
  9 :    0x11802 : #:CL::T

< f 3
IVAR -------
  11894 : 0x   0  0x 662  *local* #:X  #:CL::NULL

## STACK BF at 0x11896 ##
[cnt=0 ]
ivar : 0x1894
>> Bf's ivar says 0x11894 vs. IVar says 0x1192c
Fname is #:U-CASE
## STACK FX at 0x11898 ##
[cnt = 0 ]
 #alink           0x188a 
 fnhead   0x2fc47c 
 nextblock        0x18cc 
 pc               0xe0 
 nametbl  0x7c0bac 
 #blink           0x0 
 #clink           0x62b 
  118a2 : 0x  7b  0xe0b0  *local* [pvar0]   "CL::NULLTERNALFORMATTYPE#"
  118a4 : 0x   0  0x   0  *local* [pvar1]   #:CL::NIL
  118a6 : 0x  2e  0x15be  *local* [pvar2]   {unknown}0x2e15be
  118a8 : 0x   e  0x   9  *local* [pvar3]   9
  118aa : 0x   0  0x 662  *local* [pvar4]   #:CL::NULL
  118ac : 0x   e  0x   8  *local* [pvar5]   8
  118ae : 0x   e  0x  4c  *local* [pvar6]   76
  118b0 : 0x   0  0x   0  *local* [pvar7]   #:CL::NIL
  118b2 : 0x  7f  0xb8f0  *local* [pvar8]   {#:\UNBOXEDHUNK3}0x7fb8f0
  118b4 : 0x   e  0x   8  *local* [pvar9]   8
  118b6 : 0x   0  0x   0  *local* [pvar10]   #:CL::NIL
  118b8 : 0xffff  0xffff  *local* [pvar11]   [variable not bound]
  118ba : 0xffff  0xffff  *local* [pvar12]   [variable not bound]
  118bc : 0xffff  0xffff  *local* [pvar13]   [variable not bound]

MattHeffron · 2025-10-30T18:25:03Z

I didn't change any code except to add the :IMPORT-FROM handling, and that doesn't use CL:SYMBOL-PACKAGE.
I'm guessing that something happened with the compilation, so I'll try doing the manual (TCOMPL 'LLPACKAGE) again in a clean sysout, and then retry building the loadup.

nbriggs · 2025-10-30T18:33:13Z

The previous LCOM was made with compile-file, according to the comments in it, as was the version in CLTL2. So, i'm not sure if that's COMPILE-FILE or FAKE-COMPILE-FILE... since it's an LCOM.

rmkaplan · 2025-10-30T18:58:09Z

Doesn't it have to be FAKE-COMPILE-FILE? It has a lot of commonlisp FUNCTIONS etc.

…

On Oct 30, 2025, at 11:33 AM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2335) <#2335 (comment)> The previous LCOM was made with compile-file, according to the comments in it, as was the version in CLTL2. So, i'm not sure if that's COMPILE-FILE or FAKE-COMPILE-FILE... since it's an LCOM. — Reply to this email directly, view it on GitHub <#2335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJP2ZIXP6T4Q7RAHD5D32JKX7AVCNFSM6AAAAACKUGUZBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRZGQ4TQMJWG4>. You are receiving this because you are subscribed to this thread.

nbriggs · 2025-10-30T18:59:10Z

Yes - if you FAKE-COMPILE-FILE it you can do a loadup successfully.

Change the FILETYPE to be :FAKE-COMPILE-FILE (per #2336)

MattHeffron · 2025-10-30T21:38:37Z

Per @nbriggs I recompiled with FAKE-COMPILE-FILE by changing the FILETYPE of LLPACKAGE to be :FAKE-COMPILE-FILE.
This also resolves #2336

nbriggs · 2025-10-30T22:59:54Z

I can do a loadup with the revised LLPACKAGE.LCOM. I don't have anything to test the :IMPORT-FROM functionality.

pamoroso · 2025-10-31T11:32:56Z

It now builds successfully but I'm not sure I'm testing the feature properly as I'd expect the call to CREATEW to work here:

masinter · 2025-11-02T05:15:38Z

man cl:import

import adds symbol or symbols to the internals of package, checking for name conflicts with existing symbols either present in package or accessible to it. Once the symbols have been imported, they may be referenced in the importing package without the use of a package prefix when using the Lisp reader.

There isn't anything about referencing an imported symbol using the internal symbol package prefix notation... only if you are in-package("PKG") that you can reference the imported symbol without any package prefix.

masinter

I don't think this PR needs to wait for it, but we should try to make the apperance of internal package prefix notation in our pretty printed source code. It's especially egregious to have :: double colon references to symbols which are internal lexically scoped variables.

I'm not sure where to put the fix to eliminate those uses.

nbriggs · 2025-11-02T05:44:37Z

@masinter - the existing DEFPACKAGE code seems to have carefully used IL: symbols for all the temporary variables, unless they happened to already be symbols in the LISP: package. There are a few places in other functions that use XCL:: temporaries, and a few that really are internal symbols of the XCL package. I'm not sure what the right answer is given that they need to be printed with respect to the define-file-info reader environment so that they can be correctly read back.

MattHeffron · 2025-11-02T06:42:22Z

the existing DEFPACKAGE code seems to have carefully used IL: symbols for all the temporary variables

If it is thought to be appropriate, I can redo this using IL: package local variables.

pamoroso · 2025-11-02T10:46:13Z

What am I doing wrong in this branch?

masinter

@pamaroso apparently the new defpackage in this PR doesn't import the symbol named after all.

If I supply symbols it does:
(defpackage "PKG2" (:USE "LISP" "XCL") (:import-from "IL" il:createw))
followed by (in-package "PKG2") and (createw) will invoke IL:CREATEW.

the DEFPACKAGE arguments for :IMPORT-FROM are defined to be symbols and not strings.

from man cl:defpackage

(:import-from package-name {symbol-name}*)*

:import-from
The symbols named by the argument symbol-names are found in the package named by package-name and they are imported into the package being defined. In no case are symbols created in any package other than the one being define

pamoroso · 2025-11-02T17:45:48Z

The CLHS entry for DEFPACKAGE provides an example of a string as an argument to :IMPORT-FROM:

(defpackage "MY-PACKAGE"
   (:nicknames "MYPKG" "MY-PKG")
   (:use "COMMON-LISP")
   (:shadow "CAR" "CDR")
   (:shadowing-import-from "VENDOR-COMMON-LISP"  "CONS")
   (:import-from "VENDOR-COMMON-LISP"  "GC")
   (:export "EQ" "CONS" "FROBOLA")
   )

masinter · 2025-11-02T17:47:28Z

i remember now that package initialization and specifically the code in LLPACKAGE needs some special manipulation and can't easily be modified because the package system isn't really usablle until the foundation packages (IL, LISP, XCL, XCL-USER) are set up.

pamoroso · 2025-11-02T17:49:43Z

The example still doesn't work for me even if I explicitly import a symbol:

masinter · 2025-11-03T01:49:38Z

I did another PR #2350 with a fix: pass PACKAGE as the second argument to IMPORT so it affects the package defined by the defpackage rather than PACKAGE.
@MattHeffron Suggest either merging that or updating this one.

masinter

IMPORT PACKAGE param fixed

MattHeffron · 2025-11-03T04:18:31Z

Fixed error of missing PACKAGE argument in call to IMPORT.
Rebuilt loadup successfully.
Tested by:

In XCL exec, verifying no symbol "IT" in the "XCL-USER" package. (find-symbol "IT") returned NIL
Change to "USER" package in the exec.
Verifying no symbol "IT" in the "USER" package. (find-symbol "IT") returned NIL
Gave command in the same exec:

(IL:DEFPACKAGE "XCL-USER" (:IMPORT-FROM "IL" "IT"))

Changed back to "XCL-USER" package in the exec.
Verify that symbol "IT" is accessible from that package, and that it is the same symbol as IL:IT
I.e., (find-symbol "IT") returns 2 values:
IT
:INTERNAL
Verify that it is the same symbol as IL:IT
(EQ 'IT 'IL:IT) returns T

Add :IMPORT-FROM option to DEFPACKAGE

c2d89e5

MattHeffron requested review from hjellinek and masinter October 30, 2025 07:07

MattHeffron self-assigned this Oct 30, 2025

MattHeffron added this to common lisp Oct 30, 2025

Fix a couple of variable reference typos.

9d32cfe

Change the FILETYPE to be :FAKE-COMPILE-FILE (per #2336)

MattHeffron linked an issue Oct 30, 2025 that may be closed by this pull request

LLPACKAGE wrong? FILETYPE property #2336

Closed

masinter approved these changes Nov 2, 2025

View reviewed changes

masinter requested changes Nov 2, 2025

View reviewed changes

masinter mentioned this pull request Nov 2, 2025

Add :import-from option to defpackage (import into newly defined package) #2350

Closed

Fix error of missing arg in call to IMPORT.

d224508

masinter self-requested a review November 3, 2025 04:12

masinter approved these changes Nov 3, 2025

View reviewed changes

masinter merged commit 2d91426 into master Nov 3, 2025

github-project-automation bot moved this to Done in common lisp Nov 3, 2025

Uh oh!

Add :IMPORT-FROM option to DEFPACKAGE #2335

Add :IMPORT-FROM option to DEFPACKAGE #2335

Uh oh!

Conversation

MattHeffron commented Oct 30, 2025

Uh oh!

pamoroso commented Oct 30, 2025

Uh oh!

pamoroso commented Oct 30, 2025

Uh oh!

nbriggs commented Oct 30, 2025

Uh oh!

MattHeffron commented Oct 30, 2025

Uh oh!

nbriggs commented Oct 30, 2025

Uh oh!

rmkaplan commented Oct 30, 2025 via email

Uh oh!

nbriggs commented Oct 30, 2025

Uh oh!

MattHeffron commented Oct 30, 2025

Uh oh!

nbriggs commented Oct 30, 2025

Uh oh!

pamoroso commented Oct 31, 2025

Uh oh!

masinter commented Nov 2, 2025

Uh oh!

masinter left a comment

Choose a reason for hiding this comment

Uh oh!

nbriggs commented Nov 2, 2025

Uh oh!

MattHeffron commented Nov 2, 2025

Uh oh!

pamoroso commented Nov 2, 2025

Uh oh!

masinter left a comment

Choose a reason for hiding this comment

Uh oh!

pamoroso commented Nov 2, 2025

Uh oh!

masinter commented Nov 2, 2025

Uh oh!

pamoroso commented Nov 2, 2025

Uh oh!

masinter commented Nov 3, 2025

Uh oh!

masinter left a comment

Choose a reason for hiding this comment

Uh oh!

MattHeffron commented Nov 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants