|
|
 Up |
|
|
  |
Author: Marcel HendrixMarcel Hendrix Date: Aug 6, 2008 10:19
Albert van der Horst 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).
-marcel
|
| |
|
| | 22 Comments |
|
|
Author: Albert van der HorstAlbert van der Horst Date: Aug 6, 2008 13:08
>Albert van der Horst 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
|
| Show full article (0.95Kb) |
|
| | 16 Comments |
|
|
Author: Marcel HendrixMarcel Hendrix Date: Aug 6, 2008 14:42
Albert van der Horst writes Re: 3rd RfD: Directories>>Albert van der Horst 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?
|
| Show full article (1.21Kb) |
| no comments |
|
|
Author: Jonah ThomasJonah Thomas Date: Aug 6, 2008 16:22
mhx@iae.nl (Marcel Hendrix) wrote:
> Albert van der Horst 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.
|
| Show full article (1.89Kb) |
| no comments |
|
|
Author: Stephen PelcStephen Pelc Date: Aug 6, 2008 17:23
On Wed, 6 Aug 2008 19:19:22 +0200, mhx@iae.nl (Marcel Hendrix) wrote:
>Albert van der Horst 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
|
| Show full article (0.94Kb) |
| no comments |
|
|
Author: Albert van der HorstAlbert van der Horst Date: Aug 7, 2008 11:21
In article <20080806192245.36473e34.jethomas5@ gmail.com>,
Jonah Thomas gmail.com> wrote:>mhx@iae.nl (Marcel Hendrix) wrote:
>> Albert van der Horst 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. ...
|
| Show full article (1.39Kb) |
| no comments |
|
|
Author: Jonah ThomasJonah Thomas Date: Aug 7, 2008 12:44
Albert van der Horst wrote:> Jonah Thomas 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.
|
| Show full article (1.09Kb) |
| no comments |
|
|
Author: Brad EckertBrad Eckert Date: Aug 7, 2008 14:11
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
|
| |
| no comments |
|
|
Author: jackojacko Date: Aug 7, 2008 15:23
On 7 Aug, 20:44, Jonah Thomas gmail.com> wrote:> Albert van der Horst wrote:
>>> Jonah Thomas 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.
|
| Show full article (1.54Kb) |
| no comments |
|
|
|
|
|
Author: brian.foxbrian.fox Date: Aug 7, 2008 18:48
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 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.
> ...
|
| Show full article (1.13Kb) |
| no comments |
|
|
|
|
