Invalid argument list error when delivering Lafite message over NS/Dodo

[pamoroso]

When I deliver a formatted Lafite message over NS with Dodo I get a break window with the error:

INVALID-ARGUMENT-LIST
In \ILLEGAL-ARG:
Invalid argument: 61286

To Reproduce

Steps to reproduce the behavior:

1. launch Dodo
2. launch Medley built with support for Ethernet, PCAP, and NetHub
3. evaluate (FILESLOAD LAFITE)
4. evaluate (FILESLOAD LAFITE-NEWNSMAIL)
5. evaluate (LAFITEMODE 'NS)
6. evaluate (LAFITE 'ON)
7. compose a new message with text like in the screenshot (the heading is Helvetica 14)
8. click Deliver

Expected behavior

The message is delivered with no errors.

Screenshots

The break window and Medley:

Context (please complete the following information):

• Are you using online.interlisp.org? no
• OS: Linux
• OS Version: Mint 22.1 Cinnamon
• Display/window system: X11/VNC
• Host arch: x86_64 (System76 Merkaat)
• Maiko version: b50f976
• IL:MAKESYSDATE: 17-Jun-2026 20:35:06 (Maiko: nhb-pcap-ethernet/b50f976); Medley: master/5688f31)

Additional context

The stack trace:

MESSAGESENDER/9(debug)BTV
COPYBYTES
\NSMAIL.POST.BODY.PARTA0001
   SI::*DUMMY-FOR-CATCH* T
   SI::*CATCH-RETURN-FROM* :BULKDATA
\COURIER.HANDLE.BULKDATAA0001A0002
   SI::*CLEANUP-FORMS* \COURIER.HANDLE.BULKDATAA0003
SI::*UNWIND-PROTECT*
   DATASTREAM 
#<Output Courier.Bulk.Data Stream/136,171200>
   BULKDATAFN \NSMAIL.POST.BODY.PARTA0001
   NOERRORFLG RETURNERRORS
\COURIER.HANDLE.BULKDATA
   STREAM #<Input Spp Stream/136,171000>
   PROGRAM NEW.MAILTRANSPORT
   PGMDEF ((17 5) TYPES (& & & & & & & & & --) 
PROCEDURES (& & & & &) ERRORS (& & & & & & &))
   PROCEDURE POST.ONE.BODY.PART
   PROCDEF (8 (SESSION BODY.PART.TYPE BULK.DATA.SOURCE) 
RETURNS NIL REPORTS (AUTHENTICATION.ERROR SERVICE.ERROR 
OTHER.ERROR SESSION.ERROR TRANSFER.ERROR))
   ARGLIST ((& &) 5 \NSMAIL.POST.BODY.PARTA0001)
   ARGTYPES (SESSION BODY.PART.TYPE BULK.DATA.SOURCE)
   NOERRORFLG RETURNERRORS
   OUTSTREAM #<Output Spp Stream/136,171100>
   SOURCEFLG T
   SINKFLG NIL
   BULKDATAFN \NSMAIL.POST.BODY.PARTA0001
   DATASTREAM 
#<Output Courier.Bulk.Data Stream/136,171200>
COURIER.EXECUTE.CALL
   ARGS 7
   STREAM #<Input Spp Stream/136,171000>
   PROGRAM NEW.MAILTRANSPORT
   PROCEDURE POST.ONE.BODY.PART
   NARGS 3
   ARGLIST ((& &) 5 \NSMAIL.POST.BODY.PARTA0001)
   NOERRORFLG RETURNERRORS
   PGMDEF ((17 5) TYPES (& & & & & & & & & --) 
PROCEDURES (& & & & &) ERRORS (& & & & & & &))
   PROCDEF (8 (SESSION BODY.PART.TYPE BULK.DATA.SOURCE) 
RETURNS NIL REPORTS (AUTHENTICATION.ERROR SERVICE.ERROR 
OTHER.ERROR SESSION.ERROR TRANSFER.ERROR))
   ARGTYPES (SESSION BODY.PART.TYPE BULK.DATA.SOURCE)
COURIER.CALL
   PARTSTREAM #<IO Tedit Stream/130,35700>
   START 90
   ATTRIBUTES NIL
\NSMAIL.POST.BODY.PART
   SI::*CLEANUP-FORMS* SI::RESETUNWIND
SI::*UNWIND-PROTECT*
   MSG #<IO Tedit Stream/130,35700>
   PARSE ("TEdit formatting test" (Paolo Amoroso:) 90 
NIL (Subject . "TEdit formatting test") (To 
Paolo Amoroso:) (cc Paolo Amoroso:))
   EDITORWINDOW {WINDOW}#117,126570
   ABORTWINDOW {WINDOW}#117,126664
   LISPXHIST NIL
   SI::*RESETFORMS* ((& NIL) (&) (&))
   RESETSTATE NIL
\NSMAIL.NEW.SEND
   SI::*CLEANUP-FORMS* SI::RESETUNWIND
SI::*UNWIND-PROTECT*
   SI::*DUMMY-FOR-CATCH* T
   SI::*CATCH-RETURN-FROM* (&)
   LISPXHIST NIL
   SI::*RESETFORMS* NIL
   RESETSTATE NIL
\SENDMESSAGE0A0009
   TEXTSTREAM #<IO Tedit Stream/130,35700>
   WINDOW {WINDOW}#117,126570
   PARSE ("TEdit formatting test" (Paolo Amoroso:) 90 
NIL (Subject . "TEdit formatting test") (To 
Paolo Amoroso:) (cc Paolo Amoroso:))
   *LAFITE-MODE-DATA* ((NS 1 \NSMAIL.NEW.SEND.PARSE 
\NSMAIL.NEW.SEND \NSMAIL.MAKEANSWERFORM 
\NSMAIL.NEW.AUTHENTICATE \NSMAIL.MESSAGE.P 
\NSMAIL.MESSAGE.FROM.SELF.P \NSMAIL.LOGIN) (
"Paolo Amoroso:dev:hawala" & Paolo Amoroso: 
"Paolo Amoroso:" NIL) (&))
   MENUW {WINDOW}#117,126664
   SI::NLSETQ-VALUE NIL
   *PROCEED-CASES* (&)
   SI::*NLSETQFLAG* NIL
\SENDMESSAGE0
\SENDMESSAGE.RESTARTABLE
\SENDMESSAGE
   *FORM* (\SENDMESSAGE (QUOTE 
#<IO Tedit Stream/130,35700>) NIL NIL)
   *ARGVAL* NIL
   *TAIL* NIL
   *FN* \SENDMESSAGE
\EVALFORM
   %#FORM# (\SENDMESSAGE (QUOTE 
#<IO Tedit Stream/130,35700>) NIL NIL)
   *CURRENT-PROCESS* #<Process MESSAGESENDER/172,14000>
   HELPFLAG BREAK!
   \CURRENTDISPLAYLINE 0
   \#DISPLAYLINES 1
   \LINEBUF.OFD #<IO Linebuffer Stream/117,60700>
   *READTABLE* #<ReadTable INTERLISP/172,57714>
   \PRIMTERMTABLE {TERMTABLEP}#172,52740
   \PRIMTERMSA {CHARTABLE}#172,53000
   TtyDisplayStream #<Output Display Stream/136,171300>
   SI::*RESETFORMS* ((& NIL))
   \INTERRUPTABLE T
   \TTYWINDOW NIL
   READBUF NIL
   \TERM.OFD #<Output Display Stream/166,112400>
   *STANDARD-OUTPUT* #<Output Display Stream/166,112400>
   *STANDARD-INPUT* #<IO Linebuffer Stream/117,60700>
\MAKE.PROCESS0
T

[pamoroso]

This only happens with formatted messages as plain text ones are delivered with no errors.

[nbriggs]

ask Ron if it’s an external format issue or Tedit api issue. It looks like a non-byte being found in a copybytes operation.

[pamoroso]

@rmkaplan This may be an external format ot TEdit issue.

[rmkaplan]

Could be. 61286 is the bullet character in MCCS, but it's not a byte that COPYBYTES would be able to handle. If the input is a tedit stream, we may be running into the fact that Tedit streams don't distinguish bytes from characters, and what we want at this level is COPYCHARS instead of COPYBYTES. Or, we may want to copy from the Tedit back file (assuming that the input is not something that has been edited but not put back to a file).

…

On Jun 18, 2026, at 6:45 AM, Paolo Amoroso ***@***.***> wrote: pamoroso left a comment (Interlisp/medley#2667) <#2667 (comment)> @rmkaplan <https://github.com/rmkaplan> This may be an external format ot TEdit issue. — Reply to this email directly, view it on GitHub <#2667?email_source=notifications&email_token=AQSTUJLDCMK6BCXKQE3HJTD5APXAJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGI2TMNBYGU4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4742564858>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKVUAJK2C46W4WYA235APXAJAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TINRZGIYTKNZSGE42C5QC>. You are receiving this because you were mentioned.

[nbriggs]

It's going into a bulk data stream, so it needs to be a byte stream that represents the underlying representation of the (TEdit) document that if reconstituted with a reader from the bulk data stream storing into a file will produce a valid (TEdit) document. That used to be COPYBYTES in, COPYBYTES out as I suspect it's expecting to BOUT and BIN on the bulk data stream - but you should be able to look at the stream functions (on the bulk data stream) when it errors.

[rmkaplan]

Then the input stream should not be a textstream, it should be an ordinary file stream. That is, it should not be copying the textstream (opened with OPENTEXTSTREAM), it should be copying the file that the textstream was put to and that holds its byte representation (opened with OPENSTREAM). Otherwise, the binary formatting data would never be coppied, let alone getting confused about image objects and MCCS characters.

…

On Jun 18, 2026, at 10:43 AM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2667) <#2667 (comment)> It's going into a bulk data stream, so it needs to be a byte stream that represents the underlying representation of the (TEdit) document that if reconstituted with a reader from the bulk data stream storing into a file will produce a valid (TEdit) document. That used to be COPYBYTES in, COPYBYTES out as I suspect it's expecting to BOUT and BIN on the bulk data stream - but you should be able to look at the stream functions (on the bulk data stream) when it errors. — Reply to this email directly, view it on GitHub <#2667?email_source=notifications&email_token=AQSTUJLJONO5RDLKQONM6UT5AQS47A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGQ3DGMJVGUY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4744631551>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLFAXDILPLILGFJVIT5AQS47AVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TINRZGIYTKNZSGE42C5QC>. You are receiving this because you were mentioned.

[nbriggs]

I don't know that the message necessarily exists in a file - it might have started from a form that was modified and the textstream(?) passed to the sender process -- guess we need to break the ADD.PROCESS and see who called it, because it's not obvious from grepping through the code exactly what path it took. As well as formatted documents, we also need to try sending forms based messages to see how the path differs.

[rmkaplan]

If it doesn't exist on a file, then the sender would need to Put it first, maybe to a NODIRCORE, and then copy that. Would I need to get get dodo working again in order to look at this?

…

On Jun 18, 2026, at 2:24 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2667) <#2667 (comment)> I don't know that the message necessarily exists in a file - it might have started from a form that was modified and the textstream(?) passed to the sender process -- guess we need to break the ADD.PROCESS and see who called it, because it's not obvious from grepping through the code exactly what path it took. As well as formatted documents, we also need to try sending forms based messages to see how the path differs. — Reply to this email directly, view it on GitHub <#2667?email_source=notifications&email_token=AQSTUJJMCFXYST75VTJUUXT5ARMYNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGYZDINZWHE3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4746247696>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLUNBM6WGN3FFHLSUT5ARMYNAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TINRZGIYTKNZSGE42C5QC>. You are receiving this because you were mentioned.

[pamoroso]

It would be great if you could make Dodo work again as Lafite is an interesting Interlisp application to showcase, especially formatted messages.

I've broken ADD.PROCESS when delivering a message with bullets and these are the stack frames:

The same with a form based message:

[nbriggs]

I think I see it using COPYTEXTSTREAM. Look for MESSAGESENDER in the file LAFITE-SEND.

[nbriggs]

@pamoroso the idea of breaking ADD.PROCESS is that you say OK to each one until you see the one you're looking for (which was the one that passes in the open textstream -- there will be quite a few, as you've noticed, but they need to proceed or the rest of the action won't happen correctly.

[pamoroso]

Thanks, I was unsure what to do but I think I got it now. For the bullet test I can't proceed further than these frames:

And this is the form test. Again, I can't go further than this:

[rmkaplan]

COPYTEXTSTREAM doesn't make a new backing file, just makes a new stream with an in-memory copy of all the pieces. Lafite's TEDIT.ASSURE.BACKING.FILE looks like it is trying to make a nodircore file that it presumably can then apply COPYBYTES for the copy, maybe that's the logic that it is trying to implement. But it is being passed a closed text stream, that may be why it is failing. I'll look to see whether closing a text stream is destroying more information than it should.

…

On Jun 19, 2026, at 4:50 AM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2667) <#2667 (comment)> I think I see it using COPYTEXTSTREAM. Look for MESSAGESENDER in the file LAFITE-SEND. — Reply to this email directly, view it on GitHub <#2667?email_source=notifications&email_token=AQSTUJIJF7SKYXZ5DYUTQ7D5AUSJNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZVGEZDMOBUGQ2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4751268444>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIFZYA2FRL7IZABRBD5AUSJNAVCNFSNUABFKJSXA33TNF2G64TZHMZDQMJVGE4TSNRUHNEXG43VMU5TINRZGIYTKNZSGE42C5QC>. You are receiving this because you were mentioned.

[rmkaplan]

Turns out it was a simple bug in TEDIT.ASSURE.NO.BACKING.FILE, fixed in #2669 . Didn't depend on whether the stream was closed or not.

This may be part of the problem with Lafite send, but it would be an odd set up for that. What this function does is copy everything to a NODIRCORE file, and then go through the original pieces in the original stream and make them point to that new file, so nothing points to backing information in the original file.

But it doesn't actually return that NODIRCORE file. Instead it saves it as the value of a CACHE property, but sets the usual TXTFILE property to NIL.

Anyway, see if anything works better with this fix.