Populating ALLOCSTRING strings with characters

[pamoroso]

If I allocate a string with ALLOCSTRING in Interlisp what is the typical way of populating the string by setting individual characters? Wtih RPLCHARCODE and code like this?

10_ (SETQ S (ALLOCSTRING 3))
"\00\00\00"
11_ S
"\00\00\00"
12_ (RPLCHARCODE S 1 (CHARCODE B))
"B\00\00"
13_ (RPLCHARCODE S 2 (CHARCODE y))
"By\00"
14_ (RPLCHARCODE S 3 (CHARCODE e))
"Bye"
15_ S
"Bye"

[nbriggs]

I wouldn't populate it one character at a time - (RPLSTRING S 1 "Bye") would be better.

[pamoroso]

I was wondering about the case where you need to set the string character by character, for example by reading a stream one character at a time.

[nbriggs]

Seems like a situation to be avoided as inefficient. I'd look for ways to redesign what was going on rather than go down that path.

[masinter]

file devices and others are "buffered" and read a buffer-full of characters using BINS rather than BIN.

It seems likely that some of the tuning was lost with the character changes to support Unicode and end-of-line convention changes.... if you're reading from a non-MCCS stream into MCCS then you need to call the character reader and not buffer.

Also, RPLCHARCODE needs to make a decision to convert the string from thin to fat.

[pamoroso]

I have in mind the output stream of ShellCommand, using a string as a buffer to read a line at a time from the stream.

[rmkaplan]

You might take a look at GIT-RESULT-TO-LINES in GITFNS

…

On Aug 10, 2025, at 12:46 PM, Paolo Amoroso ***@***.***> wrote: I have in mind the output stream of ShellCommand, using a string as a buffer to read a line at a time from the stream. — Reply to this email directly, view it on GitHub <#2250 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL2S5VZMQD5G27Q5ED3M6OSXAVCNFSM6AAAAACDRPE6LOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMBWGYYDGNA>. You are receiving this because you are subscribed to this thread.

[pamoroso]

GIT-RESULT-TO-LINES calls CL:READ-LINE but I'm wondering about an Interlisp solution.

[nbriggs]

ShellCommand is already Common Lisp --

(CL:DEFUN ShellCommand (Cmd &OPTIONAL (Output T))
       (CL:WITH-OPEN-STREAM (s (CREATE-PROCESS-STREAM Cmd))
              (CL:TAGBODY (SETFILEINFO s 'ENDOFSTREAMOP #'(CL:LAMBDA (s)
                                                                 (GO OUT)))
                     (CL:LOOP (PRINTCCODE (READCCODE s)
                                     Output))
                     OUT))
       NIL)

which is rather ugly.

[pamoroso]

Yes ShellCommand is Common Lisp, but that part is inevitable if Interlisp needs to communicate with the external world.

[nbriggs]

CREATE-PROCESS-STREAM is about the lowest level, and apart from the fact that it uses a CL:SETF instead of replacing a field in a record, is pure Interlisp. CL:READ-LINE is almost pure Interlisp, except for multiple values -- and you can see how it uses RSTRING to read from the stream.

(LAMBDA (&OPTIONAL STREAM (IL:EOF-ERRORP T)
               IL:EOF-VALUE IL:RECURSIVE-P)
                                                        (IL:* IL:; "Edited 31-Mar-87 18:36 by bvm:")
       
       (IL:* IL:;; 
       "Returns a line of text read from the STREAM as a string, discarding the newline character.")

       (SETQ STREAM (IL:\GETSTREAM STREAM 'IL:INPUT))
       (IL:if (AND (NULL IL:EOF-ERRORP)
                   (NULL IL:RECURSIVE-P)
                   (IL:\EOFP STREAM))
              IL:then IL:EOF-VALUE IL:else (LET ((IL:RESULT (IL:RSTRING STREAM IL:READ-LINE-RDTBL)))
                                                (IL:if (IL:\EOFP STREAM)
                                                       IL:then
                                                       (VALUES IL:RESULT T)
                                                       IL:else
                                                             (IL:* IL:; "consume the eol")
                                                       (IL:READCCODE STREAM)
                                                       (VALUES IL:RESULT NIL)))))

[pamoroso]

I see, thanks. So the trick to read a line is to call RSTRING with an appropriate readtable.

[pamoroso]

Based on the code of CL::INIT-CML-READTABLES I wrote this function to create a readtable suitable for reading a line with RSTRING:

(DEFINEQ

(EOLRDTBL  [LAMBDA NIL

         (* * Return a readtable suitable for reading a line of text with RSTRING.)

    (LET [(RDTBL (COPYREADTABLE 'ORIG]
         (for I from 0 to 255 do (SETSYNTAX I 'OTHER RDTBL))
         (SETBRK (CHARCODE (EOL))
                NIL RDTBL)
         RDTBL])
)

Now I have a related question. Is it possible to modify the readtable to strip (omit altogether from the string returned by RSTRING) the characters with codes not in the ASCII range, or include only some specific control codes such as HT? SETBRK-ing the unwanted codes would omit them but terminate the string before the natural end of the line.

[nbriggs]

That is the definition of IL:READ-LINE-RDTBL (except you introduced a magic number, 255, for which there is a constant \MAXTHINCHAR), which is a global variable, so you should use it rather than defining another one.

There is no basic syntax class for "omit". I didn't see an easy way to get the effect you are looking for with either basic MACRO or SPLICE macro syntax classes.

[pamoroso]

I initially got the error \MAXTHINCHAR is an unbound variable when evaluating \MAXTHINCHAR but then realized it requires SYSEDIT.

[rmkaplan]

SYSEDIT loads EXPORTS.ALL, that's where you can get its constant value.

…

On Aug 16, 2025, at 11:17 PM, Paolo Amoroso ***@***.***> wrote: I initially got the error \MAXTHINCHAR is an unbound variable when evaluating \MAXTHINCHAR but then realized it requires SYSEDIT. — Reply to this email directly, view it on GitHub <#2250 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJK7ESIRWKTDNPSZG4D3OANAJAVCNFSM6AAAAACDRPE6LOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJTGAZDKNA>. You are receiving this because you commented.

[nbriggs]

@pamoroso -- Yes, it's in EXPORTS.ALL. But... adhere to the once-and-only-once principle: don't duplicate the code that makes the IL:READ-STRING-RDTBL, just use that already defined global variable. If you want to modify that read table use COPYREADTABLE (spelling?) to get a new copy and then apply the changes to that.

[pamoroso]

I created a new function because I initially assumed I would need more extensive modifications. But using IL:READ-LINE-RDTBL is indeed cleaner and doesn't require SYSEDIT.