Local resource paths - #936

I'll look this over, just want to reference issue #495 as well.

Please include this patch. It’s a hassle because the First Program tutorial doesn’t even work on a standard Linux distribution (/usr/lib/* not writable).

Perhaps a better solution would be to not write to resource:, and move the work directory to ~/.factor-work or something.

@bjourne I realize that we forgot about this pull request, but maybe when you're bored you can rebase it on master so we can revisit it?

@bjourne it would be good to rebase this at some point because user-resource-path and site-resource-path are good concepts towards system-wide Factor.

(Or rather, just re-apply the commits in question to master and force push into this PR).

I tried, but it was all conflict-y and I gave up for the moment.

This one is ancient and probably not of much use anymore. I hope we can eventually look into my waf pr #934 instead. It is a better attempt which I've kept uptodate with master.

How does waf help doing system-wide installations? Don't we have a bunch of Factor-side changes to make?

Emphasizing that I do not think that CMake is a great piece of software, I feel obliged to point out that going to CMake instead would give us a bunch of instant integration with lots of toolchains that waf doesn't. I do volunteer to look at writing a CMakeList.txt if that's appealing.

cmake and a much simpler build.sh to automate the cmake + bootstrap process
would be awesome.

On Wed, Mar 30, 2016 at 5:06 PM, Benjamin Pollack notifications@github.com
wrote:

Emphasizing that I do not think that CMake is a great piece of software, I
feel obliged to point out that going to CMake instead would give us a bunch
of instant integration with lots of toolchains that waf doesn't. I do
volunteer to look at writing a CMakeList.txt if that's appealing.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#936 (comment)

I've resurrected the pr. But not tested it. It adds user-resource-path and writes the boot images and logs to that directory. I think I wrote the pr before I knew about vocab-roots and that you can add how many paths you want by pushing to that variable. So I don't think it is of much use.

@mrjbq7, waf helps because it makes installation easy. On Linux you want the binary in one directory, the .factor files in another, icons in a third and if we ever add .so files in a fourth. It's a mess.. So the Factor changes needed is to make it so a factor binary in /usr/bin/factor can find its image in /usr/lib/factor/factor.image and icons in /usr/share/factor/icons. And it must never write to any resource: directory because it is write-protected (likely).

@bpollack if you want to investigate using CMake, you should look at my wscript too: https://github.com/bjourne/factor/blob/waf-build-system/wscript There is a lot of "wrinkles" to automating the compilation to be aware about. Especially Windows is a pita, and cross-compilation.

Please include this patch. It’s a hassle because the First Program tutorial doesn’t even work on a standard Linux distribution (/usr/lib/* not writable).

Just confirming that the First Program tutorial still doesn't work in Arch Linux in 2020. I've managed to find this github issue which explains why but with my near non-existent knowledge of Factor I don't know how to work around it. Maybe the tutorial can be updated with a Linux work-around?

Fwiw, I set the FACTOR_ROOTS env var to my home directory but "palindrome" scaffold-work still fails with:

Unix system call “mkdir” failed:

Permission denied (13)

It was called with the following arguments:

"/usr/lib/factor/work"

It's supposed to look like this:

"palindrome" scaffold-work
IN: scratchpad Command: continue-restart
1: Note:
Added "tools.scaffold" vocabulary to search path
Creating scaffolding for P" resource:work/palindrome/palindrome.factor"
Loading resource:work/palindrome/palindrome.factor
Creating scaffolding for P" resource:work/palindrome/authors.txt"
IN: scratchpad   P" resource:work/palindrome/palindrome.factor" normalize-path .
"/home/erg/factor/work/palindrome/palindrome.factor"

It looks like you installed Factor into /usr/lib instead of into your home directory. When you normalize-path it uses /usr/lib/factor as a starting point and tries to create /usr/lib/factor/work which will fail without extra permissions.

Did you install a PKGBUILD version of Factor or something?

Here's what I recommend:

cd
pwd  # /home/erg
git clone git@github.com:factor/factor.git
cd factor
./build.sh update
# done

Did you install a PKGBUILD version of Factor or something?

Yeah I did. I'll uninstall it and do it using your steps, thanks erg.

@erg Yeah sure, it's an AUR package so nothing official but this is the one I used: https://aur.archlinux.org/packages/factor/

I also just stumbled upon the scaffold-work error, also using the Arch Linux PKGBUILD linked above. I also initially thought it involved changing the vocab-roots and wasted some time trying various combinations. Finally I was able to figure out a workaround; use "/your/preferred/work/path" "palindrome" scaffold-vocab instead of "palindrome" scaffold-work.

As someone new to Factor I think I would definitely find it more intuitive to have a user resource path separate from the site resource path. Especially because I may want to customize my user resource directory after building Factor. Plus, distros that ship binaries have no way of knowing in advance what the user's $HOME will be.

Or is the idea that Factor should not be installed as a pre-built binary and the user should always compile it from source themselves?

Thank you for the reminder.

We have a few things to improve in this context, and decisions to make, not just about where a user-specific "work" directory might be, but also what does it mean to have a system-level factor.image and what happens when a user does save... presumably they would need to save a user-level factor.image that is attempted to be loaded on startup, and if not available, default to the system image?

presumably they would need to save a user-level factor.image that is attempted to be loaded on startup, and if not available, default to the system image?

I am not a Factor contributor (yet), so my opinion might not be worth much, but now that I am a bit more familiar with how Factor works, I would say that this idea sounds good to me.

Maybe Factor should always save generated images to the user-resource-path, and look for the image in user-resource-path by default. If the user's image doesn't exist, fall back to the default image in system-resource-path. It seems like it may be useful not to change the default system image, to make it easier to revert back to without having to reinstall the whole Factor package; instead the user could just delete their saved image from user-resource-path.

In case it is useful to anyone, the workaround I'm using for this in the meantime is the following (which I have added to my ~/.factor-rc:

SYMBOL: my-work-dir

"/home/user/misc/factor" my-work-dir set-global

my-work-dir get-global add-vocab-root

! my-scaffold-work can be used instead of scaffold-work until this bug is fixed/PR merged: https://github.com/factor/factor/pull/936

: my-scaffold-work ( str -- )
    my-work-dir get-global swap scaffold-vocab-in ;

Just make sure you change the "/home/user/misc/factor" to wherever you want new projects to be stored. The downside is you have to remember to use my-scaffold-work instead of scaffold-work.

https://wiki.archlinux.org/title/XDG_Base_Directory ?

@AndydeCleyre yes and we have the xdg vocabulary (https://docs.factorcode.org/content/vocab-xdg.html) with words for all their defined directories.

Ah, I thought current plans for this were to use e.g. ~/.factor and not follow the xdg defaults or overrides.

I would hope to follow platform defaults for linux, mac, and windows!

Which includes XDG, but we haven't implemented it that way yet.