3rd RfD: Directories

On 14 Aug, 06:51, Bruce McFarling <agil...@netscape.net> wrote:
> On Aug 13, 4:53 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
> > Jonah Thomas wrote:
> > > What value do we get from using blocks for this? Is it a problem
> > > that a 16-bit Forth could only access 4 gigabytes into a VFS, while
> > > with blocks we could have a VFS a thousand-fold larger?
> > As a block number is 16 bit according to standard, 64 megabytes seems
> > to me to be the limit for a 16 bit implementation.
> > I do use sometimes such a file containing 65535 blocks.
>
> Yes, of course, 64Mb ... a 16-byte Forth can access at most 4 Gbytes
> into a VFS (ud), and with blocks we could have a VFS 1/64th the size
> (u*1024), so there's no trouble.

Could it be non blocking as well ;-) (locks on block buffers) Looks
like a B@ and B! needed in the enumerable word set of implementation.

cheers
jacko

On Aug 15, 6:03 pm, jacko <jackokr...@gmail.com> wrote:
> Could it be non blocking as well ;-) (locks on block buffers) Looks
> like a B@ and B! needed in the enumerable word set of implementation.

None of the standard file or block words in the standard specify that,
since the standard does not address multi-tasking.

On this, it'd be inherited from the blocks words, for which at least
at one time it was assumed that multi-tasking words know what they are
doing and don't walk around in block's they should not be walking
around in.

If the VFS is an *implementation* rather than a interface standard
specification, it can be implemented first for the simpler case, and
then an implementation that wants to work in the context of the multi-
tasking of a particular Forth system can sort out how to do it then.

Anton Ertl schrieb:
> This is the third RfD on this topic. The second one was in July
> 2007. You find the updated text further down.
>
> The main point of contention was about the prefix syntax. I solved it
> by removing the prefix stuff.
> [...]
>
> F" lib1/lib.fs" required
> F" data.txt" r/o open-file
> S\" ./funny\"filename" include-name-abs r/o open-file
>

Actually, I have implemented the prefix "./" recognition and
it was released along of PFE 33.69 (May 2008). Since many files
are found along a path of elements, the "./" serves a good value
of what the programmer intends to have - as a preference to the
current path prefix - yes, in some embedded platforms there is no
real "current directory" but it did happen that I was implementing
such a thing on those platforms. In a way I think of that prefix
resolution to be similar to ~userhome resolution syntax - just
pick up a value to make it into an absolute (i.e. canonic) path.
The userhome resolution did already exist in PFE for quite a time
so that I didn't mind to have just another prefix notation.

cheers, Guido