Some operations on a PSEUDOHOST based name don't work if underlying destination is XNS file server

[nbriggs]

In the sample Dodo network, with a file server FS1:DEV:HAWALA

(PSEUDOHOST 'PUBLIC "{FS1:DEV:HAWALA}<Public>")

I have a file "{PUBLIC}simple.tedit;1" -- doing (PDFFILEP "{FS1:DEV:HAWALA}<Public>simple.tedit;1") works correctly, returning NIL, however
(PDFFILEP "{PUBLIC}simple.tedit;1") fails with ARG NOT SPPCON NIL.

I see that \BULK.DATA.CLOSE is getting called with #<Input Stream on {PUBLIC}simple.tedit;1/135,76400> instead of the #<Input Courier.Bulk.Data Stream/135,143500> that would be supplied in the case of directly referencing the XNS file server name.

[rmkaplan]

What device operation is it calling?Sent from my iPhoneOn May 21, 2026, at 3:17 PM, Nick Briggs ***@***.***> wrote: Assigned #2624 to @rmkaplan. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were assigned.Message ID: ***@***.***>

[nbriggs]

CLOSEFILE.PH called \NSFILING.CLOSEFILE passing it the stream open on the pseudohost.

[rmkaplan]

It's a little tricky, to the extent that I can see what's happening. It seems that an FDEV's close method takes the stream as argument, and the only stream we have is the pseudohost stream whose fullname is the pseudoname and whose operations all indirect to the operations of the truedevice. If the true close-method operates on the fullname of the stream, it will get it wrong. The most immediate fake might be for the CLOSE.PH method to smash the truename into the fullname field before it invokes the backend method, and then smash back the pseudoname on the way out. An alternative would be to have CLOSE.PH create a new proper true stream with all the right back-end information and just execute on that stream. Or the pseudohost implementation strategy could be revisited so that a pseudo stream doesn't just have a pointer to the true FDEV, it actually has a pointer to a conventional stream on that FDEV with all of its true properties (including its true name), and each pseudo operation X works uniformly by apply X to the true stream.

…

On May 21, 2026, at 3:16 PM, Nick Briggs ***@***.***> wrote: nbriggs created an issue (Interlisp/medley#2624) <#2624> In the sample Dodo network, with a file server FS1:DEV:HAWALA (PSEUDOHOST 'PUBLIC "{FS1:DEV:HAWALA}<Public>") I have a file "{PUBLIC}simple.tedit;1" -- doing (PDFFILEP "{FS1:DEV:HAWALA}<Public>simple.tedit;1") works correctly, returning NIL, however (PDFFILEP "{PUBLIC}simple.tedit;1") fails with ARG NOT SPPCON NIL. I see that \BULK.DATA.CLOSE is getting called with #<Input Stream on {PUBLIC}simple.tedit;1/135,76400> instead of the #<Input Courier.Bulk.Data Stream/135,143500> that would be supplied in the case of directly referencing the XNS file server name. — Reply to this email directly, view it on GitHub <#2624>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLTT5XSHZVIJWA743L43554VAVCNFSM6AAAAACZILDSQOVHI2DSMVQWIX3LMV43ASLTON2WKOZUGQ4TQMRWG43TQNA>. You are receiving this because you were assigned.

[nbriggs]

I don't think its the name of the stream that's the problem --

I think it's that the FDEV associated with the stream is a pseudohost FDEV rather than the underlying NS filing FDEV. I looked at two streams, one direct, one via the pseudohost, and they're identical except for the FDEV. Perhaps the pseudohost methods need to put the true FDEV back in the stream's DEVICE field before calling the lower-level methods?

[rmkaplan]

I don't think you should be seeing the true filename after the open, you should be seeing the pseudo name. Where is this device defined?

[nbriggs]

It's an NS filing device, so presumably created out of NSFILING

[rmkaplan]

The way it is supposed to work:

The fullname of the stream is its pseudoname, its FDEV is the pseudofdev.

The stream also has its truename, in a separate internal field, and the pseudofdev also has the true FDEV in a separate internal field.

I see the opening code in NSFILING, but I apparently can't run it without having a clearinghouse or other server set up and available.

[nbriggs]

I'll check whether it works well enough with the maiko master code, to compile with Dodo nethub, and then you can try it against the Dodo release code. Do you have Java installed on your mac? I have java 22.0.1 installed on mine.

[rmkaplan]

Apparently I don't have Java. Easy way to install?

…

On May 22, 2026, at 7:50 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2624) <#2624 (comment)> I'll check whether it works well enough with the maiko master code, to compile with Dodo nethub, and then you can try it against the Dodo release code. Do you have Java installed on your mac? I have java 22.0.1 installed on mine. — Reply to this email directly, view it on GitHub <#2624 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJM75WY7Q43JNCFBSMT44EGXTAVCNFSM6AAAAACZILDSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMRTHE2DSNRRGA>. You are receiving this because you were mentioned.

[nbriggs]

https://www.oracle.com/java/technologies/downloads/#jdk25-mac and download the .dmg installer for macOS for your hardware architecture. I've verified that Dodo will run with that version of Java. I probably won't get to checking against the maiko/master release until tomorrow.

[rmkaplan]

OK, I now seem to have version 26.0.1

…

On May 22, 2026, at 8:35 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2624) <#2624 (comment)> https://www.oracle.com/java/technologies/downloads/#jdk25-mac and download the .dmg installer for macOS for your hardware architecture. I've verified that Dodo will run with that version of Java. I probably won't get to checking against the maiko/master release until tomorrow. — Reply to this email directly, view it on GitHub <#2624 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNEBDQ42XALJMU4MHT44EL73AVCNFSM6AAAAACZILDSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMRUGA2DCOBRGE>. You are receiving this because you were mentioned.

