GNU bug report logs - #56989
[PATCH v1 1/5] gnu: bqn: Add bqn.scm and dbqn package.

Previous Next

Full log

Message #28 received at 56989 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Christopher Rodriguez <yewscion <at> gmail.com>
Cc: 56989 <at> debbugs.gnu.org
Subject: Re: [PATCH v2] gnu: bqn: Add bqn.scm and dbqn package.
Date: Sat, 06 Aug 2022 00:33:37 +0200

Am Freitag, dem 05.08.2022 um 11:12 -0400 schrieb Christopher
Rodriguez:
> 
> > Don't let-bind tag, version and hash, use them inline.
> ...
> > Note that version will be bound here even if you use the version
> > field to do so.
> 
> This makes sense, and I've removed the let binding entirely. My only
> uncertainty is where "revision" should go; I've currently attached it
> to the upstream version tag (version "0.2.1-1"), where "0.2.1" is the
> tag and "1" is the revision. Is this correct?
You should let-bind revision and commit.  You should nt let-bind tag,
version and hash.  Use git-version like (git-version "0.2.1" revision
commit).

> 
> > You could do
> >   (replace 'check
> >     (lambda* (#:key tests? #:allow-other-keys)
> >       (when tests?
> >         (for-each (lambda (known-good-test)
> >                     (invoke my-glorious-bin known-good-test))
> >                   known-good-tests))))
> > FSVO my-glorious-bin and known-good-tests.
> 
> I plan to do this once I've been able to look at each test and the
> entire source and see if I can get it working. I've added an issue
> upstream[1] where the author of the package has confirmed it is on
> "just enough life support" to build the recommended implementation
> from source.
> 
> As it stands, I would have to test each test individually anyway, and
> only add it to the package if it arbitrarily passes on my machine for
> some reason. I don't think there is value there, as tests are meant
> to ensure consistency and I cannot do that using such a workflow.
Fair enough.

> And though this *is* and *should be* a public package, it is *not*
> the recommended interpreter for the language. It is primarily
> included here to build the recommended one (CBQN) from source, along
> with some other tools I've yet to package that require it during
> build.
That isn't really a good argument not to have tests though.  While
package maintainers should check that dependant packages still build,
having early failure for a broken package (courtesy of the check phase)
goes a long way.

> 
> > You can use #:rest args to bind args for apply.  Also use assoc-ref
> > rather than cdr + assoc.
> 
> I had, for some reason, flipped the arguments on assoc-ref (which
> obviously didn't work) and when that failed fell back to cdr + assoc.
> I woke up this morning and noticed my mistake; It is fixed now.
Ah, yes, the infamous flip :)

> As for the #:rest args recommendation: I cannot figure out how to
> explicitly bind (list options) to #:options in the apply call using
> #:rest. This is probably ignorance on my part; I am still learning
> the some of the mechanisms in scheme, and have not used #:rest (or
> the dot notation for it) much at all.
(cons* #:options your-options rest) ?

> Is there an example You could point me to so I can educate myself?
> 
> > Is OpenJDK 17 required?
> 
> Really, only a JDK 7+ is required. openjdk17 carries the "openjdk"
> label currently, and so I defaulted to that one. Is there another I
> should use in my packages instead?
If there is no *variable* named "openjdk", I'd suggest using the lowest
one that works.  If people are so inclined to use a newer jdk they can
modify the package graph (which is easier than walking back to the
earliest supported version), plus it's lower bootstrap for those of us
building from source.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.