On Mar 10, 8:51 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Would it make sense to start with prototypes that do part of the job
> simply? Get something working and extend it over time?
Either that, or get something that comes close enough to running that
someone who can program wants to use it, and then they do it right
because the rough edges annoy the hell out of them.
> It would probably be necessary to undo some work that way. New versions
> of your library system would develop incompatibilities with old ones.
Yes, that is built into the wordlist management words.
* A request for a version only matches that version ... if a range of
distinct versions are OK, then multiple versions can be specified, and
the first that matches is selected. A later version that is upwardly
compatible (or has a ****tability harness) would alias to allow code
that does not know about the earlier version to use it ... and a later
version that is not upwardly compatible would not.
* A request for a revisions within a version matches that revision or
any revision that is higher (sorts after it lexicographically).
> But it's so much more pleasant to get something working than to wait for
> it to do everything....
> The library oversight system looks like a good early effort because it's
> a useful tool for the other things. Save the info with ENVIRONMENT?
> strings or some other way?
As source, there is a defined source hierarchy system. As code, there
is a sketchily defined wordlist hierarchy. SEARCH words are a
dependency (of course, some systems might require a single explicit
prelude file before they can load and run Niclos base to get to
autoload).
So far, information is saved as compiler constants and values in
Niclos-tools, which will alias to be the same as
[]Make tools []
in the Niclos wordlist management system.
And so far, there is more specification than running code.
> Are you interested in breaking one or more of the projects down into
> modules with assigned interfaces, and see whether volunteers do any of
> it? Maybe set up a web site with the specs? Even if you don't get any
> volunteers the time you put into specifying it might not be wasted.
Yes, once I have a running VER0 REV0 of Niclos, I'll put it up in the
file section of an open-to-join Google group, along with various
projects, either draft specifications, loose ideas, or existing source
to integrate in.
The core of the file system is the three level hierarchy of Niclos
source files.
# .fs files don't know anything about where they are in the wordlist
hierarchy, and don't know how to use any of the tools for managing
their dependencies. They are allowed to make subordinate wordlists if
they wish, but work with the namespace that they find, and leave
things the way they find them. They can use [DEFINED] / [UNDEFINED]
for conditional compilation, so that a script can optionally compile
Nicl-tools words that it uses in case it is included outside the
Niclos system.
If the folding section markers ( -[ --[ and ---[ ) appear in a .fs
file, it is inside a ``\'' comment line.
# .fsn files know about the wordlist hierarchy. However, they only
know about the current directory ... they do not include any
filesystem management. They can execute source with the folding
section markers, passing over all text between the section marker and
the first ``\'' comment line before beginning to execute the source.
The Niclos wordlist management words appear in a .fsn files:
[]Make services ThePanel []
[]Use library charscan []Use tools mini-oof []Use tools scripts []
[]Version VER3 REV03 VER2 VER1 []
There's also a result state from those that can be used as a
conditional compilation flag, []? as the result state itself and []??
to give the complement as an amenity.
The -[ --[ ---[ fold-able section markers are specified with an eye to
conditional compilation at the granularity of a section, but just
block comments are fine to start with, and that's working.
# .nlf files know about the whole system ... which model is in use,
where to go in the file hierarchy to look for a file to script the
specifics for a sup****ted model, how to read a configuration file and
use it to set compilation options, how to select sections of .fsn
and .fs files for conditional compilation.
Obviously, .fs files we already have ... .fsn files are on the way
sometime this year, which season of the year is up in the air ... .nlf
files, we'll see. But there's no need to wait until the facilities
for .nlf are available before writing using the facilities for .fsn
files ... if the .fsn file needs that, its trying to do something that
will confuse things when the facilities to run .nlf files are up and
running.
By placing some restrictions on files, it should be possible to hammer
out the process of generating an appropriate set of blocks for a block
oriented system ... chiefly source is written to use ``Nicl-refill''
rather than ``REFILL' which respects the current block range if it is
being interpreted from a BLOCK via ``Nicl-thru'', and the library file
standard is for simple ascii text files with a right margin of 63 or
fewer columns.
|
