Interlisp
reset defaultexternalformat when returning
Returning to previous saved image (after LOGOUT, SYSOUT, MAKESYS, SAVEVM), reset *NEW-SHELL-DEVICE*'s DEFAULTEXTERNALFORMAT to (SYSTEM-EXTERNALFORMAT).
Note that the current code has two devices *SHELL-DEVICE* and *NEW-SHELL-DEVICE* with a comment (1990) that some future release might only use *NEW-SHELL-DEVICE*. That change will be made later.
*SHELL-DEVICE* vs *NEW-SHELL-DEVICE* is about coordinating with the version of maiko and the sub-functions that the unixcomm.c code implements for pipes, sockets, process communication etc. We're definitely on the new version now, but having had to look some at the code in unixcomm.c, it's compensating for some poor choices in the Lisp code. We should probably review that interaction at some point in the future.
this PR just does the minimum to effect the updating. I'm not so happy with the means of determining the external format of process streams -- scanning environment variables is ugly and likely wrong for some -- but we got here. Perhaps the external format should be determined by the subrs that are opening the stream?
I don't think the SUBRs know any better than the Lisp code what the text encoding is (at least by default) -- the code can override defaults by setting values in the environment but otherwise it's left looking at exactly the same environment variables that Lisp would look at, and it would be much harder for the C code to smash an external format into the stream than for the Lisp code to do it. There's a C structure matching the Lisp STREAM datatype, but I don't know that it knows about the external format because that's probably beyond the fields it currently needs to know.
... and having the SUBR or the Lisp code set the encoding behind the user's back would, if it's not really careful, make it impossible for Lisp code that created a shell stream to set the encoding in the environment to override the defaults.
In this case, the default external format doesn't affect existing streams or streams opened with an explicit encoding. It couldn't anyway, because open process/socket/shell streams are closed when starting a saved VM.
Still poking, it now seems that WHEREIS doesn't work. Even though there whereis-hash is open.
IL:COMPILE-FILE is equivalent to FAKE-COMPILE-FILE as per PF* COMPILE-FILE?
Not sure of the history of that.
I think this PR is subsumed by PR #1006 which gets rid of the "old" device in favor of one "new" one. I'm not sure if there will be a conflict, but it won't be too hard to resolve if there is.
I don’t see that IL:COMPILE-FILE exists. Just CL:COMPILE-FILE and FAKE-COMPILE-FILE, for files with commonlisp stuff.
On Oct 25, 2022, at 10:21 PM, Larry Masinter @.***> wrote:
IL:COMPILE-FILE is equivalent to FAKE-COMPILE-FILE as per PF* COMPILE-FILE?
Not sure of the history of that.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/988#issuecomment-1291518512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKFDQ6I3USWSQCZ6LTWFC5V5ANCNFSM6AAAAAARCPKMVQ. You are receiving this because your review was requested.
i'm puzzled by FAKE-COMPILE-FILE and why it was invented and when should it be used, and why 'FAKE:'? I was looking for something else and stumbled on this. I don't remember changing the property but perhaps I did to see if it was equivalent. Maybe we should make a list of questions for people who might know but aren't part of the group?
Between versions 40 and 42, UNIXCOMM acquired a FILETYPE property of FAKE-COMPILE-FILE. I don't know why.
in commit 32128f5e19 UNIXCOMM;40 Jun 22 I noted
- UNIXCOMM compile to DFASL; only set UTF-8 if getenv(LANG). ...
In commit d7ca40ebeb1d1a @rmkaplan noted
- UNIXCOMM: Default format comes from device Also, I seemed to have reverted back to LCOM with FAKE-COMPILE-FILE
I think what might have happened is that I thought I was setting it to make FASLs but put FILETYPE COMPILE-FILE instead of CL:COMPILE-FILE and didn't notice. I'd recommend adding a "compiled file matches FILETYPE" to the PRC "sanity/version match" check.
The "why?" i was wondering was "why FAKE-COMPILE-FILE at all?".
This PR is followed by PR #1006 (assumed by?); shouldn't prc show the relationship?
I think this PR is subsumed by PR #1006 which gets rid of the "old" device in favor of one "new" one. I'm not sure if there will be a conflict, but it won't be too hard to resolve if there is.
Resolving the conflict: close this PR.
I seem to have a newer version of UNIXCOMM (by lmm on October 25 vs October 11), with two differences in INITIALIZE-SHELL-DEVICE. My newer one says that the device is FDBINABLE, which I’m not sure about. It also has all the method-functions wrapped in FUNCTION instead of QUOTE, which does seem like a good idea—masterscope should be able to find them
Should I push out the version that I have, in a mini-PR ?
On Dec 7, 2022, at 10:19 AM, Larry Masinter @.***> wrote:
I think this PR is subsumed by PR #1006 https://github.com/Interlisp/medley/pull/1006 which gets rid of the "old" device in favor of one "new" one. I'm not sure if there will be a conflict, but it won't be too hard to resolve if there is.
Resolving the conflict: close this PR.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/988#issuecomment-1341382531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJNORYWKLJ7WROXPUS3WMDIJLANCNFSM6AAAAAARCPKMVQ. You are receiving this because you were mentioned.
I think if you have newer version(s) of file(s) that you could check out a new branch with differences you're not sure of, and then just ask for review. The QUOTE => Function change only happens in the UNIXCOMCOMS which Masterscope currently doesn't analyze.