#xlisp — Public Fediverse posts

So for reasons that are slightly unclear to me, having made a crude 9-pin dot matrix printer emulator, i tracked down the likely Atari ST PD disk that i had as a teenager with XLISP on https://www.atariuptodate.de/en/1329/xlisp-171 and found a tool to extract files from the weird disk format https://bitbucket.org/AnimaInCorpore/msatool/src/master/ and compiled it and ran the XLISP doc through the emulator to get this. A far-too-crisp page, but actually quite reminiscent of my 1989 experience.

( @tartley i mentioned this to you once)
#XLisp

So for reasons that are slightly unclear to me, having made a crude 9-pin dot matrix printer emulator, i tracked down the likely Atari ST PD disk that i had as a teenager with XLISP on https://www.atariuptodate.de/en/1329/xlisp-171 and found a tool to extract files from the weird disk format https://bitbucket.org/AnimaInCorpore/msatool/src/master/ and compiled it and ran the XLISP doc through the emulator to get this. A far-too-crisp page, but actually quite reminiscent of my 1989 experience.

( @tartley i mentioned this to you once)
#XLisp

for the first time in a year i felt like i had the energy/brains to do some actual programming, so I attacked my swi-presenting fork of RISC OS Xlisp.

(swi... ) now acccepts int, char, and string parameters.

i am calling swis that take/return arbitrary sized buffers a seperate problem because theres currently no way to allocate arbitrary sized blocks from xlisp.

and return values from the swi is also for later thought.

#RiscOS #XLisp #codeInC

Looking through the RISC OS source for the old Icon 8 language.
It looks like, in order to give ICON (a nice language, but one with its own ideas about memory usage) a useful SWI interface, they had to add a cheaty call to low-level allocate unformatted blocks of memory, and then add calls to read / write these blocks.

I suspect I'd have to duplicate this work to give xlisp an SWI interface.

I don't know if I'm that good a programmer. Or that modivated. :-(

#xlisp #riscos #icon8

So an xlisp array is a cell
car = length of array
cdr = dynamically allocated array of pointers to cells

not really what I wanted...

#xlisp #riscos

I've been toying with the RISC OS port of XLISP 2.1+, an ancient lisp.

Any language under RISC OS that doesn't provide an interface to the raw SWIs is a toy.

So, I'm attempting to add (swi....).

So far I've:
added a built-in function
made the new function do a hard-coded SWI & properly return its status
made the function accept a numeric parameter and print that parameter

now I need to think about what the rest of the interface should look like.

#riscos #xlisp #swi #lisp

I still want to try adding (swi...) to RISC OS XLISP.
I'm not sure how useful it will be though... Not sure XLISP can handle the data types that the raw OS interface wants.
I mean, how do you tell a LISP to give you an X kilobyte buffer, no structure no typing no blah blah blah?
Nevermind what stuctures the OS itself might want...

XLISP on other operating systems support (system...) and call it good. That works under RISC OS too but... I still wanna try.

#xlisp #riscos

While the result would be kind of neat, I'm not converting the xlisp docs to clearview format. The docs are just too big!

#riscos #clearview #xlisp #nope

Is xlisp still a thing?

Anyway I'm looking at adding a SWI interface to the old RISC OS port I've 32bitted.

Any RISC OS language without swi() is a toy.

Did the easy part. Xlisp now can know the names of all the SWIs (load "swi.lsp"). Now I just gotta do the C code. Fun!

#xlisp #riscos