Re: slib and Schemes
Rob Browning <rlb@defaultvalue.org> writes:
> Göran Weinholt <goran@weinholt.se> writes:
>
>> Rob Browning <rlb@defaultvalue.org> writes:
>>> We could also just rely on auto-compilation, and accept the wasted
>>> space, longer initial startup-times (per user after an upgrade), and
>>> potential risks related to changes in macros, but that's perhaps not
>>> ideal.
>>
>> For Chez Scheme it would be better to do nothing at all, its compiler is
>> very fast. Guile's compiler can take some time, so I guess it would be a
>> large benefit to at least do something. But this also speaks against
>> this strategy, I've seen *very* slow compilation times with Guile, on
>> some libraries. It could quickly make apt upgrade very painful.
>
> I sympathize, though I suspect it might end up being one of the
> preferable approaches given all the trade-offs, but we'll see (still
> pondering). And I think we'd be able to limit the scope of the
> rebuilding when library packages are upgraded (likely to the given
> library and all of its reverse dependencies).
Well, you make an excellent point by bringing up trade-offs. Building
during installation and certainly preferable to not doing it, even if
it's slow. Hopefully it pays off in faster run time.
>> Perhaps in this case it should be rebuilt in the background if that's
>> feasible; the user should not wait for it to be completed.
>
> Unfortunately, for Guile specifically, I suspect that won't be feasible,
> [...]
I concede the point here as well, and it will be better to have
something instead of nothing.
>> It's also possible that I'm overthinking everything and we can just use
>> the Depends: field and then dig out the dependencies with dpkg. It would
>> be more coarse, and would recompile more libraries, but it would have
>> fewer moving parts.
>
> Hmm, indeed, at the moment, I suspect this may be preferable.
>
> I'm not familiar with Akku yet (though it definitely sounds interesting)
> but at least for Guile, for our purposes I'd think that there may not be
> a solid way to collect the right set of dependencies in advance,
> i.e. it's entirely possible to do non-declarative imports:
>
> (when weather-is-good?
> (import (consult-omens-for-the-list))
Very indeed. This particular case can err on the side of assuming good
weather, but in general it's possible to have things like:
(eval expr (environment some-library))
In the general case it's impossible for static analysis to find out what
some-library refers to, so we should not build a system that assumes we
will ever write such an analyser.
[...]
> Given that, I'd been leaning more toward something like emacsen-common
> (though I think we could do something simpler[1]) that just relies on
> Debian package dependencies, since they already have to be correct at
> their level of granularity (which as you mention, is coarser).
This sounds very good. At some later point we can also have a debhelper
script for Scheme that adds automatic dependency analysis, which is
something I'm interested in working on (but not right now).
> Where feasible, I'd think we should aim to make the harness general
> enough to allow implementations sufficient latitude. For example, maybe
> Guile ends up not being able to rely on debian triggers for compilation
> (perhaps because of the potential for races with auto-compilation), but
> if possible, we might not want to preclude other implementations from
> relying on them.
>
>
> All that said, I haven't had time to *really* contemplate what kind of
> approach I think might be preferable, but here are a few things I have
> been considering: #include <giant-grain-of-salt.h>
[...]
> I'm sure none of that's quite right, and it's definitely too simple, but
> perhaps it communicates the general idea. And whatever we do, if we
> *do* end up pursuing some "cross scheme implementation" infrastructure,
> I think we should try to make the common case as simple as we can
> (cf. dh, dh-elpa, etc.), even if we still need to allow additional
> complexity to handle some situations.
This seems like a good approach, but the details will only come out when
it's put to the test. So how do we test it?
We seem to have come to a different conclusion for slib, namely that it
will take care of everything by itself in its own postinst. (Unless you
disagree with that, I haven't seen your opinion).
What other packages to we currently have that works in many Schemes and
will benefit from the approach we're discussing? I'm only aware of
r6rs-nanopass-dev, which works with chezscheme and ikarus, but I've also
uploaded chez-srfi (stuck in NEW) that works with several more Schemes,
including Guile. That might be the most complicated package to start
with though, since SRFIs get very special treatment in Guile. I'm
thinking to upload ijp's pfds (purely functional data structures), which
is an excellent software package and is also portable to all R6RS
Schemes. Do you know of anything to use for a proof of concept, that is
already in the archive?
--
Göran Weinholt | https://weinholt.se/
Debian Developer | 73 de SA6CJK
Reply to: