Arch Linux User Repository

@serkho Thank you - and for your packaging of FriCAS. I ended up doing exactly that: using git to create a local repository, compiling with makepkg and then installing with pacman -U. All good and I didn't need any of the helpers at all. (Now I have to work out how to provide fonts for HyperDoc; the fonts it wants don't seem to be available to it, and the default fonts are too tiny on my screen to be usable. And I'll also look into jfricas and hunchentoot (SBCL webserver) for use with Jupyter.)

@amca01 I just downloaded the latest snapshot and built it with makepkg successfully. So I guess it has something to do with trizen. Looking into its readme I can see it has a --debug flag which might help you to debug the issue.

@neven Many thanks for your reply, and for the heads-up about mentioning AUR helpers. I didn't realize that issue (about potential infinite numbers of helpers, and hence impolite to mention which one) and in my innocence I imagined that it may have been helpful. But in respect of my particular issue, I can see now that the helper is, or should be, irrelevant. Anyway, I'll take your expert advice, with again many thanks.

@amca01 Your best option is to troubleshoot. This means you should use the AUR without a helper (i.e. just run makepkg). I guess your issue is caused by an AUR helper bug, so this may even fix it for you. BTW, consider that the amount of AUR helpers is potentially unlimited, so mentioning which AUR helper you use is in fact impolite when reporting a bug or asking for assistance. What helper one uses is really noise at best, at worst it could be interpreted as demanding other people to try out your random helper.

I've tried downloading and installing FriCAS using trizen as my AUR helper; all went well until after some minutes of work it stopped with

:: Unable to find a built tarball for fricas.

What's my best option here? (I know I could download and compile FriCAS from its source code, but that seems like overkill.) I know this is a very niche package, and if this is a case of my working it out for myself, I'll understand. But as always, advice is very welcome.

@neven, thanks. I've updated the package, let's see how it works

My suggestion to set memory limits so as to be effectively unlimited was not good.

This seems to work correctly instead: in the "build" bash function in the PKGBUILD:

./configure --prefix=/usr '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 6000'

I have been playing around with Fricas and one thing that is bothering me is SBCL memory usage limits. I often run out of stack or heap space, which is enforced by SBCL and causes the Fricas command in execution to fail with some ugly warnings.

It would be optimal if the limits could be set at run time (if any SBCL devs read this: USE GETRLIMIT, so I could set limits myself with ulimit), but I suspect that is not possible.

In view of that, could you configure SBCL to increase the stack and heap limits to a large value to make it effectively unlimited, or just set it to 8 GB? The relevant SBCL options seem to be --dynamic-space-size and --control-stack-size .

@bertalanp99 Looks like a temporary outage on SF side, working ok now. Can you give it a try again?

Downloading copyright.txt fails, can't install :/

I'll mark it out-of-date. September 25, 2015 -- FriCAS 1.2.7 released http://fricas.sourceforge.net/

Seems to out-of-memory on build for me? Heap exhausted during garbage collection: 0 bytes available, 16 requested. Total bytes allocated = 1072754400 Dynamic-space-size bytes = 1073741824 fatal error encountered in SBCL pid 27525(tid 140737353762560): Heap exhausted, game over.

Apparently SBCL needs it. I removed the execstack flag from an SBCL-compiled binary and it stopped working.

...but "executable stack" looks like a security hole. I think, this is something, which the developers should address.

Warnings about missing lisp and interpsys are caused by shebang in .fasl files. It does not affect the functionality.

Thanks for the report. namcap errors have been fixed and I will look what can be done for its warnings. BTW there was no need to flag the package as out of date: I am subscribed on all comments and the version was 1.2.2 already :) Thanks anyway.

namcap gives the following output: fricas E: Missing custom license directory (usr/share/licenses/fricas) fricas W: ELF file ('usr/lib/fricas/target/x86_64-unknown-linux/bin/AXIOMsys') has executable stack. fricas W: Referenced library 'lisp' is an uninstalled dependency fricas W: Referenced library 'interpsys' is an uninstalled dependency fricas E: Dependency libxpm detected and not included (libraries ['usr/lib/libXpm.so.4'] needed in files ['usr/lib/fricas/target/x86_64-unknown-linux/bin/htadd', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/ex2ht', 'usr/lib/fricas/target/x86_64-unknown-linux/bin/hypertex', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/spadbuf', 'usr/lib/fricas/target/x86_64-unknown-linux/bin/viewAlone', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/hthits', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/view2D', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/viewman', 'usr/lib/fricas/target/x86_64-unknown-linux/lib/view3D']) fricas E: Dependency gawk detected and not included (programs ['gawk'] needed in scripts ['usr/lib/fricas/target/x86_64-unknown-linux/lib/presea'])

September 28, 2013 -- FriCAS 1.2.2 released