3rd RfD: Directories

Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: 3rd RfD: Directories
> In article <33363617153559@frunobulax.edu>, Marcel Hendrix <mhx@iae.nl> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: 3rd RfD: Directories
[..]
>>> To be specific. What I do is reserve a directory for a project.
>>> Libraries are in a fixed (system dependant) path.

>>> In the directory is a main program with

>>> WANT NIP / library code
>>> INCLUDE this.frt
>>> INCLUDE that.frt

>>> Never needed to get any more complicated than that.

>>Of course there is. At some time a user of your Forth will want to
>>use library code that is not written by you and comes in a separate
>>directory or file (like the ffl).

>You mean like a c include file that is in
> /usr/include/X11

Do you want to start a directory naming scheme convention for Forth?

> What is the problem?

E.g. the Dick van Oudheusden's ffl is currently more than 66 files, and they
are interrelated. If I want to use its gzip module, most Forth will not be able
to simply say /usr/ffl/gzip.fs because gzip.fs contains other include statements,
and (in general) they do *not* absolutely refer to /usr/ffl/xxx.

-marcel

mhx@iae.nl (Marcel Hendrix) wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> writes

> >You mean like a c include file that is in
> > /usr/include/X11
>
> Do you want to start a directory naming scheme convention for Forth?
>
> > What is the problem?
>
> E.g. the Dick van Oudheusden's ffl is currently more than 66 files,
> and they are interrelated. If I want to use its gzip module, most
> Forth will not be able to simply say /usr/ffl/gzip.fs because gzip.fs
> contains other include statements, and (in general) they do *not*
> absolutely refer to /usr/ffl/xxx.

I want to point out again that part of the problem here is interacting
with multiple incompatible operating systems.

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.

To use files from multiple virtual libraries is no problem once you
locate the libraries. and if you want to avoid that, you can put all the
libraries your application needs together into one VFS and you're done.
You can install every read-only file your application needs by copying
one file to someplace that's convenient for your Forth system. No
directory problems.

The only problems come when you have to share files with applications
written in other languages, and those applications assume a particular
host directory structure. Then you have to do it their way.

If we were to do this we'd need a reference implementation that
people could modify until it was time to converge on a common
practice. Last time I suggested this I listened to the various
objections about why it should not be done, and I dropped the idea. Is
it really not worth doing? Is there something that's more worth doing,
that I should do instead?

On Wed, 6 Aug 2008 19:19:22 +0200, mhx@iae.nl (Marcel Hendrix) wrote:

>Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: 3rd RfD: Directories
>> In the directory is a main program with
>
>> WANT NIP / library code
>> INCLUDE this.frt
>> INCLUDE that.frt
>
>> Never needed to get any more complicated than that.
>
>Of course there is. At some time a user of your Forth will want to
>use library code that is not written by you and comes in a separate
>directory or file (like the ffl).

And then there are application developers who keep their application
code in a totally different source tree.

I'm so glad we've used text macros for the last 12+ years.

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 5, 3:31 pm, jacko <jackokr...@gmail.com> wrote:
> In general I would prefer a URL syntax. But F" has advantages,
> although why you would need another word to get the absolute one when
> F" would place the absolute one on the stack is another matter.

Anytime there is a parsing word, sooner or later someone will want a
non-parsing version. Commonly that non-parsing version already exists
as a factor ... but if the name is not specified, then the name used
for the non-parsing factor will vary from one implementation to
another.

In article <20080806192245.36473e34.jethomas5@gmail.com>,
Jonah Thomas <jethomas5@gmail.com> wrote:
>mhx@iae.nl (Marcel Hendrix) wrote:
>> Albert van der Horst <albert@spenarnc.xs4all.nl> writes
>
>> >You mean like a c include file that is in
>> > /usr/include/X11
>>
>> Do you want to start a directory naming scheme convention for Forth?
>>
>> > What is the problem?
>>
>> E.g. the Dick van Oudheusden's ffl is currently more than 66 files,
>> and they are interrelated. If I want to use its gzip module, most
>> Forth will not be able to simply say /usr/ffl/gzip.fs because gzip.fs
>> contains other include statements, and (in general) they do *not*
>> absolutely refer to /usr/ffl/xxx.
>
>I want to point out again that part of the problem here is interacting
>with multiple incompatible operating systems.
>
>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.

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

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.

