On Mar 11, 8:32 am, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Great! Would it make sense to do that with the draft specifications and
> loose ideas before you have anything running? If it's a significant
> effort I'd think it wouldn't be worth doing, but if you're writing stuff
> out anyway and organising it for your own use, and if you have an HTML
> editor that doesn't much get in your way, is there much to lose?
For most projects, or if the whole ball of wax is seen loosely as
"Nicl", yeah ... I write a rough draft specification, then see if I
can do it, and edit the specification as I find out things I can't do.
There are a range of social programming constraints built into Niclos
as such that respect limits of small systems, because retro computers
is another hobby. Its not necessary for each project to respect those
limits ... a project doesn't have to run on every system to be
collected in the library ... but if the library oversight system
doesn't, they are entirely excluded.
For example, designing the file system so that it is comfortable
working with an 8.3 filename and 8.0 subdirectory naming constraint is
something that is much easier to build in from the ground floor than
to add after, as is building the system so that you never have to go
down more than one subdirectory level ... and doing that means that /
foldname/filename.ext or ^foldname/filename.ext fits in 22 characters.
Add a block range for a 16-bit system in HEX, and you even have room
to spare to protect the data block from being executed and make it a
trans****table block-line.
\ 0000001F/foldname/filename.ext 0020003C^foldname/filename.ext<CR>
None of the system of allocating a range of blocks for use as pseudo-
files and using them to provide a strictly limited type of text file
has to be ****table code ... the code is ****ted via the Forth-94 file
words, which are well designed for this kind of problem.
|
