Better integration

[Earnestly]

I was wondering if it's possible to get better integration with the rest of the system, particularly Linux.

That is I would like to install J to a structure which resembles the following:

# /usr is optional here, it's just a PREFIX.
/usr/bin/j # jconsole conflicts with java packages.
/usr/lib/libj.so
/usr/share/j/profile.ijs
/usr/share/doc/j/...

But as it stands this will result in libj.so failing to load because you appear to hardwire some path into dlopen, I'm not sure.

A somewhat less nice solution I could use is to dump everything into /opt so jconsole has the same directory as libj.so and then symlinking jconsole to /usr/bin/j.

The other feature I'd like to consider is moving .jhistory out of the users HOME and following something more in-line with XDG_DATA_DIR/j/history which would typically expand to HOME/.local/share/j/history. (See https://wiki.archlinux.org/index.php/XDG_Base_Directory_support)

[iocane]

Currently, Unbox only provides the shared library. You should use the jconsole and profile from the standard J release and copy libj.so over the one provided from the J installation or from your distro's package manager. If you are using Arch I believe there is an AUR package available. I believe it does install to a structure similar to the one you provided.

[Earnestly]

Unbox certainly provides the jconsole, profile.ijs and more...

Also https://github.com/jsoftware/jsource has the same problem.
While https://github.com/openj/core is unresponsive to build failures and seems to be stuck on 7.0.1, it does have a slightly better structure at the cost of more workarounds in the profile.ijs to reduce littering the users HOME directory.

I thought unbox was the right place to ask as it seems to be "maintained", unlike the former two.

As for the "AUR", while I'm not sure how it is relevant, I can only find https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=j8-git which is frankly quite horrible and doesn't seem to solve anything... it even comments out the incorrect use of _isnan instead of trying to get it fixed, but then both of the main sources of J don't respond to bug reports shrug.

A workaround I've come up with is something similar, dumping jsource and libj.so in the same directory and symlinking jsource out, but this is not ideal.

[iocane]

This message was posted to the J forum upon release, I probably should include it in the readme:

Currently, the focus is on the core engine which intends to be a drop in replacement for the J Software provided engine. Therefore, the source tree does not include any of the J standard library scripts and the provided profile and jconsole are only meant to run the test suite.

I hope to provide a full distribution in the future, but only the core engine is the focus now. For the time being I would find the best packaging you can from another source and replace the shared library with the one from Unbox.

[Earnestly]

I could do that, say using openj/core or jsoftware/jsource (with a lot of effort), but then how does one make jconsole look for /lib/libj.so? It appears to me that it's hardwared to look for libj.so using the same prefix and directory jconsole inhabits.

[iocane]

Is there a reason you need to use another source release to install the rest of the system?

I use the .deb package from http://www.jsoftware.com/download/j804/install/. Then after building I copy libj.so over /usr/lib/x86_64-linux-gnu/libj.so.8.0.4 and everything works fine.

I assumed you were using Arch because of the link you provided. It doesn't seem too difficult to make a package build that works the way you want, just base it on the contents of http://www.jsoftware.com/download/j804/install/j804_linux64.tar.gz instead of the existing AUR package.

[Earnestly]

I'm not building from stable releases though (and the distribution is irrelevant). The deb and tarball links are also not the source code. The tarball also doesn't follow any kind of standard/ratified directory structure, which is what I specifically asked about...

I'm very likely a complete idiot, but if J is interested in improving things perhaps document the build process in a way that is suitable for systems from the last 15 years (at least on Linux) or change it to match? I really don't know any other way to smooth over this process than being a friend of the current ecosystem.

As I don't really understand how this is currently being done, and I'm not sure how to modify things like profile.ijs to a useful enough extent WRT things like BINPATH and thus don't know how I'd contribute anything useful. The alien style of C used also makes reasoning about the system that much harder (note: I don't mind this per-se, but there are many, many static analysis errors (338 to be specific; including null dereference, use of garbage values, division by zero, memory leaks, and so on) and warnings if you enable it and trying to fix anything is a struggle.)

For what it's worth, here was my attempt, which doesn't work sadly:

NB. /usr/share/j/profile.ijs

NB. Ensure any set XDG_* environments are absolute otherwise fallback on
NB. specification defined defauls.

NB. XXX This could be much cleverer but I am not.
data =. >('/'-:{.(getenv 'XDG_DATA_HOME')){((getenv 'HOME'),'/.local/share');(getenv 'XDG_DATA_HOME')
cache =. >('/'-:{.(getenv 'XDG_CACHE_HOME')){((getenv 'HOME'),'/.cache');(getenv 'XDG_CACHE_HOME')

user =. data,'/j'
tmp =. cache,'/j'

break =. user,'/break'
config =. user,'/config'
snap =. user,'/snap'

NB. Load user provided overrides(?)
load :: ] <data, '/j/profile.ijs'

mkdirp =. 3 : 0
    NB. y is the user input, *shrug*
    p =. y 

    NB. Append a trailing '/' so this function creates all paths.
    p =. p,'/'
    mkdir =. 1!:5
    if. -.# dir }: p do. 
        for_n. I. p = '/' do. 
            mkdir :: [ <n{. p 
        end. 
    end.
)

mkdirp user,'/projects'
mkdirp break
mkdirp config
mkdirp snap
mkdirp tmp

NB. boot up J and load startup.ijs if it exists(?)
load '/usr/share/j/system/util/boot.ijs'