Daniel Ehrenberg wrote:
> how do you include unit tests (without manually finding the files and
> calling run-file)?
The plan is to have a test-vocab word that is analagous to test-module. It
should be easy to add:
Let's say you have a vocabulary named 'foo.a'. Assuming that this vocabulary
is documented and has tests, these would be the files for the vocab:
foo/a/a.factor
foo/a/a.facts
foo/a/a.tests
The first time that foo.a is loaded from disk, the facts file is loaded too.
The a.tests file holds the tests that correspond to that vocabulary. These
words are defined in libs/vocabs.factor :
: find-vocabulary ( vocab -- file-or-f )
: find-facts ( vocab -- file-or-f )
: find-tests ( vocab -- file )
For example:
"foo.a" find-vocabulary => ".../foo/a/a.factor"
The ... represents the rest of the full path.
So find-tests is similar:
"foo.a" find-tests => ".../foo/a/a.tests"
A test-vocab word should be easy to build on top of that. Anyone wanna take a
crack at it? :-) It would be nice if one of y'all that has more experience
with tests in factor added some input on this part.
> Also, do you think it's possible to make an automated tool to do the
> transition, at least partially?
Part of the transition can be automated:
$ find . -name 'load.factor' -exec rm '{}' ';'
:-)
One-file modules like alot of doublec's are trivial. With multi-file ones,
you'll often want to make a sub vocabulary for each file. To do that, you
just create a directory for it, move the file to that directory, and rename
it. So the current xml/data.factor file would now be:
xml/data/data.factor
It's IN: would be:
IN: xml.data
Lastly, update the USING: line of any vocab that needs this vocab to reflect
the new name (the old name was xml-data).
> outside of the core, there is usually one help (or occasionally two) file
> per module, covering the whole module. How can that be represented with your
> system?
Each vocabulary can have a corresponding facts file. Assuming that a
traditional module would be broken up into a few vocabularies, your
documentation would be built around particular vocabularies. Awhile back, I
converted libs/xml to use libs/vocabs. The converted directory looked
something like this:
xml/xml.factor
xml/xml.facts
char-class/
entities/
data/
errors/
etc...
In that case you only had one facts file. So it's associated with the xml
vocab. But if there were a complex subsystem with it's own vocab and you
wanted to document it, you could give that vocabulary it's own facts file.
For example, if you wanted to document the xml.char-class vocabulary, you'd
just create this file:
xml/char-class/char-class.facts
and you'd be done.
Slava and I discussed the problem of associating a vocabulary with an article.
To keep things simple, we decided on something like a hashtable that does a
vocab/article mapping. Perhaps in a future revision, we could promote
vocabularies to an actual TUPLE object with properties and things. I would
prefer to keep things as they are at this point.
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
