On Apr 10, 2:21 am, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> On Apr 9, 5:37 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> > On Apr 6, 6:34 pm, an...@[EMAIL PROTECTED]
(Anton Ertl)
> > wrote:
>
> > > Bruce McFarling <agil...@[EMAIL PROTECTED]
> writes:
> > > >SF" ..." returns a string anchored in the directory of the source
file
>
> > > That's certainly an approach that would avoid the whole prefix issue
> > > completely. Another advantage is that it would do the anchoring at
> > > the right place (in the file where the string sits, rather than in
the
> > > file where the string is used).
> > ...
> > > One disadvantage of F" (or SF") is that most Forth programmers seem
to
> > > prefer INCLUDE and REQUIRE over INCLUDED and REQUIRED, standards be
> > > damned.
> > Yes, exactly.
> > So please provide non-parsing versions of SF" WF" LF"
> > so that we would write ourselves
> > : s-include parse-name src-anchored included ;
> > : l-include parse-name lib-anchored included ;
> > and would be able to write
> > : w-include parse-name wrk-anchored included ;
> > S" win32/process.fth" lib-anchored included
> > it looks enough ugly to be... well... ahem... I want to say, it is the
> > same style that we have in the standard.
>
> Ok:
>
> ANCHORED ( ca1 u1 -- ca2 u2 )
> translate the relative file reference given the string at ( ca1 u1 )
> into an absolute file reference. If contained in a source file, the
> file is relative to the source file currently being interpreted. If
> given on the command line, the file is relative to an implementation
> dependent position in the file hierarchy.
>
> LIB-ANCHORED ( ca1 u1 -- ca2 u2 )
> translate the relative file reference given the string at ( ca1 u1 )
> into an absolute file reference to the first file in the library path
> that matches the file reference. If there is no matching file, an
> absolute file reference is returned that refers to the first directory
> in the library path.
>
That is, ANCHORED is relative to the file being loaded (and not the
project directory), LIB-ANCHORED is somewhere in the library path, and
no "anchored" means `pwd`-relative. Is my understanding correct?
I would like to have WRK-ANCHORED too, to make `pwd`-anchoring
explicit. Some systems may already have some built-in intellect, and
this sort of things is always difficult to hack-around.
Now, what about lifetime and releasing of the converted path strings?
If I store the address and length into a 2VARIABLE, will the filename
be available via that 2VARIABLE while the file loads?
2variable filename
: lib-include
parse-name lib-anchored filename 2@[EMAIL PROTECTED]
2>R 2DUP filename 2! included
2R> filename 2!
;
> In both cases, the relative file reference refers to a subdirectory
> within the file reference
Sorry, can you please re-phrase?
> by appending the character '/', with
> ANCHORED or LIB-ANCHORED providing any translation required by
> INCLUDED and/or REQUIRED.
Sorry, what translation you are talking about?
And as to '/' vs '\', IMO it would be good to allow both.
|
