unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Programmer <programmer@verisimilitudes.net>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: guix-devel@gnu.org
Subject: Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)
Date: Fri, 09 Nov 2018 15:17:53 -0500	[thread overview]
Message-ID: <in16j98u.fsf@server.domain.com> (raw)
In-Reply-To: <87bm6y4ipf.fsf@ambrevar.xyz> (message from Pierre Neidhardt on Fri, 09 Nov 2018 12:02:36 +0100)

>Sure: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/lisp-utils.scm
I've only taken a look at lisp-utils.scm so far.  I can see it explicitly supports sbcl and ecl.
It's possible to get most or all of this in purely portable Common Lisp, which would make adding
more implementations require no effort.

>But how do you build this for a single Guix package?  If you want FASLs for,
>say, SBCL and CCL, then you need to invoke both compilers when building the Guix
>package.  It would be much to heavy weight that every single Lisp package
>depended on all Lisp compilers, plus it would result in disk consuming packages
>that would benefit practically no one (no one uses all Lisp compilers at the
>same time).

>I could be missing something.  Can you see a way around this?
I do see value in offering compiled forms of standalone Common Lisp programs, such as StumpWM, but
don't see the point in doing this with Common Lisp libraries.

The common way to do this in Common Lisp is to distribute the source and simply compile it as
needed.  It can be advantageous to have this choice easily.

The basic idea is simply that the system package manager installs libraries wherever it will and
places a file that will load this library and its own dependencies properly in the user's home
directory.  It would be simple to have it check for and load compiled versions if present or compile
them if not after loading for faster reloading.

So, this would enable you landing into a new system to, say, reuse your Common Lisp initialization
files that reference the directory and seamlessly pick up from where you left off, once the system
package manager installs things.

Does this idea make sense?

>If this is more general than Guix, does it still belong to the Guix project?
>Shouldn't it belong to the Common Lisp community as a replacement for ASDF?  I
>know the Common Lisp community has been talking about replacing ASDF for a
>while.
I thought Guix would be a good first place to propose this idea.  If it would be more appropriate, I
now have time to build a first approximation of this idea, although I lack the Guix knowledge for a
robust implementation.  I did provide a simple example of this in my initial message, which shows
the file a library would have that loads another library that has no dependencies.

>Fare (one of the maintainers) has talked about it a few times:
>https://fare.livejournal.com/190738.html and other articles.
I'll make certain to read this.  I've read some of his articles before.

>But who places those files?  Guix cannot.
>Did you mean the user guix-profile instead?
I'm not certain by what you mean.  I did ask around earlier and learned it's not uncommon for Guix
to place files in the user's home directory when needed.

I'm not particularly familiar with Guix terminology yet.

>My understanding is that CL-CFFI makes those assumptions.  A few months back I
>had brought up the issue upstream and they told me they were not eager to change
>it.
>The way we do it now is probably optimal.  See cl-sqlite for instance.
I'll need to take a look at those later.

>I'm realizing my answers might come off as discouraging.  I hope it's not, we
>still need to work on the build system on the Guix side, while the Common Lisp
>side would certainly benefit from improvements to ASDF (or its successor).
You need not worry about discouraging me.  I'd be delighted to see ASDF and Quicklisp replaced with
more intelligent, simpler, and more secure solutions for this simple problem.

  reply	other threads:[~2018-11-09 20:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-09  6:45 Lisp libraries: Other variants? (CCL, CLisp, etc.) Programmer
2018-11-09 11:02 ` Pierre Neidhardt
2018-11-09 20:17   ` Programmer [this message]
2018-11-10 10:02     ` Pierre Neidhardt
  -- strict thread matches above, loose matches on Subject: below --
2018-11-05  1:35 Programmer
2018-11-05 21:03 ` Pierre Neidhardt
2018-10-20 10:10 Pierre Neidhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=in16j98u.fsf@server.domain.com \
    --to=programmer@verisimilitudes.net \
    --cc=guix-devel@gnu.org \
    --cc=mail@ambrevar.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).