GNU bug report logs - #48463
gnu: Add j.

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: elaexuotee <at> wilsonb.com
Cc: Maxime Devos <maximedevos <at> telenet.be>, 48463 <at> debbugs.gnu.org
Subject: [bug#48463] gnu: Add j.
Date: Sun, 16 Jan 2022 20:53:29 +0100

Hi,

Am Montag, dem 17.01.2022 um 00:19 +0900 schrieb
elaexuotee <at> wilsonb.com:
> > > Interesting idea. How about just always forcing a MINOR part,
> > > setting to "0" if upstream doesn't have one?
> > That'd declare regular releases as MAJOR.0 in the version field,
> > which I'm not sure if we want that.  In the case of random commits
> > I'm less reserved, as they don't correspond to releases anyway.
> 
> I see your point. In fact, upstream releases start with MINOR part "a"
> and "count up" through the letters over the course of a year. It's a
> pretty simple scheme. For example, J 901 started at "j901-release-a"
> and ended at "j901-release-f".
> 
> When I originally wrote this package, I noticed that the release tag
> for the first J 902 was "j902-release", and so treaded MINOR as
> potentially optional.
> However, after checking upstream's forums, this looks to just be a git
> tag mishap.
> 
> How about we just go ahead and treat MINOR as mandatory as well?
In other words minor should always have a value >= "a" and 902 was just
missing it?  Fair enough, in that case making version mandatory sounds
like the way to go.

> > > If you have a better idea, I am all ears.
> > You could define that file-union right after ijconsole.  If you want
> > to
> > golf even more, you could define ijconsole inside that file-union,
> > i.e.
> >   (define jsoftware-aux-files
> >     (file-union "jsoftware-aux-files"
> >       `(("profile.ijs" ,(search-aux-file ...)
> >         ("ijconsole" ,(program-file ...))))
> > 
> > I'm not quite sure if you want to use jsoftware-aux-files directly as
> > input or whether it's wiser to stuff it into another union like 
> > (file-union "jsoftware-aux-input" `(("aux" ,jsoftware-aux-files))).
> > search-input-file will probably do the right thing regardless.
> > The new style should also still work with assoc-ref, it'd just be
> > weirder to look at.  Lastly, you could code up a (search-file-input)
> > just in case; I'm not sure if we have one already.
> 
> The file-union seems like a cludgy workaround to me. What we really
> want is an easy, direct way to get handles on the input files. Heck,
> program-file objects already have a name property; why can't we use
> that? Attached patches are a proof-of-concept.
That proof of concept does look nice, but for one we're trying to move
away from labels, and for the other, it's on a scale that I don't want
to decide as part of a package addition.  If you feel it has value
outside of the proposed usage for j, discussing it under a different
number or perhaps on guix-devel might be worth it.

> That said, if this is going to turn into a big rabbit hole, can we just
> munge the J package inputs into whatever you think is best?
As said in my previous mail, that'd be
> >   (define jsoftware-aux-files
> >     (file-union "jsoftware-aux-files"
> >       `(("profile.ijs" ,(search-aux-file ...)
> >         ("ijconsole" ,(program-file ...))))
In my personal opinion, you can then simply add jsoftware-aux-files as
input and (search-input-file "ijconsole") instead of the current assoc-
ref.  WDYT?

Don't worry, I don't plan to drag this out too long, but I also don't
planning on pushing this today.  There are definitely some stylistic
choices that I want to make under the considerations here (basically,
we can just merge major and minor into a single base that'd be "903.a",
for example), but it's almost bedtime and I want to relax a little
before going to sleep.

Cheers

Previous Next

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