[nbriggs]

Starting with the master branch of maiko, edit bin/makefile-darwin.aarch64-x to add -DMAIKO_ENABLE_NETHUB to the DFLAGS line (diff below).

Clean and rebuild maiko -- (from the bin directory): ./makeright x cleanup && ./makeright x

Make sure that this version of maiko is the one you'll get when you start medley.

diff --git a/bin/makefile-darwin.aarch64-x b/bin/makefile-darwin.aarch64-x
index 37da65e..0862fc9 100644
--- a/bin/makefile-darwin.aarch64-x
+++ b/bin/makefile-darwin.aarch64-x
@@ -18,7 +18,7 @@ XFLAGS = -I/opt/X11/include -DXWINDOW
 # OPTFLAGS is normally -O2.
 OPTFLAGS =  -O2
 DEBUGFLAGS = # -DDEBUG -DOPTRACE
-DFLAGS = $(DEBUGFLAGS) $(XFLAGS) -DRELEASE=$(RELEASE)
+DFLAGS = $(DEBUGFLAGS) $(XFLAGS) -DRELEASE=$(RELEASE)  -DMAIKO_ENABLE_NETHUB
 
 LDFLAGS = -L/opt/X11/lib -lX11 -lm
 LDELDFLAGS =  -L/opt/X11/lib -lX11 -lm

If you don't already have Dodo checked out, get it here:

https://github.com/devhawala/dodo.git

In that dodo directory, unzip the dist.zip file (it will unpack to the dist directory) then move the dist directory to, say, ../dodo-xns-services. From that directory you should be able to run

./run-nethub.sh &
sleep 10
./run-dodoserver.sh &

(I put this into a shell script, start.sh, in the dodo-xns-services directory and start it from there)

Once Dodo is running, you should be able to start a full.sysout with the maiko version with Dodo support compiled in, and then do FB {fs1:}<Public> -- user name motu, password master. I don't know if it has any files to start with. You should be able to make one using that login.

[nbriggs]

Oh, I forgot one thing -- you have to pass these options to lde on startup so it will connect to the Dodo server:

-nh-host localhost -nh-mac CA-FF-EE-33-44-55

I don't know how you're starting your Medley instances -- I do this, my working medley is in medley, I have the Maiko version I'm testing on my PATH --

 % echo $PATH
/Users/briggs/Projects/maiko-master/darwin.x86_64/:/usr/local/bin:...

(cd medley && ./run-medley -noscroll -g 1280x1024 -sc 1280x1024  -nh-host localhost -nh-mac CA-FF-EE-33-44-55 loadups/full.sysout )

[rmkaplan]

What is this relative to? ../dodo-xns-services

…

On May 22, 2026, at 10:10 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2624) <#2624 (comment)> Starting with the master branch of maiko, edit bin/makefile-darwin.aarch64-x to add -DMAIKO_ENABLE_NETHUB to the DFLAGS line (diff below). Clean and rebuild maiko -- (from the bin directory): ./makeright x cleanup && ./makeright x Make sure that this version of maiko is the one you'll get when you start medley. diff --git a/bin/makefile-darwin.aarch64-x b/bin/makefile-darwin.aarch64-x index 37da65e..0862fc9 100644 --- a/bin/makefile-darwin.aarch64-x +++ b/bin/makefile-darwin.aarch64-x @@ -18,7 +18,7 @@ XFLAGS = -I/opt/X11/include -DXWINDOW # OPTFLAGS is normally -O2. OPTFLAGS = -O2 DEBUGFLAGS = # -DDEBUG -DOPTRACE -DFLAGS = $(DEBUGFLAGS) $(XFLAGS) -DRELEASE=$(RELEASE) +DFLAGS = $(DEBUGFLAGS) $(XFLAGS) -DRELEASE=$(RELEASE) -DMAIKO_ENABLE_NETHUB LDFLAGS = -L/opt/X11/lib -lX11 -lm LDELDFLAGS = -L/opt/X11/lib -lX11 -lm If you don't already have Dodo checked out, get it here: https://github.com/devhawala/dodo.git In that dodo directory, unzip the dist.zip file (it will unpack to the dist directory) then move the dist directory to, say, ../dodo-xns-services. From that directory you should be able to run ./run-nethub.sh & sleep 10 ./run-dodoserver.sh & (I put this into a shell script, start.sh, in the dodo-xns-services directory and start it from there) Once Dodo is running, you should be able to start a full.sysout with the maiko version with Dodo support compiled in, and then do FB {fs1:}<Public> -- user name motu, password master. I don't know if it has any files to start with. You should be able to make one using that login. — Reply to this email directly, view it on GitHub <#2624 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPJPL24A5XMEPG7MXD44EXEZAVCNFSM6AAAAACZILDSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMRUGIZTSOJXGY>. You are receiving this because you were mentioned.