3rd RfD: Directories

On Thu, 7 Aug 2008 18:48:19 -0700 (PDT), brian.fox@rogers.com wrote:

>Could you show us an example of what you mean/how it works?

Here's a real example from a project control file worked on by
three developers on separate sites.

\ set only one of these non-zero
1 constant SFP?
0 constant EGS?
0 constant JOW?

SFP? [if]
"" \buildkit.dev\software\ROM\Common"
setmacro CommonDir \ where the common code lives
"" \buildkit.dev\software\ROM\ARM"
setmacro CpuDir \ where the CPU specific code
lives
"" \buildkit.dev\software\ROM\ARM\Hardware\LPC210x"
setmacro HWDir \ where board specific code
lives
"" \buildkit.dev\software\ROM\Examples"
setmacro ExampleDir \ Examples
"" ." setmacro AppDir \ where application code lives
"" \buildkit.dev\software\AddOns\PowerNet\Dev"
setmacro IpStack \ where the PowerNet stack lives
[then]

EGS? [if]
"" C:\program files\xarm\Common"
setmacro CommonDir \ where the common code lives
"" C:\program files\xarm\ARM"
setmacro CpuDir \ where the CPU specific code
lives
"" C:\program files\xarm\ARM\Hardware\LPC210x"
setmacro HWDir \ where board specific code
lives
"" C:\program files\xarm\Examples"
setmacro ExampleDir \ Examples
"" ." setmacro AppDir \ where application code lives
"" .\SPI" setmacro SpiDir \ where SPI code lives
"" ..\v30dev"
setmacro IpStack \ where the PowerNet stack lives
[then]

JOW? [if]
"" C:\Apps\XArm\Common"
setmacro CommonDir \ where the common code lives
"" C:\Apps\XArm\Arm"
setmacro CpuDir \ where the CPU specific code
lives
"" C:\Apps\XArm\ARM\Hardware\LPC210x"
setmacro HWDir \ where board specific code
lives
"" C:\Apps\XArm\Examples"
setmacro ExampleDir \ Examples
"" ." setmacro AppDir \ where application code lives
"" .\SPI" setmacro SpiDir \ where SPI code lives
"" C:\Apps\XArm\Examples\PowerFile"
setmacro FileSysDir \ PowerFile code
"" C:\Apps\PowerNet"
setmacro IpStack \ where the PowerNet stack lives

[then]

....

SFP? [if] 1 equ DM9000? [then] \ SFP has 100Mb board
EGS? [if] 1 equ DM9000? [then] \ EGS has 100Mb board
JOW? [if] 0 equ DM9000? [then] \ JOW has 10Mb boards

....

include %IpStack%\NetCode \ network order stuff
include %AppDir%\WebConfig \ EEPROM configuration settings
DM9000? [if]
include %CpuDir%\Drivers\EtherDM9000 \ DM9000 Ethernet driver
[else]
include %AppDir%\Ether8019AS \ RTL8019AS Ethernet driver
[then]
include %IpStack%\PowerNet.bld \ PowerNet build file
include %AppDir%\WebAccess \ Web access code
[then]

....

Stephen


--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Aug 7, 3:44 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> > We have that since ages. It is called blocks. It is very portable and
> > very modular.

> LOL!

> I laughed and laughed.
>
> Sure, blocks work fine. But they require people to write their libraries
> in block files, and people don't want to do that.

No, they don't, not if there is a VFS layer that defines a file system
within a span of blocks.

Bruce McFarling <agila61@netscape.net> wrote:
> Jonah Thomas <jethom...@gmail.com> wrote:
> > Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> > > We have that since ages. It is called blocks. It is very portable
> > > and very modular.
>
> > LOL!
>
> > I laughed and laughed.
> >
> > Sure, blocks work fine. But they require people to write their
> > libraries in block files, and people don't want to do that.
>
> No, they don't, not if there is a VFS layer that defines a file system
> within a span of blocks.

OK, that would do it. Then you'd have a VFS built on blocks, and since
nobody would have to care how it was made, it would look like a VFS.
That's fine.

I imagined Albert saying that block files provide a VFS by being block
files, and of course they do. But they are not at all stylish, and I
haven't heard anyone particularly admit to using blocks for years now.

In article <20080807154437.27d3013f.jethomas5@gmail.com>,
Jonah Thomas <jethomas5@gmail.com> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> Jonah Thomas <jethomas5@gmail.com> wrote:
>
>> >And for libraries at least, one solution would be to develop a
>> >Virtual File System (VFS) which would let us do it our own way
>> >independent of host operating systems. If you can find one file on
>> >the host, you have all the files of the library in your own directory
>> >system.
>>
>> We have that since ages. It is called blocks. It is very portable and
>> very modular.
>
>LOL!
>
>I laughed and laughed.
>
>Sure, blocks work fine. But they require people to write their libraries
>in block files, and people don't want to do that.

What makes you think that? Have you come across people writing
libraries, at all?

