From: "Ludovic Courtès" <ludo@gnu.org>
To: Katherine Cox-Buday <cox.katherine.e@gmail.com>
Cc: 36131@debbugs.gnu.org
Subject: [bug#36131] Removing some of the Common Lisp packages for ECL?
Date: Wed, 26 Jun 2019 10:56:23 +0200 [thread overview]
Message-ID: <87blykk9mw.fsf_-_@gnu.org> (raw)
In-Reply-To: <87zhm5k0qs.fsf@gmail.com> (Katherine Cox-Buday's message of "Tue, 25 Jun 2019 12:56:11 -0500")
Hello,
Cc’ing Andy as the original author of all this. :-)
Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
[...]
>> I noticed that ‘ecl-hu.dwim.asdf’ and ‘ecl-rt’ fail to build, so I
>> couldn’t test all the ‘ecl-*’ variants. Could you take a look at these
>> two packages?
>
> I focused on the SBCL packages and then retroactively went back and
> added all the ECL packages, trying to be a good citizen. In retrospect,
> this was not a good idea. Common Lisp code is not guaranteed to work
> across runtimes.
>
> If you're OK with it, I would just go ahead and delete any ECL package
> that doesn't immediately work. I can do this myself, but I'm currently
> on holiday and won't be able to take a look for another week and a half.
Sure, removing packages that don’t build sounds good to me. Andy, WDYT?
>> More generally, does it make sense to have ECL variants for each and
>> every package? Or should we trim that down? I’m under the impression
>> that ECL is typically used with rather small code bases since it’s meant
>> to be embedded, but then I’m not a Common Lisper.
>
> I think ECL is used outside embedded contexts, but I haven't found a
> reason to use it yet. If I remember correctly, I think one compiles
> faster than the other, and the other runs faster, so some people switch
> between the two when developing and then deploying.
OK, I see.
Thanks for explaining!
Ludo’.
next prev parent reply other threads:[~2019-06-26 8:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-08 0:08 [bug#36131] Add Multiple Common Lisp Packages Katherine Cox-Buday
2019-06-25 15:39 ` Ludovic Courtès
2019-06-25 17:56 ` Katherine Cox-Buday
2019-06-26 8:56 ` Ludovic Courtès [this message]
2019-07-02 15:51 ` Ludovic Courtès
2020-01-03 20:14 ` bug#36131: " Guillaume Le Vaillant
2020-01-06 9:34 ` [bug#36131] " Ludovic Courtès
2020-01-06 12:06 ` Katherine Cox-Buday
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=87blykk9mw.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=36131@debbugs.gnu.org \
--cc=cox.katherine.e@gmail.com \
/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).