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

Reply via email to