[bug#48463] gnu: Add j.

[elaexuotee--- via Guix-patches via <guix-patches@gnu.org>]

> I tried to get J ready for packaging, but thanks to my CPU not
> supporting AVX2 and some helpful discussion in IRC, I was able to avoid
> an error here.

The black hole has extended it's grip...

> The (guix cpu) code is not meant to be used at runtime as the comment
> to ijconsole implies it wants it to be used.  Rather, you should use it
> at compile time to bake in the correct tuning parameters, and it should
> ideally also support "cross-tuning" (though in that case you probably
> need to disable the tests because your CPU won't make sense of the
> code).

Hrm... Mind if I ask about the rationale? We could go back to scraping
/proc/cpuinfo, but I suspect that's not addressing the issue you have in mind.

> ijconsole not only fails that, but it also fails at an even more basic task
> in Guix' launcher scripts, which is actually knowing the thing you launch.
> (We hardcode everything, period.)

Okay. I see the logic in that.

The original patch indeed hard-coded paths in the ijconsole script, but that
required having ijconsole be a wrapper package. I thought I was being clever by
eliminating a "needless" wrapper, but it sounds like we can just bring it
back.

> Now I could just disable everything AVX-related in J and push something
> that works on x86 and amd64, but since you do claim that AVX is
> important to J, there are also other options one could take here.  One
> is to implement tuning for this package the correct way, though since
> it reinvents build systems, that's probably going to be a hard one. 
> The other would be to define package variants (e.g. jsoftware-j-with-
> avx) and use those -- there ought to be an old blog post on Guix HPC
> detailing the rationale behind doing that.

Not including AVX would be a hard hit.

Morally, the ijconsole script just wraps the libj*.so libs into a "fat binary".
From what I understand, fat binaries are (were?) an accepted solution in the
HPC world. Heck, the libj*.so total up to a whopping 15Mb, which feels more
like slim that fat, anyway.

Questions floating around in my head:

- What is wrong with detecting CPU features in a wrapper vs in the binary?
- If a wrapper is theoretically okay, how can we fix the current one?
- Is such a "proper fix" massively more subtle and bug-prone than the naive
  solution? Why?

> WDYT?  Is AVX worth the trouble?

Personally, I really do not like the jsoftware-j-with-* variants workaround. If
you say that tuning support is the only other acceptable solution, then I'll
bite the bullet and see what is possible.


P.S. Just throwing this out there, but if you'd like, I'd be willing to do a
mob session together. It seems like we are in compatible timezones.