Move from SBCL

[cottsay]

This issue issue more or less intends to collect thoughts about if SBCL is the right CLISP implementation for use in ROS.

The primary motivation behind bringing this up is the fact that SBCL is not currently available on ARM, which is becoming more and more useful (and supported) in ROS. This makes roslisp the only desktop-full package which will not install on ARM.

How reasonable would it be to begin migrating to a more widely-available CLSIP implementation such as GNU CLISP? Would it even be possible? How much work?

Looking for thoughts...

[bhaskara]

To my knowledge the two things that are sbcl-specific are the threading and sockets. Assuming there is a Common Lisp implementation on ARM that has those, migrating should just be a matter of changing those calls, which are hopefully reasonably localized in the code.

[moesenle]

I would like to stay with SBCL because its compiler is just really good. However, I think it might be possible to add an abstraction layer and support CLISP as well as SBCL. That's doable but might require some work.

[bchretien]

👍
I'm thinking about making roslisp optional in the metapackages on Arch Linux for that reason.
I currently remove roslisp from ros_comm for ARM architectures in Arch Linux's PKGBUILDs. AFAIK, this seems to be the only problem people encounter while building the "basic" metapackages for ROS.

[airballking]

Interesting question. I was not aware that SBCL prevents people from using ROS seamlessly for ARM. Thanks for bringing this to our attention!

My impression is that the roslisp-community is currently pretty small with few people providing bugs fixes/features. Hence, the know-how required to pull off a move away from SBCL or an abstraction of SBCL is in even less minds. Therefore, I'm afraid that even if such a refactoring is possible, it will not be feasible.

Question to @moesenle, @bhaskara and @dirk-thomas : Are there ways the roslisp-community could release roslisp with its current code-base without forcing a dependency on SBCL for ros_comm?

[moesenle]

I think roslisp doesn't really need to be part of roscomm. It's just important that roslisp messages are generated for all packages so genlisp needs to be in a central place.

[dirk-thomas]

roslisp is listed as a dependency in ros_comm in order to maintain compatibility with dry packages using lisp (https://github.com/ros/ros_comm/blob/indigo-devel/ros_comm/package.xml#L37). Otherwise all existing dry packages using lisp would need to add an additional dependency which is not realistic. Patching the package.xml for ARM and removing the dependency seems to be a reasonable (until there is an implementation which works on ARM).

[daewok]

👍
I actually think it wouldn't be too hard to shift away from requiring SBCL. There are portable libraries for the SBCL specific bits of the current code base. I have a fork that mostly works under Allegro (making binaries is the most iffy bit of it right now). I'm just starting to put ROS on my Raspberry Pi and was planning on making sure my fork works with Clozure CL as well.

If there's interest, I can clean up my fork (I was a little hasty when working on it and some things are a bit hacky) and submit a pull request for review that uses portable libraries.

[moesenle]

Wow. That sounds awesome. It would be great to have a look at your work. We should try to merge your work as soon as possible.

Which libraries are you using? Can we install them in Ubuntu or will we need a different mechanism for installing them.

[daewok]

Great! I'll start cleaning up a bit and see if I can get the executable creation working more smoothly.

As for libraries, I'm currently using:

• bordeaux-threads
• trivial-gray-streams
• trivial-timers
• usocket
• uiop

At least some of these appear to be in Ubuntu's package manager, but I was imagining that they'd be included in the repo just like s-xml and s-xml-rpc have been. This way if we need newer versions than are in aptitude (which I find very likely) we're not stuck waiting on that. The only issue I see is that the more packages bundled in with roslisp, the more likely it is that we'll bundle a package that a developer is using in their systems, potentially causing version mismatches. However, that should only be an issue if they're using an older version.

[bhaskara]

Incidentally, I noticed the latest SBCL 1.2.0 release has ARM support, in case you guys want to consider that as an option: http://www.sbcl.org/news.html

[cottsay]

Thanks for pointing that out, @bhaskara. It looks like Fedora is already working on bootstrapping SBCL for armv7hl [1]. The (previous) lack of ARM support was really the only reason I had a problem with SBCL, but it looks like that won't be a problem any longer.

I don't think it would be a bad idea to try to abstract roslisp to the point where other CL implementations could be used, but I certainly don't of the spare cycles to develop on this.

As far as I'm concerned, this PR can be closed. However, it might not be a bad idea to leave it open until sbcl has hit main repositories for at least Fedora and Ubuntu for arm.

[rohanbhargava11]

Any updates on this issue? I tried publishing to a topic using roslisp but I can't as sbcl doesn't support multi threading on ARM. I get this error
; Evaluation aborted on SIMPLE-ERROR "Not supported in unithread builds." {52F5ED39}

Is there a workaround?

[cottsay]

SBCL is now supported on ARM. It is in the Fedora main repos, but I'm not sure about Ubuntu.

[rohanbhargava11]

Yes SBCL is supported in ubuntu as well. The issue here is whether multi threading is supported or not? It looks like sbcl doesn't support multi threading on ARM. When I run the following command in sbcl running on arm
(member :sb-thread features) I get nil. That looks like to me that multi threading is not supported therefore I can't run roslisp on ARM

[airballking]

No news on this from us in Bremen. We neither have the resources to investigate moving away from SBCL nor do we use ARM ourselves.

[gaya-]

According to the following commit, on ARM64 there is multithreading support now:
sbcl/sbcl@53cbb34
Can't test it myself though.