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
next prev parent 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.