2014-08-27 22:52 GMT+02:00 Benjamin Pollack <benja...@bitquabit.com>:
> The idea of resource:work is great, but its location (inside the
> work/ directory of the Factor checkout itself) makes it really prone
> to an erroneous “git clean” if I’m not paying attention. Adding new
> vocabularies via .factor-roots or FACTOR_ROOTS is easy enough, but
> then requires I type out the full path in many situations
> (e.g. scaffold-vocab), which is also annoying, if for no other
> reason than my private vocabulary collection is in different places
> on different machines (different Unix users, different operating
> systems, etc.). What would be great is to say, “Treat
> /path/to/whatever as resource:whatever”. This doesn’t appear hard
> to add, but I’m wondering if there’s a reason we’re not already
> doing so.
I'm not following you. Can't you already do this? Suppose I want to
write a killer game in Factor, first I go to the directory and setup
FACTOR_ROOTS if it's not already setup:
$ cd ~/tmp/facts
$ export FACTOR_ROOTS=.
Then I create a new vocab relative to that directory,
killer-game/killer-game.factor, and implement my killer game:
! ~/tmp/facts/killer-game/killer-game.factor:
USING: io ;
IN: killer-game
: run-game ( -- )
"Killer game not done!" print ;
MAIN: run-game
Then back in the shell, I run it:
$ /path/to/factor killer-game/killer-game.factor
Killer game not done!
I can create a subvocab killer-game.gfx:
! ~/tmp/facts/killer-game/gfx/gfx.factor:
IN: killer-game.gfx
: render-gfx ( -- gfx )
"awesome gfx here" ;
And of course call it from my main vocab:
USE: killer-game.gfx
: run-game ( -- )
"Killer game not done!" print
render-gfx print ;
Maybe I store utility vocabs in ~/tmp/utils, then if I add them to
FACTOR_ROOTS i can access them:
! ~/tmp/utils/mytools/mytools.factor:
USING: io ;
IN: mytools
: my-tool ( -- )
"does something.." print ;
! ~/tmp/facts/killer-game/killer-game.factor:
USING: io killer-game.gfx mytools ;
IN: killer-game
: run-game ( -- )
"Killer game not done!" print
render-gfx print
my-tool ;
MAIN: run-game
$ export FACTOR_ROOTS=.:~/tmp/utils
$ /path/to/factor killer-game/killer-game.factor
Killer game not done!
awesome gfx here
does something..
I really like how it works because imho it's simple and easy to
understand.
> As long as we’re on the topic: it looks relatively easy to extend out the
> vocabulary system to support versions, so that, instead of doing
>
> “whatever” require
>
> you’d instead do
>
> { “whatever” “2.4” } require
What if the directory whatever/2.4/ isn't present but whatever/2.5/
is? I don't think extending the require word to handle semantic
versioning is a good idea.
I'd like to imagine a package more as a directory tree full of vocabs
than a single vocab file. Maybe the deploy.factor system which already
encodes deployment dependencies can be extended for packaging?
> which would allow you to selectively load a specific version of a
> vocabulary into a specific Factor instance based on a slight tweak
> to the path (e.g., maybe whatever/ would become whatever/2.4/). I’m
> guessing we’ve not done this because there’s concerns about this
> approach. What are they? Do we, like the Go community, simply not
> want to support this?
Personally I like packages a lot. But let's start small. You're
talking about not only packaging Factor vocabs but also versioning and
dependency management. It easily becomes overwhelming if you try to
solve all problems at once.
--
mvh/best regards Björn Lindqvist
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
