Ricardo Wurmus schreef op ma 14-02-2022 om 23:32 [+0100]:
> I think we should add simple type checks, something like this:
> [...]
>
> What do you think? There are many different ways of implementing this
> (a new variant of DEFINE that also accepts a type declaration, an assert
> like above, a f
Hello Liliana,
On 2/14/22 20:33, Liliana Marie Prikler wrote:
Hi Zelphir,
Am Montag, dem 14.02.2022 um 18:41 + schrieb Zelphir Kaltstahl:
Hi Michael!
What I mean by that is the following in `init.el`:
(setq guix-package-enable-at-startup t)
(require 'guix-init nil t)
I have a sep
Hey Ludo,
> As discussed on IRC, I’m skeptical about this because:
>
> 1. It requires the development and testing of a custom tool that’s
> easy to get wrong—e.g., it removes a gzipped nar for something that
> had nothing but gzip available, etc.
>
> 2. That code would have to run
Hi guix,
It sounds like a good idea, but ISTM we don't need yet another markup syntax
if emacs org mode already defines a useful standard that can be adopted.
The advantage to org mode style [0] -- in commit commentary as well as tags
would be its scrapability -- i.e., ease of writing an extracto
Hi,
On +2022-02-05 15:12:28 +0100, Ludovic Courtès wrote:
> Konrad Hinsen skribis:
>
> > There is obviously a trade-off between reproducibility and performance
> > here.
>
I suspect what you really want to reproduce is not verbatim
code, but the abstract computation that it implements,
typicall
Bengt Richter schreef op di 15-02-2022 om 13:23 [+0100]:
> Hi guix,
>
> It sounds like a good idea, but ISTM we don't need yet another markup syntax
> if emacs org mode already defines a useful standard that can be adopted.
>
> The advantage to org mode style [0] -- in commit commentary as well a
This is largely resolved now - turns out my code sucked rather than needing
to do something clever with Guix module importing, which is what I
suspected ;-)
The only compromise I'm making now is that any complicated manifest for
example, I am having to split into a trivial manifest script calling
Ludovic Courtès writes:
>> The only thing I can see that's required before merging though is the
>> exports. I'm now thinking about this kind of thing (getting data out of
>> the data service) in the context of patch/branch review.
>
> I think there’s a couple of issues that would be nice to add
Mathieu Othacehe writes:
>> I like Chris Baines’ idea of decoupling nar distribution from nar
>> building. If we want to keep nars long enough so that ‘time-machine’ is
>> usable, then storage requirements will keep growing.
>>
>> Perhaps that means we can regularly copy nars “elsewhere” for lo
Hi Zelphir,
Am Dienstag, dem 15.02.2022 um 09:45 + schrieb Zelphir Kaltstahl:
> Hello Liliana,
>
> On 2/14/22 20:33, Liliana Marie Prikler wrote:
> > Hi Zelphir,
> >
> > Am Montag, dem 14.02.2022 um 18:41 + schrieb Zelphir Kaltstahl:
> > > [...]
> > I think we need some multi-level print
Hi,
On 2/14/22 17:32, Ricardo Wurmus wrote:
As you can probably tell easily by looking at this message, the
“service” field of the operating system configuration looked something
like this:
(services (append (list a b c %desktop-services) #;oops))
instead of this
(services (append (list
Philip McGrath writes:
> As a Racketeer, I think you're half way to reinventing contracts.
Yes, I was in fact thinking of contracts, but shied away from mentioning
them :) The reason is that I think we can cover a lot of distance with
just a few simple assertions to avoid plowing ahead on bad
12 matches
Mail list logo
