Re: Simple Instructions/packages for Installing, SBCL/Emacs/Slime ???

Hi Robert,

I've never heard of Roswell.  I'll poke around a bit and see what it can do.

For the short term, what I personally am looking for is just a replacement
for Portacle, which was an easy-to-install package that fired up a Gnu
Emacs, compatible versions of slime and the latest SBCL for MacOS, plus a
few libraries loaded via Quicklisp.  I was able to just hand this Portacle
package to my students and collaborators, they could be on the air in a few
minutes.  And then they could easily load and play with Scone.

You could carry the whole Portacle package on a memory stick and just use
it from there, or install it.  And then you just load the Scone fasl files
and knowledge-base files, and you're running.  But, sadly, the guy who was
maintaining Portacle has apparently lost interest.  :-(

Prior to the appearance of Portacle, for every new version of SBCL and
other components, I had to cobble together the Emacs/SBCL environment from
assorted libraries. it always took me at least a few days to get a new
installation in place and tested.  There were always version
mismatches/incompatibilities with slime, and so on.  So it was just painful
and time-consuming to upgrade to new versions of SBCL (often prodded by new
hardware or MacOS releases).

In building up these environments, I would try to keep careful records of
exactly what I did in the build, but that was hard since there was a fair
amount of trial-and-error and backtracking.  Sometimes the students could
just follow the resulting script and it would work for them; sometimes not.

Scone doesn't really need any exotic system calls.  The current
implementation doesn't use multi-threading, though that is a goal for the
future.  The Scone reasoning algorithm has a LOT of opportunities for
multi-threading and memory optimization, but that's a task for some future
student or programmer who really enjoys that sort of tweaking -- I'm trying
to focus on the AI parts.

In some of our past projects at CMU, we had a Scone/SBCL module running as
a server proecess in a larger multi-process system, written in C++ or Java
or whatever was popular that year.  There wasn't very intense traffic
between the two parts, so we could just put the Scone/SBCL stuff in its own
process and talk to the other parts via text pipes.  Ugly, but it worked
well.

So if I can just get back to that Portacle level of capability and
convenience with the latest SBCL, and only on MacOS, that would solve my
immediate problems.  I do think there would be demand for Windows and
probably Linux versions later.

Cheers,
Scott


On Wed, Apr 23, 2025 at 5:57 PM Robert Goldman <[email protected]> wrote:

> Oh, yes, if you want to have your system, for example, invoke other
> programs, instead of just running a self-contained lisp program, then it
> gets much more complicated, very quickly.
>
> Is there any chance that roswell will do what you want? Before I used
> Docker, I used it to do some of my CI. But then at least for a while it was
> unmaintained, and I gave up. https://github.com/roswell/roswell
>
> Looking just now, I see that it has commits only 3 months ago, so it's not
> abandoned. On the other hand, it failed one of its last tests. Wonder if
> anyone's noticed and is looking to fix that. Also, the test incorporates a
> pretty old version of SBCL. Are they updating?
>
> On 23 Apr 2025, at 16:46, Scott E. Fahlman wrote:
>
> Sounds like an interesting research project to make this encapsulated
> system work smoothly with the facilities outside the VM.  Especially if you
> want to someday look at multithreading and things like that.  Sadly, not
> something I am likely to have time for.
>
> Thanks again,
> Scott
>
>
>
> On Wed, Apr 23, 2025 at 5:25 PM Robert Goldman <[email protected]> wrote:
>
>> It actually would not need updates for host operating system changes,
>> since it would be running a virtual machine. It would only need updates for
>> substantial changes to SLIME, Emacs, or SBCL. And, of course, that's
>> "substantial changes that we care about," not just any substantial changes.
>> Updates to Emacs, for example, could be ignored for years (basically until
>> you hit incompatible byte codes), and SBCL changes ignored until there's
>> some critical bug fix.
>>
>> The biggest issue, I believe, would be integrating the host machine
>> (where the source code lives) and the virtual machine. As I said, mounting
>> the lisp code into the VM would be straightforward and could be managed by
>> simply starting lisp with a script.
>>
>> The editor is more of a nuisance: either you have to have the editor run
>> in the container and display onto the host, or you have to have the editor
>> run on the host. The latter is easy to do, but requires the user to install
>> the editor, which is what you are trying to avoid.
>>
>>
>> On 23 Apr 2025, at 15:53, Scott E. Fahlman wrote:
>>
>> Hi Robert,
>>
>> Thanks.  This all-inclusive image might be the lowest-hassle delivery
>> vehicle for end users.  But it sounds like it would require a lot of work
>> to set up, and the result would be a brittle core image that has to be
>> rebuilt by someone every time there's an update in any component or in the
>> environment (a new MacOS version, for example) changes.  And it would be
>> inflexible, requiring a complete new build if someone needs a different set
>> of components or settings.  So that could be great if someone wants to do
>> that work and commit to maintaining that.  But finding that volunteer might
>> not be easy.
>>
>> Cheers,
>> Scott
>>
>>
>> On Wed, Apr 23, 2025 at 4:37 PM Robert Goldman <[email protected]>
>> wrote:
>>
>>> This might be the sort of thing that is best handled by making a docker
>>> image.
>>>
>>> One could make a docker image for SBCL that works on either AMD64 or
>>> ARM64, covering Windows and Mac. I have done this myself based on the
>>> images that used to be provided by the CL Foundation. See the images
>>> rpgoldman/sbcl:latest (I use these for testing CL systems).
>>>
>>> One could further build from this initial docker image a new one that
>>> contains also Emacs with SLIME (or SLY) pre-installed.
>>>
>>> That would be easier in some ways. It would still have a couple of
>>> problems:
>>>
>>>    1.
>>>
>>>    It would probably be a nuisance to run Emacs inside the container.
>>>    From outside the container, one could run Emacs with SLIME using the SBCL
>>>    inside the kernel. It might take some work to get this to work properly,
>>>    and then the user would still have to install emacs + slime.
>>>    2.
>>>
>>>    One would have to run the container with the user's directory of
>>>    Lisp code mounted into the docker. That could be automated by a shell
>>>    script (bat) file that would start up the container (and start a swank or
>>>    slynk server).
>>>    3.
>>>
>>>    Another subtlety: one would probably want to also mount the
>>>    quicklisp directory into the container, too, so that it wouldn't have to be
>>>    regenerated every time one started up the image.
>>>
>>> There would still be a fair amount of work getting this to work.
>>>
>>
>>

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help