How good is Haiku now?!?

Off-Topic
21

Almost the entirety of the Linux graphic stack is dual licensed GPLv2 / MIT though which is important to note making it 100% license compatible with Haiku… unfortunately the code on the other hand.

1 Like
22

Even if it could be leveraged to get something working on Haiku, which could then be forked and left to prosper on its own would be a good thing.

23

But by the time we get it working nicely, it will be out of date when compared with the Linux one and people will go all “why don’t you just use the code from Linux”?

1 Like
24

I was involved in communication, although not in implementation. The compilation of SBCL (and probably any other compiler) is done in several stages. First: bootstrap SBCL with some other Common Lisp implementation. Second: Compile SBCL with prepared bootstrap. The first stage is passed (x86-64, but other architectures should also work). The second stage fails. The relevant SBCL comment in src/runtime/gencgc.c is:

    /* There's a mysterious Solaris/x86 problem with using mmap
     * tricks for memory zeroing. See sbcl-devel thread
     * "Re: patch: standalone executable redux".
     */
    /* I have no idea what the issue with Haiku is, but using the simpler
     * zero_pages() works where the unmap,map technique does not. Yet the
     * trick plus a post-check that the pages were correctly zeroed finds
     * no problem at that time. So what's failing later and why??? */
#if defined LISP_FEATURE_SUNOS || defined LISP_FEATURE_HAIKU
    zero_pages(from, to);
#else

This code is responsible for generic garbage collection and thus for memory reclamation. Recently Haiku had changes in memory allocation. After each change I tried to recompile SBCL, which failed in the same place and the same error. Unfortunately, my knowledge is too limited to debug this kind of problems.

1 Like
25

Unfortunately I think I’m too much of a Haiku newbie to be able to do much, and we don’t have a Common Lisp on x86_64. I guess that would be stage 1 - getting ECL to run on 64 bit so that it can be used to bootstrap SBCL.

26

As said, the Common Lisp implementation that can be run on current Haiku is ABCL (https://abcl.org/), which runs on top of Java runtime. I use it to bootstrap SBCL.

2 Likes
27

How does that work? Doesn’t ABCL compile to Java bytecode?

28

To use ABCL, you need to install some JDK from Depot, say openjdk8. After that, download and unarchive abcl-bin-1.6.0.zip. This is just jar file. Next, in Terminal type:

java -jar abcl.jar

You can put this also in Slime configuration file ~/.slime with the following line:

(setq inferior-lisp-program "java -jar /path/to/abcl.jar")

And then you can use ABCL in Emacs by pressing M-X and typing slime.

29

Yeah, I can run ABCL no problem. I had to add a symlink to the jre binary to /boot/home/config/non-packaged/bin/ to get it on the path.

Even so, ABCL only gets so far during the bootstrapping process which suggests that there is some incompatability somewhere.

My issue stems from initially not really understanding what the bootstrapping process for SBCL is doing. I made a false assumption that what the first stage does is compile the basic lisp image, function by function and save it to disk. ABCL runs on the JVM and so it stands to reason that it would compile bytecode for the JVM and not x86 machine code.

After a brief conversation with the guys on ##lisp, they told me that the bootstrapping process isn’t quite what I thought. It’s not compiling the image functions with the lisp compiler itself but with the SBCL bootstrapper’s own inbuilt compiler.

Seems crazy to me, but until I go through the SBCL source I won’t know for sure.