GNU bug report logs - #50072
[PATCH WIP 0/4] Add upstream updater for git-fetch origins.

Previous Next

Full log

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

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Sarah Morgensen <iskarian <at> mgsn.dev>, Xinglu Chen <public <at> yoctocell.xyz>,
 50072 <at> debbugs.gnu.org
Subject: Re: bug#50072: [PATCH WIP 0/4] Add upstream updater for git-fetch
 origins.
Date: Mon, 06 Sep 2021 13:47:35 +0200

[Message part 1 (text/plain, inline)]

Hi,

Ludovic Courtès schreef op ma 06-09-2021 om 12:23 [+0200]:
> > > > 
> > > > [...]
> > > > Does it support packages defined like (a)
> > > > 
> > > > (define-public gnash
> > > >   (let ((commit "583ccbc1275c7701dc4843ec12142ff86bb305b4")
> > > >         (revision "0"))
> > > >     (package
> > > >       (name "gnash")
> > > >       (version (git-version "0.8.11" revision commit))
> > > >       (source (git-reference
> > > >                 (url "https://example.org")
> > > >                 (commit commit)))
> > > >       [...])))
> > > 
> > > No, it doesn't.  Since the commit definition isn't part of the actual
> > > package definition, the current code has no way of updating it.  It
> > > would require a rewrite of the edit-in-place logic with probably a lot
> > > of special-casing.
> > 
> > Perhaps a 'surrounding-expression-location' procedure can be defined?
> > 
> > (define (surrounding-expression-location inner-location)
> >   "Determine the location of the S-expression that surrounds the S-expression
> > at INNER-LOCATION, or #false if the inner S-expression is at the top-level."
> >   ??? Something like 'read', but in reverse, maybe?
> >   Doesn't need to support every construct, just "string without escapes" and
> >   (parentheses other-things) might be good enough in practice for now)
> > 
> > Seems tricky to implement, but it would be more robust than relying
> > on conventions like ‘the surrounding 'let' can be found by moving two columns
> > and two lines backwards’.  Or see another method (let&) below that is actually
> > implemented ...
> 
> I think we can work incrementally.  It wouldn’t be unreasonable to start
> with a ‘definition-location’ procedure that would work in a way similar
> to ‘package-field-location’ (essentially ‘read’ each top-level sexp of
> the file and record the location of the one that immediately precedes
> the package location.)

‘package-field-location’ (currently) doesn't work like that.  Currently,
it extracts the location from the package, opens the file, uses a procedure
'goto' that works like 'seek' except that it accepts line and column numbers
instead of byte offsets.

What you proposed could work, though it seems a bit inefficient to me.
Asking upstream for an update probably takes a lot more time though.

> But maybe the discussion in <https://issues.guix.gnu.org/50286> will
> give us something nice.

Greetings,
Maxime

[signature.asc (application/pgp-signature, inline)]

Previous Next

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