clisp-devel

CLISP on Haiku

[Alexandru P. <al...@gm...>]

Hi,

I tried to build CLISP on Haiku operational system (
https://www.haiku-os.org/). It is not a Linux distribution, nor *BSD and is
unrelated to Windows. I want to say, compiling CLISP on Haiku at the first
attempt was easier than I expected.

1. After reading the *DEPENDENCIES* and *INSTALL* files, I installed
necessary dependencies except *libffcall*, which does not (yet) exist in
Haiku. Of course, I will try to get in also available. Haiku has
*libffi_devel*, but I am not sure if is a proper substitution. For now, I
used *--without-ffcall* configure option.

2. Because Haiku does not have multi-user support, the user has
administrative permissions. So, I issued:
*export FORCE_UNSAFE_CONFIGURE=1*
otherwise it complains about too many permissions.

3. During configuring, it was one crash (recover-able), so I just saved
report and continued. I will ask Haiku for help. The error was in program
*conftest* (during "*checking for working re_compile pattern... *" onscreen
message).

4. After configuration I inspected *src/config.lisp* file and made the
following changes:
Because *vi* editor is not available by default, I changed:
*(defparameter *editor* "vi" "The name of the editor.")*
to:
*(defparameter *editor* "nano" "The name of the editor.")*
This is for console editor. If the GUI editor can also be considered, the
"Haiku way" would be something like:
*(defparameter *editor* "/boot/system/apps/Pe/Pe" "The name of the
editor.")* ; Pe = Programmer's Editor for source code.
or:
*(defparameter *editor* "/boot/system/apps/StyledEdit" "The name of the
editor.")* ; Default text editor of Haiku.

After that, I added just after:
*;; (setq *browser* :firefox)*
the following:
*(setq *browser* "/boot/system/apps/WebPositive")* ; Firefox is not yet
ported to Haiku (the work is ongoing), and will probably not be official
one. WebPositive is The Haiku Web Browser.

5. Building was successful and I could find *clisp* executable in *src*
folder.
- *make* - OK
- *make check-tests* - 3 / 59 tests failed: *socket.erg*, *streams.erg* and
*streamslong.erg*, maybe because of missing *libffcall*.
- *make check-recompile* - OK
- *make install* - OK
- *make distrib* - OK

---------------------

On the first try, CLISP works with Terminal application under Haiku. It
fails to connect to *Slime* or *Sly* under *Emacs*, but this is probably
the issue with Slime / Sly.

Can you please guide me how can I contribute to making CLISP available on
Haiku? For now, is there some code I can modify to not being necessary to
manually change *config.lisp* after configuration?

Thank you,
Alexandru Popa

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Hi,

Alexandru Popa wrote:
> I installed
> necessary dependencies except *libffcall*, which does not (yet) exist in
> Haiku.

GNU libffcall 2.5 builds and works out-of-the-box on Haiku (both the x86
and the x86_64 versions).

> 2. Because Haiku does not have multi-user support, the user has
> administrative permissions. So, I issued:
> *export FORCE_UNSAFE_CONFIGURE=1*
> otherwise it complains about too many permissions.

Yes, this workaround is needed.

> 3. During configuring, it was one crash (recover-able), so I just saved
> report and continued. I will ask Haiku for help. The error was in program
> *conftest* (during "*checking for working re_compile pattern... *" onscreen
> message).

This configure test (whose source code is in gnulib/m4/regex.m4) tests
for known regex bugs in older glibcs. Since Haiku's libc descends from
glibc, it's likely to have some of these bugs.

> 4. After configuration I inspected *src/config.lisp* file and made the
> following changes:
> Because *vi* editor is not available by default, I changed:
> *(defparameter *editor* "vi" "The name of the editor.")*
> to:
> *(defparameter *editor* "nano" "The name of the editor.")*
> This is for console editor.

Ah, Haiku has a console editor actually! I didn't know :)

> If the GUI editor can also be considered, the
> "Haiku way" would be something like:
> *(defparameter *editor* "/boot/system/apps/Pe/Pe" "The name of the
> editor.")* ; Pe = Programmer's Editor for source code.
> or:
> *(defparameter *editor* "/boot/system/apps/StyledEdit" "The name of the
> editor.")* ; Default text editor of Haiku.

I would vote for Pe. If you are in Haiku land, do the Haiku way.

> After that, I added just after:
> *;; (setq *browser* :firefox)*
> the following:
> *(setq *browser* "/boot/system/apps/WebPositive")* ; Firefox is not yet
> ported to Haiku (the work is ongoing), and will probably not be official
> one. WebPositive is The Haiku Web Browser.

OK.

> 5. Building was successful and I could find *clisp* executable in *src*
> folder.
> - *make* - OK
> - *make check-tests* - 3 / 59 tests failed: *socket.erg*, *streams.erg* and
> *streamslong.erg*, maybe because of missing *libffcall*.
> - *make check-recompile* - OK
> - *make install* - OK
> - *make distrib* - OK

Nice!

> On the first try, CLISP works with Terminal application under Haiku. It
> fails to connect to *Slime* or *Sly* under *Emacs*, but this is probably
> the issue with Slime / Sly.

Sockets have been a known problem with BeOS. It is possible that for these
historical reason, they are still problematic with Haiku. I haven't looked
in detail.

> Can you please guide me how can I contribute to making CLISP available on
> Haiku?
> For now, is there some code I can modify to not being necessary to
> manually change *config.lisp* after configuration?

Step 1 is to provide source-code patches. You could provide your config.lisp,
for inclusion in the CLISP source code as cfghaiku.lisp. One could then make
it automatic, via a makemake.in rule.

Then, it depends what "make available on Haiku" means. Does it have a
package system, like so many other OSes do? If yes, then you could submit
libffcall and then CLISP there. Be sure to pick libffcall version 2.5
and CLISP git (https://gitlab.com/gnu-clisp/clisp) master branch.

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Thank you Bruno for your response.

Haiku has a package manager, unlike BeOS. The available packages can be
searched via web interface at https://depot.haiku-os.org/. The *ffcall*
package was just added to Haiku repository for the sake of CLIPS, but is is
available also for other purposes of course. The recipe for CLISP is being
prepared these days. The discussion about it is ongoing at
https://discuss.haiku-os.org/t/make-ansi-common-lisp-available-on-haiku-again/15780
.

I prepared *cfghaiku.lisp*. Unfortunately, I did not succeed in
modifying *makefile.in
<http://makefile.in>* to reflect Haiku specific handling. These days I try
to extensively test CLISP on Haiku. I found *tests* and *sacla-tests*
folders in master tarball from Git. However, I did not find a folder for
ANSI compliance testing as per "*make check-ansi-tests*". Where can I find
them?

Additionally, what can you suggest for debugging sockets? Is there
something OS specific in SLIME / SLY to support Haiku (never looked at
their code)?

Thank you again for your time and detailed information,
Alexandru

ср, 23 окт. 2024 г. в 17:40, Bruno Haible <br...@cl...>:

> Hi,
>
> Alexandru Popa wrote:
> > I installed
> > necessary dependencies except *libffcall*, which does not (yet) exist in
> > Haiku.
>
> GNU libffcall 2.5 builds and works out-of-the-box on Haiku (both the x86
> and the x86_64 versions).
>
> > 2. Because Haiku does not have multi-user support, the user has
> > administrative permissions. So, I issued:
> > *export FORCE_UNSAFE_CONFIGURE=1*
> > otherwise it complains about too many permissions.
>
> Yes, this workaround is needed.
>
> > 3. During configuring, it was one crash (recover-able), so I just saved
> > report and continued. I will ask Haiku for help. The error was in program
> > *conftest* (during "*checking for working re_compile pattern... *"
> onscreen
> > message).
>
> This configure test (whose source code is in gnulib/m4/regex.m4) tests
> for known regex bugs in older glibcs. Since Haiku's libc descends from
> glibc, it's likely to have some of these bugs.
>
> > 4. After configuration I inspected *src/config.lisp* file and made the
> > following changes:
> > Because *vi* editor is not available by default, I changed:
> > *(defparameter *editor* "vi" "The name of the editor.")*
> > to:
> > *(defparameter *editor* "nano" "The name of the editor.")*
> > This is for console editor.
>
> Ah, Haiku has a console editor actually! I didn't know :)
>
> > If the GUI editor can also be considered, the
> > "Haiku way" would be something like:
> > *(defparameter *editor* "/boot/system/apps/Pe/Pe" "The name of the
> > editor.")* ; Pe = Programmer's Editor for source code.
> > or:
> > *(defparameter *editor* "/boot/system/apps/StyledEdit" "The name of the
> > editor.")* ; Default text editor of Haiku.
>
> I would vote for Pe. If you are in Haiku land, do the Haiku way.
>
> > After that, I added just after:
> > *;; (setq *browser* :firefox)*
> > the following:
> > *(setq *browser* "/boot/system/apps/WebPositive")* ; Firefox is not yet
> > ported to Haiku (the work is ongoing), and will probably not be official
> > one. WebPositive is The Haiku Web Browser.
>
> OK.
>
> > 5. Building was successful and I could find *clisp* executable in *src*
> > folder.
> > - *make* - OK
> > - *make check-tests* - 3 / 59 tests failed: *socket.erg*, *streams.erg*
> and
> > *streamslong.erg*, maybe because of missing *libffcall*.
> > - *make check-recompile* - OK
> > - *make install* - OK
> > - *make distrib* - OK
>
> Nice!
>
> > On the first try, CLISP works with Terminal application under Haiku. It
> > fails to connect to *Slime* or *Sly* under *Emacs*, but this is probably
> > the issue with Slime / Sly.
>
> Sockets have been a known problem with BeOS. It is possible that for these
> historical reason, they are still problematic with Haiku. I haven't looked
> in detail.
>
> > Can you please guide me how can I contribute to making CLISP available on
> > Haiku?
> > For now, is there some code I can modify to not being necessary to
> > manually change *config.lisp* after configuration?
>
> Step 1 is to provide source-code patches. You could provide your
> config.lisp,
> for inclusion in the CLISP source code as cfghaiku.lisp. One could then
> make
> it automatic, via a makemake.in rule.
>
> Then, it depends what "make available on Haiku" means. Does it have a
> package system, like so many other OSes do? If yes, then you could submit
> libffcall and then CLISP there. Be sure to pick libffcall version 2.5
> and CLISP git (https://gitlab.com/gnu-clisp/clisp) master branch.
>
> Bruno
>
>
>
>

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

On Donnerstag, 24. Oktober 2024 09:44:42 CEST Alexandru Popa wrote:
> Thank you Bruno for your response.
> 
> Haiku has a package manager, unlike BeOS. The available packages can be
> searched via web interface at https://depot.haiku-os.org/. The *ffcall*
> package was just added to Haiku repository for the sake of CLIPS, but is is
> available also for other purposes of course. The recipe for CLISP is being
> prepared these days.

I see; nice:
https://github.com/haikuports/haikuports/tree/master/dev-libs/ffcall
https://github.com/haikuports/haikuports/tree/master/dev-libs/libsigsegv

> I prepared *cfghaiku.lisp*. Unfortunately, I did not succeed in
> modifying *makefile.in

Thanks. I can handle the makemake.in part.

> <http://makefile.in>* to reflect Haiku specific handling. These days I try
> to extensively test CLISP on Haiku. I found *tests* and *sacla-tests*
> folders in master tarball from Git. However, I did not find a folder for
> ANSI compliance testing as per "*make check-ansi-tests*". Where can I find
> them?

You get them through
  $ make -f Makefile.devel update-ansi-tests

> Additionally, what can you suggest for debugging sockets?

I don't know: Which of these tools, that are familiar on Linux, are ported to
Haiku?
  - netstat
  - ss
  - lsof
  - netcat

> Is there
> something OS specific in SLIME / SLY to support Haiku (never looked at
> their code)?

I don't know. I haven't looked in their code either.

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Also, I see clisp-2.50 branch in Git repository. Is CLISP 2-50 already
released or is it prepared to be released in the future? I suppose Haiku
specific code will enter in master branch, and from this branch Haiku will
prepare the package. But the version will still be clisp-2.49, right?

чт, 24 окт. 2024 г. в 10:44, Alexandru Popa <al...@gm...>:

> Thank you Bruno for your response.
>
> Haiku has a package manager, unlike BeOS. The available packages can be
> searched via web interface at https://depot.haiku-os.org/. The *ffcall*
> package was just added to Haiku repository for the sake of CLIPS, but is is
> available also for other purposes of course. The recipe for CLISP is being
> prepared these days. The discussion about it is ongoing at
> https://discuss.haiku-os.org/t/make-ansi-common-lisp-available-on-haiku-again/15780
> .
>
> I prepared *cfghaiku.lisp*. Unfortunately, I did not succeed in modifying *makefile.in
> <http://makefile.in>* to reflect Haiku specific handling. These days I
> try to extensively test CLISP on Haiku. I found *tests* and *sacla-tests*
> folders in master tarball from Git. However, I did not find a folder for
> ANSI compliance testing as per "*make check-ansi-tests*". Where can I
> find them?
>
> Additionally, what can you suggest for debugging sockets? Is there
> something OS specific in SLIME / SLY to support Haiku (never looked at
> their code)?
>
> Thank you again for your time and detailed information,
> Alexandru
>
> ср, 23 окт. 2024 г. в 17:40, Bruno Haible <br...@cl...>:
>
>> Hi,
>>
>> Alexandru Popa wrote:
>> > I installed
>> > necessary dependencies except *libffcall*, which does not (yet) exist in
>> > Haiku.
>>
>> GNU libffcall 2.5 builds and works out-of-the-box on Haiku (both the x86
>> and the x86_64 versions).
>>
>> > 2. Because Haiku does not have multi-user support, the user has
>> > administrative permissions. So, I issued:
>> > *export FORCE_UNSAFE_CONFIGURE=1*
>> > otherwise it complains about too many permissions.
>>
>> Yes, this workaround is needed.
>>
>> > 3. During configuring, it was one crash (recover-able), so I just saved
>> > report and continued. I will ask Haiku for help. The error was in
>> program
>> > *conftest* (during "*checking for working re_compile pattern... *"
>> onscreen
>> > message).
>>
>> This configure test (whose source code is in gnulib/m4/regex.m4) tests
>> for known regex bugs in older glibcs. Since Haiku's libc descends from
>> glibc, it's likely to have some of these bugs.
>>
>> > 4. After configuration I inspected *src/config.lisp* file and made the
>> > following changes:
>> > Because *vi* editor is not available by default, I changed:
>> > *(defparameter *editor* "vi" "The name of the editor.")*
>> > to:
>> > *(defparameter *editor* "nano" "The name of the editor.")*
>> > This is for console editor.
>>
>> Ah, Haiku has a console editor actually! I didn't know :)
>>
>> > If the GUI editor can also be considered, the
>> > "Haiku way" would be something like:
>> > *(defparameter *editor* "/boot/system/apps/Pe/Pe" "The name of the
>> > editor.")* ; Pe = Programmer's Editor for source code.
>> > or:
>> > *(defparameter *editor* "/boot/system/apps/StyledEdit" "The name of the
>> > editor.")* ; Default text editor of Haiku.
>>
>> I would vote for Pe. If you are in Haiku land, do the Haiku way.
>>
>> > After that, I added just after:
>> > *;; (setq *browser* :firefox)*
>> > the following:
>> > *(setq *browser* "/boot/system/apps/WebPositive")* ; Firefox is not yet
>> > ported to Haiku (the work is ongoing), and will probably not be official
>> > one. WebPositive is The Haiku Web Browser.
>>
>> OK.
>>
>> > 5. Building was successful and I could find *clisp* executable in *src*
>> > folder.
>> > - *make* - OK
>> > - *make check-tests* - 3 / 59 tests failed: *socket.erg*, *streams.erg*
>> and
>> > *streamslong.erg*, maybe because of missing *libffcall*.
>> > - *make check-recompile* - OK
>> > - *make install* - OK
>> > - *make distrib* - OK
>>
>> Nice!
>>
>> > On the first try, CLISP works with Terminal application under Haiku. It
>> > fails to connect to *Slime* or *Sly* under *Emacs*, but this is probably
>> > the issue with Slime / Sly.
>>
>> Sockets have been a known problem with BeOS. It is possible that for these
>> historical reason, they are still problematic with Haiku. I haven't looked
>> in detail.
>>
>> > Can you please guide me how can I contribute to making CLISP available
>> on
>> > Haiku?
>> > For now, is there some code I can modify to not being necessary to
>> > manually change *config.lisp* after configuration?
>>
>> Step 1 is to provide source-code patches. You could provide your
>> config.lisp,
>> for inclusion in the CLISP source code as cfghaiku.lisp. One could then
>> make
>> it automatic, via a makemake.in rule.
>>
>> Then, it depends what "make available on Haiku" means. Does it have a
>> package system, like so many other OSes do? If yes, then you could submit
>> libffcall and then CLISP there. Be sure to pick libffcall version 2.5
>> and CLISP git (https://gitlab.com/gnu-clisp/clisp) master branch.
>>
>> Bruno
>>
>>
>>
>>

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa asked:
> Also, I see clisp-2.50 branch in Git repository. Is CLISP 2-50 already
> released or is it prepared to be released in the future?

The clisp-2.50 branch was meant to give rise to a 2.50 release, but is
obsolete by now. The next release will be cut from the master branch, and
will be called 2.51.

> I suppose Haiku
> specific code will enter in master branch, and from this branch Haiku will
> prepare the package.

Right.

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Thank you. Plain CLISP is more or less working in Haiku x86-64 and x86.
Will test ANSI compliance tests. Also I take a look at modules which would
go inside the package (probably those suggested in unix/INSTALL: i18n,
regexp, syscalls, readline as well as asdf and rawsock).

>> Additionally, what can you suggest for debugging sockets?
> I don't know: Which of these tools, that are familiar on Linux, are
ported to
> Haiku?
>   - netstat
>   - ss
>   - lsof
>   - netcat

I see netcat (
https://depot.haiku-os.org/#!/pkg/netcat/haikuports/haikuports_x86_64/1/10/-/-/4/x86_64?bcguid=bc2-XCBK)
and psutil_python310 (
https://depot.haiku-os.org/#!/pkg/psutil_python310/haikuports/haikuports_x86_64/6/0/0/-/1/x86_64?bcguid=bc2-RAHS)
are available. I necer used them, but I am sure somebody can help using
them.

пт, 25 окт. 2024 г. в 00:49, Bruno Haible <br...@cl...>:

> Alexandru Popa asked:
> > Also, I see clisp-2.50 branch in Git repository. Is CLISP 2-50 already
> > released or is it prepared to be released in the future?
>
> The clisp-2.50 branch was meant to give rise to a 2.50 release, but is
> obsolete by now. The next release will be cut from the master branch, and
> will be called 2.51.
>
> > I suppose Haiku
> > specific code will enter in master branch, and from this branch Haiku
> will
> > prepare the package.
>
> Right.
>
> Bruno
>
>
>
>

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

CLISP package is available in Haiku (x86-64, x86):
https://depot.haiku-os.org/#!/pkg/clisp/haikuports/haikuports_x86_64/2/49/93/git/1/x86_64?bcguid=bc175-TJHY
https://depot.haiku-os.org/#!/pkg/clisp_x86/haikuports/haikuports_x86_gcc2/2/49/93/git/1/x86_gcc2?bcguid=bc2-UVML

I see some activity in CLISP for Haiku in mailing lists, but do not see
anything in GitLab. Am I missing something, or am I just too impatient?

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Hi,

> I see some activity in CLISP for Haiku in mailing lists, but do not see
> anything in GitLab. Am I missing something, or am I just too impatient?

You were too impatient :)

Meanwhile, I have
  - Tuned the memory management configuration for Haiku.
    On x86_64 it's possible to use mmap instead of malloc.
    But on this platform, I turned off generational GC by default,
    since here it provides a 20% slowdown instead of a speedup.
  - Added workarounds for Haiku-specific test failures
    (streams.erg, streamslong.erg).
  - Added and fixed your Haiku-specific user configuration.
    Tested by running  (edit-file "~/foo.c")  and  (clhs 'setf):
    The edit-file function was not returning immediately. And the
    clhs function complained that the value of *browser* was of
    the wrong type.

There are still test failures relating to sockets, but other platforms
have that too. Not sure if these failures have important effects.

Alexandru Popa wrote:
> CLISP package is available in Haiku (x86-64, x86):
> https://depot.haiku-os.org/#!/pkg/clisp/haikuports/haikuports_x86_64/2/49/93/git/1/x86_64?bcguid=bc175-TJHY
> https://depot.haiku-os.org/#!/pkg/clisp_x86/haikuports/haikuports_x86_gcc2/2/49/93/git/1/x86_gcc2?bcguid=bc2-UVML

Did you test these binaries? I installed the x86_64 one, and

1) When I start /bin/clisp, there is an error
  runtime_loader: Cannot open file libsigsegv.so.2 (needed by /boot/system/lib/clisp-2.49.93+/base/lisp.run): No such file or directory

So I install package 'libsigsegv'.

2) When I start /bin/clisp, there is an error
  runtime_loader: Cannot open file libunistring.so.5 (needed by /boot/system/lib/clisp-2.49.93+/base/lisp.run): No such file or directory

So I uninstall package 'libunistring' and reinstall the packages
'libunistring' and 'libunistring2'.

It seems that the binary package is missing at least these two dependencies.
The dependencies to readline and ffcall seem to be working, on the other hand.

Now it's worth making new packages, I would say.

Bruno

Re: CLISP on Windows

[Bruno H. <br...@cl...>]

Hi Wolfgang,

Please keep the mailing list in CC.

Wolfgang Dautermann wrote:
> I am looking forward to a new release. People (including me) are using 
> 2.49, which is 14 years old, as that was the last release.
> 
> And Clisp *is* under active development (thanks!!), so the current code 
> is probably much better than the version from 2010.
> 
> [Since 2015 I create Windows installers for the Computeralgebrasystem 
> Maxima by crosscompiling it from Linux to Windows, and Clisp was the 
> first Lisp compiler, which allowed me to do this (running Clisp using 
> 'wine' on Linux).
> But for that task I still use 2.49 from sourceforge, as this is the 
> latest Windows version. (Other Lisp compilers are supported now in my 
> Maxima Windows installer, but of course Clisp (2.49) is still used there).]

For Maxima, the version 2.49 should be entirely sufficient (on platforms
that were supported back then).

> How does one create a Windows installer? You recommend using Cygwin as 
> development environment, I tried to set up that on Github actions, but 
> it stops during the compiliation:
> 
> ./lisp.exe -marc > marc.out
> Cannot reserve address range 0x3000000-0x300ffff .
> [../src/spvw_mmap.d:342] GetLastError() = 0x1e7: Attempt to access 
> invalid address.
> 
> See
> https://github.com/daute/clisp-crossbuild/
> and
> https://github.com/daute/clisp-crossbuild/actions/runs/11520137588/job/32070748276

The situation of the Windows port is currently a mess, because it is focused
on the MSVC compiler (whereas mingw-w64 is now generally the better approach)
on old versions of that compiler, on nmake rather than GNU make, with way too
much code for cross-compiling.

This will take a while to clean up. And the NSIS-based installer for Windows
is also out-of-date; maybe people can just unpack a zip instead?

Bruno

Re: CLISP on Windows

[Wolfgang D. <wol...@da...>]

Am 03.11.24 um 15:31 schrieb Bruno Haible:
> Hi Wolfgang,
> 
> Please keep the mailing list in CC.

Hi Bruno,
yes, sorry.

> For Maxima, the version 2.49 should be entirely sufficient (on
> platforms that were supported back then).

Yes, it works without problems. 'Crosscompiling' Lisp programs seems to 
be a crazy idea (I did know nearly nothing about Lisp back then), and I 
tried various Lisp's - and Clisp was the first one, that worked.

Now other Lisp's are supported too in my installer, but of course Clisp
is used too.

> The situation of the Windows port is currently a mess, because it is
> focused on the MSVC compiler (whereas mingw-w64 is now generally the
> better approach) on old versions of that compiler, on nmake rather
> than GNU make, with way too much code for cross-compiling.
> 
> This will take a while to clean up.

Thanks in advance.

> And the NSIS-based installer for Windows is also out-of-date; maybe
> people can just unpack a zip instead?

I use the zip file clisp-2.49-win32-mingw-big.zip from
https://sourceforge.net/projects/clisp/files/clisp/2.49/ - so, of
course, a zip file is great, an installer is not needed. Most people 
should be able to extract zip files, especially developers...

For my 'crosscompiliation-procedure' I extract also (NSIS and
MSI-)installers like an archive (using 7z).

Best regards, Wolfgang

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Hi,

Meanwhile, I have
>   - Tuned the memory management configuration for Haiku.
>     On x86_64 it's possible to use mmap instead of malloc.
>     But on this platform, I turned off generational GC by default,
>     since here it provides a 20% slowdown instead of a speedup.
>   - Added workarounds for Haiku-specific test failures
>     (streams.erg, streamslong.erg).
>   - Added and fixed your Haiku-specific user configuration.
>     Tested by running  (edit-file "~/foo.c")  and  (clhs 'setf):
>     The edit-file function was not returning immediately. And the
>     clhs function complained that the value of *browser* was of
>     the wrong type.
>


Thank you Bruno.


> There are still test failures relating to sockets, but other platforms
> have that too. Not sure if these failures have important effects.
>
>
The Haiku thread about CLISP has some input from Haiku developers (
https://discuss.haiku-os.org/t/make-ansi-common-lisp-available-on-haiku-again/15780/87):
"the only thing to know is you need to link to libnetwork. Other than that,
it should be identical to other unix systems, and if you have any beos
specific code, you should remove it." (PulkoMandy
<https://discuss.haiku-os.org/u/PulkoMandy>), "It’s already linked with
libnetwork (and libbsd), so leaves the old BeOS code to be updated then I
presume." (Begasus <https://discuss.haiku-os.org/u/Begasus>)


> Did you test these binaries? I installed the x86_64 one, and
>
> 1) When I start /bin/clisp, there is an error
>   runtime_loader: Cannot open file libsigsegv.so.2 (needed by
> /boot/system/lib/clisp-2.49.93+/base/lisp.run): No such file or directory
>
> So I install package 'libsigsegv'.
>
> 2) When I start /bin/clisp, there is an error
>   runtime_loader: Cannot open file libunistring.so.5 (needed by
> /boot/system/lib/clisp-2.49.93+/base/lisp.run): No such file or directory
>
> So I uninstall package 'libunistring' and reinstall the packages
> 'libunistring' and 'libunistring2'.
>
> It seems that the binary package is missing at least these two
> dependencies.
> The dependencies to readline and ffcall seem to be working, on the other
> hand.
>
> Now it's worth making new packages, I would say.
>

Sorry, my fail. This is my very first Haiku recipe (and first software port
ever). During building I installed corresponding _devel packages, which
also installed these ones. And then did not check the runtime dependencies.
Of course they should be specified in the recipe. I will update the recipe
ASAP.

I also have some observations:
1. **features** lists *:UNIX* and *:OS-UNIX*, but does not list *:HAIKU* /
*:OS-HAIKU*. The former may be OK in sense Haiku to some extent can be
considered Unix-like. But it is sufficiently different from Unix to specify
*:HAIKU* and / or *:OS-HAIKU*, so 3rd-party packages can make OS-specific
decisions. Maybe this can be done via *cfghaiku.lisp*? I did not find any
reference to **features** in *cfgunix.lisp*.
2. I see CLISP on Haiku does not support threading? I know, I am too
impatient, but I believe once it will be added. Because CLISP is a CLI
application, I do not expect it to be any different from Linux threads.

I managed to compile the following CLISP modules (not tried them except
asdf):
- *asdf*,
- *berkeley-db*,
- *clx/mit-clx* (I doubt this one is actually useful in Haiku),
- *editor*,
- *gdbm*,
- *libsvm*,
- *pcre*,
- *postgresql*,
- *queens*,
- *rawsock*,
- *zlib*.
One more package, *pari* is almost buildable. It depends on *pari.desc*
file containing information about pari functions, but this file is not more
delivered with pari. On the one hand, it can be re-created relatively
simple (and maybe pari source contain some script about it), but on the
other hand, pari CLISP package may be altered to read *src/functions*
folder instead.

Alexandru

Fwd: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Sorry, also to mailing list.

Hi Bruno,

I see more GitLab activity related to Haiku. Thank you.

I submitted a new pull request at Haiku for updated CLISP recipe (2.49.95),
which includes also modules: *asdf*, *rawsock*, *clx/mit-clx*, *editor*,
*queens*, *berkeley-db*, *gdbm*, *libsvm*, *pcre*, *postgresql*, *zlib*.
Module *pari* will probably follow soon, but first I need to play with
recipe for pari 3rd party library. Pull request is
https://github.com/haikuports/haikuports/pull/11327. Hopefully the new
packages will be available soon.

When I configure CLISP on Haiku, I see config.lisp contains the last line
duplicated:
(setq *clhs-root-default* "
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/")

This is because I prepared *cfghaiku.lisp* starting from *config.lisp*, not
from *cfgunix.lisp*. And after renaming, the last line is dynamically added
to *config.lisp*. So, I suppose, the last line should be removed from
*cfghaiku.lisp* to not get a duplicated one.

Re: Fwd: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa wrote:
> When I configure CLISP on Haiku, I see config.lisp contains the last line
> duplicated:
> (setq *clhs-root-default* "
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/")
> 
> This is because I prepared *cfghaiku.lisp* starting from *config.lisp*, not
> from *cfgunix.lisp*. And after renaming, the last line is dynamically added
> to *config.lisp*. So, I suppose, the last line should be removed from
> *cfghaiku.lisp* to not get a duplicated one.

Ah, right. Done.

Bruno

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa wrote on 2024-11-04:
> 1. **features** lists *:UNIX* and *:OS-UNIX*, but does not list *:HAIKU* /
> *:OS-HAIKU*.

In my builds, the last element of *features* is :HAIKU.
How come that it's not the same in your builds?
It comes from spvw.d line 1993.

> 2. I see CLISP on Haiku does not support threading?

CLISP does not support threading. There is a configure option to enable it,
but it's experimental and the resulting builds are not reliable.

> I managed to compile the following CLISP modules (not tried them except
> asdf):
> - *asdf*,
> - *berkeley-db*,
> - *clx/mit-clx* (I doubt this one is actually useful in Haiku),
Yes, this module is useless without an X11 server to connect to.

> - *editor*,
> - *gdbm*,
> - *libsvm*,
> - *pcre*,
> - *postgresql*,
> - *queens*,
> - *rawsock*,
> - *zlib*.

> One more package, *pari* is almost buildable. It depends on *pari.desc*
> file containing information about pari functions, but this file is not more
> delivered with pari.

Not worth bothering. The people in the field use SAGE nowadays when they want
to integrate different computer-algebra systems.

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Hi Bruno,

ср, 13 нояб. 2024 г. в 21:55, Bruno Haible <br...@cl...>:

> Alexandru Popa wrote on 2024-11-04:
> > 1. **features** lists *:UNIX* and *:OS-UNIX*, but does not list *:HAIKU*
> /
> > *:OS-HAIKU*.
>
> In my builds, the last element of *features* is :HAIKU.
> How come that it's not the same in your builds?
> It comes from spvw.d line 1993


I can see in src/spvw.d, lines 1980-1982, 1992-1994 the following:
#ifdef UNIX
  " :UNIX"
#endif
...
#ifdef UNIX_HAIKU
  " :HAIKU"
#endif

Still in my build of CLISP *features* list :UNIX (last) but not :HAIKU.
Where the definition "#ifdef UNIX_HAIKU" comes from? AFAIK, the standard
Haiku macro is "#ifdef __HAIKU__".

Alexandru.

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa wrote:
> Still in my build of CLISP *features* list :UNIX (last) but not :HAIKU.
> Where the definition "#ifdef UNIX_HAIKU" comes from?

It comes from lispbibl.d:315.

> AFAIK, the standard Haiku macro is "#ifdef __HAIKU__".

What's the result of these commands on your machine?
$ : | gcc -E -dM - | grep -i haiku
$ gcc -v

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

чт, 14 нояб. 2024 г. в 15:10, Bruno Haible <br...@cl...>:

> Alexandru Popa wrote:
> > Still in my build of CLISP *features* list :UNIX (last) but not :HAIKU.
> > Where the definition "#ifdef UNIX_HAIKU" comes from?
>
> It comes from lispbibl.d:315.
>
> > AFAIK, the standard Haiku macro is "#ifdef __HAIKU__".
>
> What's the result of these commands on your machine?
> $ : | gcc -E -dM - | grep -i haiku
> $ gcc -v
>

When I run:
*$ : | gcc -E -dM - | grep -i haiku*
I get:
*#define __HAIKU__ 1*

The command:
*gcc -v*
shows (among other):
*Target: x86_64-unknown-haiku*
*gcc version 13.3.0 (2023_08_10)*

Regarding *lispbibl.d*, I see the origin of *UNIX_HAIKU*.

But even when I modify *spvw.d* from:

*#ifdef UNIX_HAIKU*
*  " :HAIKU"*
*#endif*

to:

*#ifdef __HAIKU__*
*  " :HAIKU"*
*#endif*

I still do not have :HAIKU in **features**. Maybe I do something wrong?

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa wrote:
> When I run:
> *$ : | gcc -E -dM - | grep -i haiku*
> I get:
> *#define __HAIKU__ 1*

That's what we expect.

> But even when I modify *spvw.d* from:
> 
> *#ifdef UNIX_HAIKU*
> *  " :HAIKU"*
> *#endif*
> 
> to:
> 
> *#ifdef __HAIKU__*
> *  " :HAIKU"*
> *#endif*
> 
> I still do not have :HAIKU in **features**. Maybe I do something wrong?

When you run './lisp.run' without any -M option, does *features* then contain
:HAIKU?
  - If no, then concentrate the search on the C compiler.
  - If yes, then it means that this part of *features* got lost in the .mem
    files. Which is the first .mem file that has it lost?

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Hi Bruno,

Sorry for late response, just got access to my Haiku box. Problem solved.

*./lisp.run -M ../halfcompiled.mem*
*./lisp.run -M ../interpretet.mem*
*./lisp.run -M lispinit.mem*
All these have in **features**:




*[1]> *features* (:QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.2 :ASDF3.1 :ASDF3
:ASDF2 :ASDF :OS-UNIX :ASDF-UNICODE :LOOP :COMPILER :CLOS :MOP :CLISP
:ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
:GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
:WORD-SIZE=64 :UNIX)*

*./lisp.run -B .*
has in **features**:

*[1]> *features* (:CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER
:LOGICAL-PATHNAMES :SOCKETS*
* :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER*
* :WORD-SIZE=64 :UNIX :HAIKU)*

Evidently, there is a difference with *-M* and without this option. It is
important to mention that with *-M* option the following files are also
loaded: *~/.clisprc.lisp*, *~/quicklisp/setup.lisp* and
*~/quicklisp/asdf.lisp*. These were setup with earlier attempt to build
CLISP. If I rename these files to not be loaded, I have yet another version
of **features**:

*[1]> *features* (:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP
:COMPILER :CLOS :MOP :CLISP*
* :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS*
* :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER*
* :WORD-SIZE=64 :UNIX :HAIKU)*
So far so good!

So, I deleted all QuickLisp related stuff together with *~/.clisprc.lisp*
and re-installed QuickLisp. As soon as I installed it, *:HAiKU* (only this
feature) disappears again:

*[1]> *features* (*
*:QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF
:OS-UNIX :ASDF-UNICODE **:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP
:COMPILER*
* :CLOS :MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER*
* :LOGICAL-PATHNAMES :SOCKETS :GENERIC-STREAMS :SCREEN :FFI :GETTEXT
:UNICODE*
* :BASE-CHAR=CHARACTER :WORD-SIZE=64 :UNIX)*

So QuickLisp is the guilty party. I will debug it further. It is not fail
of CLISP.

Thank you for your help,
Alexandru


пн, 18 нояб. 2024 г. в 10:50, Bruno Haible <br...@cl...>:

> Alexandru Popa wrote:
> > When I run:
> > *$ : | gcc -E -dM - | grep -i haiku*
> > I get:
> > *#define __HAIKU__ 1*
>
> That's what we expect.
>
> > But even when I modify *spvw.d* from:
> >
> > *#ifdef UNIX_HAIKU*
> > *  " :HAIKU"*
> > *#endif*
> >
> > to:
> >
> > *#ifdef __HAIKU__*
> > *  " :HAIKU"*
> > *#endif*
> >
> > I still do not have :HAIKU in **features**. Maybe I do something wrong?
>
> When you run './lisp.run' without any -M option, does *features* then
> contain
> :HAIKU?
>   - If no, then concentrate the search on the C compiler.
>   - If yes, then it means that this part of *features* got lost in the .mem
>     files. Which is the first .mem file that has it lost?
>
> Bruno
>
>
>
>

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

Alexandru Popa wrote:
> So QuickLisp is the guilty party. I will debug it further. It is not fail
> of CLISP.

In the quicklisp-client, searching for side-effects to *features* leads me to:

$ grep -rni 'set.* [*]features[*]' .
./asdf.lisp:1908:           :do (setf o feature) (pushnew feature *features*)
./asdf.lisp:1909:           :else :do (setf *features* (remove feature *features*))

asdf.lisp contains this code:

  (defun detect-os ()
    "Detects the current operating system. Only needs be run at compile-time,
except on ABCL where it might change between FASL compilation and runtime."
    (loop* :with o
           :for (feature . detect) :in '((:os-unix . os-unix-p) (:os-macosx . os-macosx-p)
                                         (:os-windows . os-windows-p)
                                         (:genera . os-genera-p) (:os-oldmac . os-oldmac-p)
                                         (:haiku . os-haiku-p))
           :when (and (or (not o) (eq feature :os-macosx)) (funcall detect))
           :do (setf o feature) (pushnew feature *features*)
           :else :do (setf *features* (remove feature *features*))
           :finally
           (return (or o (error "Congratulations for trying ASDF on an operating system~%~
that is neither Unix, nor Windows, nor Genera, nor even old MacOS.~%Now you port it.")))))

What is this code meant to do??

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

>
> In the quicklisp-client, searching for side-effects to *features* leads me
> to:
>
> $ grep -rni 'set.* [*]features[*]' .
> ./asdf.lisp:1908:           :do (setf o feature) (pushnew feature
> *features*)
> ./asdf.lisp:1909:           :else :do (setf *features* (remove feature
> *features*))
>
> asdf.lisp contains this code:
>
>   (defun detect-os ()
>

Thank you for a hint.


>            (return (or o (error "Congratulations for trying ASDF on an
> operating system~%~
> that is neither Unix, nor Windows, nor Genera, nor even old MacOS.~%Now
> you port it.")))))
>
What is this code meant to do??


This message seems to indicate that ASDF is run at  completely new OS, and
you as ASDF user face the situation to port it to a new OS. I do not
remember to see such error, but maybe it is a good idea to ask ASDF team
for assistance.

Re: CLISP on Haiku

[Bruno H. <br...@cl...>]

> Indeed, please take this to the Quicklisp or ASDF maintainers.

Yes, please take this to the ASDF maintainers. My take on it is:
  - It is OK for ASDF to add symbols to *features*, as long as they
    don't collide with already-established symbols from other
    implementations and packages.
  - But removing symbols from *features* is a no-no.

Bruno

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

Thank you for analysis. I contacted ASDF (
https://gitlab.common-lisp.net/asdf/asdf/) using their mailing list
asdf-devel and reported the problem.

The issue is also present in asdf module of CLISP on Haiku, so wait for
upstream fix.

> Questions to you :

> Do you consider Haiku a UNIX? Or would it help to be considered a UNIX
from the Lisp application perspective (because CLISP was compiled using
UNIX/BSD compatibility libraries, all classic UNIX functions are available)?


>From the perspective of software porting, Haiku can be considered as
Unix-like (so it has :UNIX and :HAIKU in *features*). If ASDF adds just one
symbol of kind :OS-<something>, this definitely should be :OS-HAIKU. If it
should also contain :OS-UNIX, I cannot say.

Re: CLISP on Haiku

[Alexandru P. <al...@gm...>]

It turns out the problem of removing :HAIKU from *features* when (require
"asdf") is a known bug, which was already solved: after loading ASDF,
*features* contain :HAIKU, :UNIX, OS-HAIKU and :OS-UNIX. However, both
CLISP and QuickLisp use an older version which does not include the fix.

Can ASDF version shipped with CLISP be updated (of course, I will also
contact QuickLisp for this as well)?

One more request from ASDF team is to provide a Docker image with Haiku +
CLISP for testing purposes. Is it possible?

Alexandru