headers
Dr Nick Maroudas | 2 Mar 2005 13:09
Picon
Favicon

Re: Re-connecting

On Wed, 2005-02-23 at 06:02, Terry Loveall wrote:
>
> On Tue, 22 Feb 2005 22:12:28 -0500 (EST)
> Mark Slicker <maslicke <at> oakland.edu> wrote:
> > (snip)
> > My critique of hierarchical file systems is that they put too much burden 
> > on the user, to give each file a name and place within the hierarchy. Also 
> > they are not very general or flexible. I think the system could be much 
> > more active in recording information about data objects, and the system 
> > could make this information available in a general way to applications.
> 
> > To which Terry (I presume it was Terry at this point) replied:
> Forth, with a nested vocabulary structure, can provide the basis for
> 'attribute typed' data storage. The basic managed 'physical' tree structure is
> provided by the vocabulary nesting.
> (snip)
> ... for communication oriented apps, e.g. web browser or email client, it
> would probably be worth the effort to provide a rigorously defined
> 'meta-object' format that essentially allows simple replication of creation
> time/date, modified time/date, size determination, owner ...
>
> But all of the above could be applied to conventional OS design. See some of
> the recent write-ups on beOS. With colorForth, the opportunity is at hand to
> try it again.
> Regards,
> Terry Loveall
>
> Nick here:
> How about start simple with the CF list, which is not large but 
> already gives me - and Google! - trouble, trying to find who said
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Slicker | 2 Mar 2005 20:10
Picon
Favicon

Re: Re-connecting

On Wed, 2 Mar 2005, Dr Nick Maroudas wrote:

> On Wed, 2005-02-23 at 06:02, Terry Loveall wrote:
>>
>> On Tue, 22 Feb 2005 22:12:28 -0500 (EST)
>> Mark Slicker <maslicke <at> oakland.edu> wrote:
>>> (snip)
>>> My critique of hierarchical file systems is that they put too much burden
>>> on the user, to give each file a name and place within the hierarchy. Also
>>> they are not very general or flexible. I think the system could be much
>>> more active in recording information about data objects, and the system
>>> could make this information available in a general way to applications.
>>
>>> To which Terry (I presume it was Terry at this point) replied:
>> Forth, with a nested vocabulary structure, can provide the basis for
>> 'attribute typed' data storage. The basic managed 'physical' tree structure is
>> provided by the vocabulary nesting.

Is there some online reference for the nested Forth vocabulary? I have 
some touble understanding the techniques described below, how the search 
is performed, ect.

>> Nick here:
>> How about start simple with the CF list, which is not large but
>> already gives me - and Google! - trouble, trying to find who said
>> what when & where?  I think Forth could easily do:
>>
>> 1. A "passive" program that reads the complete list (plus incoming
>>    messages) but only to store the lot as plain text documents in a
>> single folder, filed by date in an "archival stratum" - to be searched
(Continue reading)

Permalink | Reply | 3 comments |
headers
Terry Loveall | 2 Mar 2005 23:58
Favicon

Re: Re-connecting

Mark,

On Wed, 2 Mar 2005 14:10:37 -0500 (EST)
Mark Slicker <maslicke <at> oakland.edu> wrote:

<snip>
> >>> To which Terry (I presume it was Terry at this point) replied:
> >> Forth, with a nested vocabulary structure, can provide the basis for
> >> 'attribute typed' data storage. The basic managed 'physical' tree
> >structure is> provided by the vocabulary nesting.
> 
> Is there some online reference for the nested Forth vocabulary? I have 
> some touble understanding the techniques described below, how the search 
> is performed, ect.
> 
<snip>

The only online reference that I am aware of is the source for 'prok', a
"minimal 32bit direct threaded subroutine 1x study" that is part of the 
'5 Forths w/source'. URL:
http://www.modest-proposals.com/binary/4thish3.zip

Rather than have the forth word 'Forth' which holds the link to the latest
definition, you have 'Context' and 'Current'. 