<SNIP>

Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <20080808211121.399c229c.jethomas5@gmail.com>,
Jonah Thomas <jethomas5@gmail.com> wrote:
>Bruce McFarling <agila61@netscape.net> wrote:
>> Jonah Thomas <jethom...@gmail.com> wrote:
>> > Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>> > > We have that since ages. It is called blocks. It is very portable
>> > > and very modular.
>>
>> > LOL!
>>
>> > I laughed and laughed.
>> >
>> > Sure, blocks work fine. But they require people to write their
>> > libraries in block files, and people don't want to do that.
>>
>> No, they don't, not if there is a VFS layer that defines a file system
>> within a span of blocks.
>
>OK, that would do it. Then you'd have a VFS built on blocks, and since
>nobody would have to care how it was made, it would look like a VFS.
>That's fine.
>
>I imagined Albert saying that block files provide a VFS by being block
>files, and of course they do. But they are not at all stylish, and I
>haven't heard anyone particularly admit to using blocks for years now.

I do. I maintain that my LAB mechanism is both practical and portable.
I have a source library that is common to linux windows and MSDOS, 16/32/64.
It is not a VFS by any stretch of the imagination.
It is a *library* : a handy way to collect and address lots of pieces
of code interdependantly.

Then apparently Bezemer does, but I don't know much about it.

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Aug 8, 9:11 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> OK, that would do it. Then you'd have a VFS built on blocks, and since
> nobody would have to care how it was made, it would look like a VFS.
> That's fine.

Well, you need a format for a span of blocks as a directory, a format
for a span of blocks as a text file, and a format for a span of blocks
as a binary file. The base and number of blocks in a double with the
root directory anchored in the base block. A portable method of
overlaying the FILES access words, support for the Directory wordset
F" ... and a word to access the VFS root directory.

Since the large general purpose collection of libraries does not in
fact exist, it might be more straightforward to specify a library
collection layout in a way that makes it straightforward to generate a
dedicated span of load blocks from a library in the collection.

Bruce McFarling <agila61@netscape.net> wrote:
> Jonah Thomas <jethom...@gmail.com> wrote:

> > OK, that would do it. Then you'd have a VFS built on blocks, and
> > since nobody would have to care how it was made, it would look like
> > a VFS. That's fine.
>
> Well, you need a format for a span of blocks as a directory, a format
> for a span of blocks as a text file, and a format for a span of blocks
> as a binary file. The base and number of blocks in a double with the
> root directory anchored in the base block. A portable method of
> overlaying the FILES access words, support for the Directory wordset
> F" ... and a word to access the VFS root directory.

If you're going to do all that, how is it easier to do it with a block
file versus another file?

You need a place in the file to be a top-level directory. You need a
format to describe directories, text files, binary files, and -- why
not? -- block files.

You need an address for the beginning of each file, kept in that file's
directory, and also a length. If you want to get fancy you could have a
format for fragmented files.

And the words to access it all.

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?

On Aug 12, 9:16 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> Bruce McFarling <agil...@netscape.net> wrote:

> > Well, you need a format for a span of blocks as a directory, a format
> > for a span of blocks as a text file, and a format for a span of blocks
> > as a binary file. The base and number of blocks in a double with the
> > root directory anchored in the base block. A portable method of
> > overlaying the FILES access words, support for the Directory wordset
> > F" ... and a word to access the VFS root directory.

> If you're going to do all that, how is it easier to do it with a block
> file versus another file?

Easier in developing the VFS and testing its portability across
systems that support block files. Once its tested and portability
problems hammered out, if there is a small file-oriented Forth where
the only use of the block file system is supporting the VFS, it should
be straightforward to rewrite the bottom layer of the VFS to use the
native file operating system directly.

> You need a place in the file to be a top-level directory. You need a
> format to describe directories, text files, binary files, and -- why
> not? -- block files.

If its for a VFS in order to hold a library, then the beginning of the
file is where you put the top level directory blockspan.

> You need an address for the beginning of each file, kept in that file's
> directory, and also a length.

Yes, an offset into the VFS blockspan and count.

> If you want to get fancy you could have a format for fragmented files.

If you want to optimize for reading rather than for writing, you could
deliberately design it in terms of block spans and avoid fragmented
files.

> And the words to access it all.

If its a VFS, we already have the wordset, the only question is how to
paste the VFS access on top of the actual file system access of the
implementation.

> What value do we get from using blocks for this?

The value from using blocks as the storage layer for the initial VFS
design would be the automatic test bed on a wide variety of ANS Forths
with the ability to have a common set of debugging tools to directly
inspect the blocks independent of the VFS source.

> 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?

Its no problem for a wide range of applications ... certainly no
problem for Forth source code libraries. So the base design can be
tailored to 16bit counts and offsets from the base of the span of
blocks. If it comes to it, which seems unlikely, a big Forth can
easily cope with multiple VFS files, and if its open source, anyone
that wants to break the 4G barrier can write a larger VFS to do so.

Jonah Thomas wrote:

<snip>
> 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.

--
Coos

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.