Re: [colorforth] Test 5 am i getting thru

[John Drake <jmdrake_98@xxxxxxxxx>]

--- Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx> wrote:

> Not to get drawn into a block vs file argument
> but to clarify;

No argument here. :)

> Most of the file source based Forth that I have
> worked
> with don't have files in one place, although they
> might be
> in subdirectories of one directory.  But things like
> win32forth
> come with source in directory trees and programmers,
> sloppy
> or not, organize their code in further directory
> trees.
> 
> So in one case you are searching a linear section
> memory
> and in the other case you are searching files,
> opening and
> closing files, opening and closing and navigating
> directories
> and making assumptions about things like extension
> types.  And
> the directories are an abstraction that take control
> of the
> physical location of the abstract file away from the
> programmer.

I see your point.  Perhaps I got a false impression
from what you said in your first post because of the
talk of "gigabytes" of hard disk space.  Yes, source
files may be in different sub directories under a
tree.  And yes, searching this way is probably much
slower than the ColorForth way.  But when I search
the "entire hard disk" (unfortunately I have to do
that sometimes to help some other user find some 
errant Word document), that sometimes means leaving
the computer for (hours?) going to get pizza and
coming back.  That doesn't happen when I search
a single directory tree for some data in some
Forth files.  I get results in a second.
 
> A single file, or a single directory could be spread
> out
> with sectors scattered all over an entire disk.  The
> file
> abstraction hides this.  In contrast to searching a
> short
> section of linear memory files means trees of
> directories,
> files, and sectors which may be spread out over an
> entire
> hard disk, or more.

True.  Which is why defragmentation is important.  
Still, searching a 1K file that's spread over a
40 GB hard disk is quite different from linearly
searching the entire harddisk.  I'm sure, now,
that's not what you meant.  I just got a false
impression.
 
> But it rides on a file system that fools some users
> into
> thinking that directory trees are in one physical
> place, like
> a continuous group of blocks in memory.  

Some users maybe, but that's not the point I was
making.  It takes significantly longer to search
all of C:\ than it does to search C:\ForthFiles.
And I was looking at the context of the question
"is it possible to build something like this
for Win32Forth".  From that perspective, yes it
is possible, even if the solution is riding on
top of an "ugly" filesystem.  For example, I have
a 30 GB harddisk.  Using TPForth's facility I 
typically get search results back in about a
second.  I haven't defragged in a while so
files and directories could be scattered
"all over" my 30 GB harddisk.  Of course what
the search DOESN'T tell me is what is "definition",
what is "usage" and what is "comment".
The ColorForth solution sounds much better
in these regards.  But things aren't so slow
that I'm sitting around twiddling my fingers
waiting for TPForth to plod through the entire
30 gigabytes.

> It really
> isn't
> as simple as searching one linear section of memory,
> a
> search invovles disk access, building and navigating
> directory trees, opening and closing files, using
> file
> allocation tables, and dealing with data that might
> well
> be spread out over an entire hard disk.  Putting
> files
> in one 'place' from the abstracted view does not
> mean
> that you are not having to deal with Forth code
> spread
> out over an entire hard disk. Fragmentation happens
> at a level below the abstraction where a file is
> "one place" and any actual disk search will be below
> the user illusion that one dir or one file is one
> physical place in memory.  The file system may have
> to deal with a single file being spread out over
> an entire disk.

I'm sure ColorForth search facilities are more 
efficient and that wasn't my argument.  
 
> > I agree with all of your other points.  Because
> > CF is pre-parsed it can take advantage of it's
> > "knowledge" of the source code even when
> searching.
> > Nice.
> 
> In his fireside chat Chuck mentioned some feature
> that
> he would like to add to the editor that would
> require
> that it call the compiler between keystrokes to give
> the
> editor even more knowledge of what the compiler is
> going
> to do with the source.  I don't remember what editor
> feature
> he mentioned in that context.
> 
> Best Wishes

Well, sounds interesting.  Looking forward to that
new feature when it comes out.

Regards,

John M. Drake


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com