'Context' points to the current named vocabulary which points to the latest
definition in that vocabulary. 'Find' uses 'Context' to search thru.

'Current' points to the current named vocabulary which points to the latest
definition being compiled to. New definitions are created and linked into
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luis | 3 Mar 2005 00:08
Picon

Forths

Hiya,

Found this link to a Forth 'OS', haven't seen it mentioned elsewhere, 
thought it might add a few ideas to the current discussion:

http://www.retroforth.org

http://ronware.org/reva.html

Cheers,

Luis.

--

-- 

Destiny is not a matter of chance, it is a matter of choice. It is not 
a thing to be waited for, it is a thing to be achieved.

     - William Jennings Bryan
Permalink | Reply | 2 comments |
headers
Dr Nick Maroudas | 3 Mar 2005 10:36
Picon
Favicon

connecting

On Wed, 2005-03-02 at 21:10, Mark Slicker wrote:

> On Wed, 2 Mar 2005, Dr Nick Maroudas wrote:
> >>> .... Terry ....(suggests that)...
> >> Forth, with a nested vocabulary structure, can provide the basis for
> >> 'attribute typed' data storage. The basic managed 'physical' tree structure is
> >> provided by the vocabulary nesting.
> 
> Then Mark asks: 
> Is there some online reference for the nested Forth vocabulary? I have 
> some trouble understanding the techniques described below, how the search 
> is performed, etc.
> 
> To which On Thu, 2005-03-03 at 00:58, Terry Loveall wrote: 
> Mark,
> The only online reference that I am aware of is the source for 'prok', a
> "minimal 32bit direct threaded subroutine 1x study" that is part of the 
> '5 Forths w/source'. URL:
> http://www.modest-proposals.com/binary/4thish3.zip
> 
> Rather than have the forth word 'Forth' which holds the link to the latest
> definition, you have 'Context' and 'Current'. 
> 
> 'Context' points to the current named vocabulary which points to the latest
> definition in that vocabulary. 'Find' uses 'Context' to search thru.
> 
> 'Current' points to the current named vocabulary which points to the latest
> definition being compiled to. New definitions are created and linked into
> 'Current'.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray St. Marie | 3 Mar 2005 11:50
Picon

Re: Forths

Luis, agreed.

Yeah, RetroForth is great, and Charles Childers, the main developer is
on version 8. It's spawnd several offshoots and runs native or in
several operating systems. It's remarkablely lean and clean and
implements many of the most current thoughts about minimalist "bare
metal" programing techniques.
http://www.retroforth.com

Worthy of any forthers dilligent investigation.

Samuel Falvo is designing an L4 port for Retro8.
http://www.falvotech.com/weblog/

On Wed, 2 Mar 2005 23:08:31 +0000, Luis <forth <at> anachreon.co.uk> wrote:
> Hiya,
> 
> Found this link to a Forth 'OS', haven't seen it mentioned elsewhere,
> thought it might add a few ideas to the current discussion:
> 
> http://www.retroforth.org
> 
> http://ronware.org/reva.html
> 
> Cheers,
> 
> Luis.
> 
> --
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray St. Marie | 3 Mar 2005 11:51
Picon

Re: Forths

doh that's www.retroforth.org yikes sorry 

On Thu, 3 Mar 2005 04:50:14 -0600, Ray St. Marie <ray.stmarie <at> gmail.com> wrote:
> Luis, agreed.
> 
> Yeah, RetroForth is great, and Charles Childers, the main developer is
> on version 8. It's spawnd several offshoots and runs native or in
> several operating systems. It's remarkablely lean and clean and
> implements many of the most current thoughts about minimalist "bare
> metal" programing techniques.
> http://www.retroforth.com
> 
> Worthy of any forthers dilligent investigation.
> 
> Samuel Falvo is designing an L4 port for Retro8.
> http://www.falvotech.com/weblog/
> 
> 
> On Wed, 2 Mar 2005 23:08:31 +0000, Luis <forth <at> anachreon.co.uk> wrote:
> > Hiya,
> >
> > Found this link to a Forth 'OS', haven't seen it mentioned elsewhere,
> > thought it might add a few ideas to the current discussion:
> >
> > http://www.retroforth.org
> >
> > http://ronware.org/reva.html
> >
> > Cheers,
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Slicker | 3 Mar 2005 20:12
Picon
Favicon

