Slava,
I'm trying out the following vocab/file mapping:
USE: foo => foo/foo.factor
USE: foo/a => foo/a/a.factor
USE: bar => bar/bar.factor
It's the METHOD A from our previous discussion. It's actually not that bad
after all. I have a vocabs/ directory in Factory/ in which I'm testing this.
So far I've ported the following modules to it:
calendar
circular
concurrency
dlists
http
match
serialize
x
xml
I don't have alot of experience with writing Factor facts, and none with
tests. :-) So I decided to port other modules to see what they would look
like with the new system and to add support for facts and tests.
This is the file that implements the system:
http://onigirihouse.com:9010/vocabs-a.factor
When you USE: foo it will look for foo.facts as well.
When porting calendar, I stumbled upon an area that I hadn't thought about.
The issue of os-unix and os-win32 files. Currently, we hide these dependencies
in load.factor files. My quick solution is platform specific parsing words.
At the beginning of calendar.factor is this:
WINDOWS-USE: calendar.win32
UNIX-USE: calendar.unix
... the rest of calendar.factor
So how do you wanna move forward? One idea is for me to push out darcs patches
for this vocabs/ sandbox. The drawback is we'll clutter the filesystem for a
bit while we work things out. The upside is that all the module developers
can try things out and chime in about their experience with it. Since the
clutter would go away when things settle, I think this route is OK.
A more conservative route would be for me to only stick modules I'm personally
developing in vocabs/ and push that out. So I'd put x, wm, and factory there
for starters. Then let the other folks put things there on their own time.
There's no problem with moving around vocabularies between libs/, apps/, and
vocabs/. Thanks to the vocabulary-roots mechanism, there is no impact on
vocabulary naming. So we could build things in vocabs/ and move them back
into libs/ or apps/ with no problem. On my system, I actually have two copies
of the x vocabulary and I choose which one to use by changing the order of
libs/ and vocabs/ in the vocaulary-roots variable.
At any rate, you can browse a copy of my vocabs/ sandbox at:
http://onigirihouse.com:9010/vocabs-a/
Chris Double's vocabs were very easy to convert. The vocabulary that underwent
the most adjustments was xml. All of it's sub vocabularies are now named like
xml.errors, xml.utils, etc. So I had to change those names where they are
referenced in USING: statements.
With this system you can do:
USE: xml
to grab everything. Or for example:
USE: xml.writer
Which will only pick up that vocab and it's one dependency, xml.data. I like
this piecemeal loading ability because it will allow other developers to load
parts of other "modules" as they need them, without loading the entire thing.
Each vocabulary does get a directory. This directory can also hold optional
facts and tests.
Ed
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk