all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: elaexuotee@wilsonb.com
Cc: Maxime Devos <maximedevos@telenet.be>, 48463@debbugs.gnu.org
Subject: [bug#48463] gnu: Add j.
Date: Sun, 16 Jan 2022 20:53:29 +0100	[thread overview]
Message-ID: <e1aa36040fe6bb590834410d482bb8027603f2cc.camel@gmail.com> (raw)
In-Reply-To: <24FU0VP6N4ZZ7.3PE5LG30BSNUQ@wilsonb.com>

Hi,

Am Montag, dem 17.01.2022 um 00:19 +0900 schrieb
elaexuotee@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




  reply	other threads:[~2022-01-16 19:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 10:54 [bug#48463] gnu: Add j elaexuotee--- via Guix-patches via
2021-05-16 14:30 ` Leo Prikler
2021-05-24 13:37   ` elaexuotee--- via Guix-patches via
2021-05-24 14:39     ` Leo Prikler
2021-05-25  3:57       ` elaexuotee--- via Guix-patches via
2021-10-01 15:31         ` Liliana Marie Prikler
2022-01-12  9:47           ` elaexuotee--- via Guix-patches via
2022-01-12 11:06             ` Maxime Devos
2022-01-12 11:10             ` Maxime Devos
2022-01-12 12:07               ` elaexuotee--- via Guix-patches via
2022-01-12 19:55                 ` Liliana Marie Prikler
2022-01-13  7:51                   ` elaexuotee--- via Guix-patches via
2022-01-13 17:51                     ` Liliana Marie Prikler
2022-01-15 14:05                       ` elaexuotee--- via Guix-patches via
2022-01-15 15:08                         ` Liliana Marie Prikler
2022-01-16  5:29                           ` elaexuotee--- via Guix-patches via
2022-01-16  8:04                             ` Liliana Marie Prikler
2022-01-16 15:19                               ` elaexuotee--- via Guix-patches via
2022-01-16 19:53                                 ` Liliana Marie Prikler [this message]
2022-01-17  1:24                                   ` elaexuotee--- via Guix-patches via
2022-01-17 21:12                                     ` Liliana Marie Prikler
2022-01-18  4:01                                       ` elaexuotee--- via Guix-patches via
2022-01-18  8:04                                         ` Liliana Marie Prikler
2022-01-18 10:40                                           ` elaexuotee--- via Guix-patches via
2022-01-18 11:33                                             ` Liliana Marie Prikler
2022-05-28 12:44 ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1aa36040fe6bb590834410d482bb8027603f2cc.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=48463@debbugs.gnu.org \
    --cc=elaexuotee@wilsonb.com \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.