Re: connecting

On Thu, 3 Mar 2005, Dr Nick Maroudas wrote:

>>>> Now Nick here:
>>>> Mark,
>>          Terry (above) has given you his online reference, and
>> outlined the way that Forth's mechanism for compiling and searching a
>> dictionary (subdivided into specialized vocabularies if necessary)
>> might be inherently suitable for programming data retrieval.  My two
>> contributions stressed the primacy of temporal order and sketched
>> out what your socalled "active" program might actually do:  namely,
>> to compile a temporal pile of incoming documents into a small Forth
>> dictionary of linked words.  The pile is maintained whole & intact
>> (read only); if you like, you can plough thru it from start to finish
>> with a conventional linear search.  The "active" Forth program should
>> be faster, because it would search only those documents whose dates
>> are found in Forth definitions of the words that you want.
>>
>>  I do not know any online reference, because I learned Fig back in
>> the book age, but it was then common practice to search a compiled
>> dictionary for a name (use -FIND & ID.) to SCAN a compiled definition
>> into its component words, and thus to extract a specific WORDLINK.
>> Now that CF has done away with working on compiled object code
>> ("Source is all there is") it ought to be even easier.  All you have
>> to do :) is to write a program that reads the incoming stream and
>> translates interesting words into blocks of source :)  Even translate
>> those CF blocks into ASCII to search with an ordinary word processor.

I have an idea, maybe it is related. Chuck has talked about FML and a new 
type word that is executed at display time. So FML is essentially 
colorForth source. The email header and body could be parsed and stored as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jecel Assumpcao Jr | 3 Mar 2005 15:40
Favicon
Gravatar

objects (was: Re-connecting)

Frédéric DUBOIS wrote on Thu, 3 Mar 2005 13:25:50 +0100
> I have a question for you CF coders somewhat related to the current
> discussion. If I've looked towards vocabularies and OO, this is because I'm
> a bit in trouble with how to name things when an applications gets a bit
> "wide". For instance, if you have many different data structures and all of
> them have a field where you store the human-readable name of an object, you
> would like to have the word NAME for fetching this field but you cannot
> because it can be at different locations in each data structure, so you have
> to name ITF-NAME for the structure that describes an Interface,
> COMPUTER-NAME for computers, etc. One nice solution would that you manage
> things so that they are at the same location but it would incur some
> penality elsewhere.

I designed an object oriented Color Forth in 2001 and it was implemented
as you suggested. The most cost effective memory chips I could find were
a 512KB Flash memory for permanent storage and an 8MB SDRAM for the main
memory. Even with compression in the Flash, it is obvious that there is
main memory to spare in this machine.

So each kind (there were no classes) of object had associated with it a
large "code vector" that began with a table holding a two word entry for
every word in the vocabulary. Each word holds three MISC instructions,
so that is enough for most definitions while longer ones can have a jump
to the rest of the code.

The memory was addressed by two 16 bit words: the object ID and the
offset within the object. So to "send a message" to an object you just
load its ID (either on top of the stack or in a special SELF register)
into SELF (top 16 bits of the address) and the message index times 2
into PC (bottom 16 bits). The word NAME, for example, might be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Slicker | 5 Mar 2005 20:01
Picon
Favicon

Re: Re-connecting

On Tue, 22 Feb 2005, Terry Loveall wrote:
>
> But all of the above could be applied to conventional OS design. See some of
> the recent write-ups on beOS. With colorForth, the opportunity is at hand to
> try it again.

Speaking of which, I found "Practical File System Design"[1] on the web, 
which focuses on the Be file system. I found this to be very good 
reference overall.

[1] http://www.nobius.org/~dbg/practical-file-system-design.pdf
Permalink | Reply | 0 comments |

Gmane