With a VFS you can have 80-char or 132-char lines. You can have CR or LF
or CRLF line endings. You can do literate programming. Your library will
still run on all the Forths that have the File wordset and they don't
even have to find files in host directories, except just the one file.

While blocks can completely solve the problem, still we have years of
experience which demonstrate that Forth users no longer accept blocks.
So we must do something else.

On Aug 6, 5:23*pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> And then there are application developers who keep their application
> code in a totally different source tree.
>
> I'm so glad we've used text macros for the last 12+ years.
>
I view a source tree as a project's workspace. I usually use CD to
point to the workspace and off I go. Often if you INCLUDE from a
Windows file-open dialog, the workspace will automatically be pointed
to. It would be nice if the host Forth would remember where it was
last pointing when I closed it. But basically, CD does what I need and
I rely on file words to treat filenames as being relative to the
workspace.

A separate problem is how to better support 3rd party libraries. There
was a long discussion here about Python's library support. That's what
we're trying to get at here. Are text macros good enough for that?

-Brad

On 7 Aug, 20:44, Jonah Thomas <jethom...@gmail.com> wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>
> > Jonah Thomas *<jethom...@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.

Some how the page breaks get in the way?

> With a VFS you can have 80-char or 132-char lines. You can have CR or LF
> or CRLF line endings. You can do literate programming. Your library will
> still run on all the Forths that have the File wordset and they don't
> even have to find files in host directories, except just the one file.

A block VFS anyone? File as indirect cluster list of blocks! Even
could give them names too...
A useful reference implementation could come in handy.

> While blocks can completely solve the problem, still we have years of
> experience which demonstrate that Forth users no longer accept blocks.
> So we must do something else.

yes could possibly mount all file root onto the block file system, and
translate all files into block addresses (double block addresses)

cheers
jacko

On Aug 6, 8:23 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Wed, 6 Aug 2008 19:19:22 +0200, m...@iae.nl (Marcel Hendrix) wrote:
> >Albert van der Horst <alb...@spenarnc.xs4all.nl> writes Re: 3rd RfD: Directories
> >> In the directory is a main program with
>
> >> WANT NIP / library code
> >> INCLUDE this.frt
> >> INCLUDE that.frt
>
> >> Never needed to get any more complicated than that.
>
> >Of course there is. At some time a user of your Forth will want to
> >use library code that is not written by you and comes in a separate
> >directory or file (like the ffl).
>
> And then there are application developers who keep their application
> code in a totally different source tree.
>
> I'm so glad we've used text macros for the last 12+ years.
>
> Stephen
>
> --
> Stephen Pelc, stephen...@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

Stephen,

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

Brian

On Thu, 7 Aug 2008 14:11:29 -0700 (PDT), Brad Eckert
<nospaambrad1@tinyboot.com> wrote:

>A separate problem is how to better support 3rd party libraries. There
>was a long discussion here about Python's library support. That's what
>we're trying to get at here. Are text macros good enough for that?

Yes, with some discipline. Define a macro for the root of the
library:
c" \buildkit.dev\software\ROM\Examples\USB" setmacro UsbDir

Assume that the build file for the project (say UsbDrive.bld)
refers to its files using that macro
include %UsbDir%\UsbHw2148.fth
include %UsbDir%\UsbConfig.fth
...

To compile that part of the application
include %UsbDir%\UsbDrive.bld

One of the nice things about text macros is that you can have more
than one macro in a file name, e.g. for different CPUs. Text macros
have application in many other areas, including internationalised
text handling, bulk mail (ugh), CGI and web scripting and so on.

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