Re: [NTLK] Soup Clues

From: Andrei Chichak <newton_at_chichak.ca>
Date: Tue Jun 17 2008 - 02:32:57 EDT

It's been a while since I have cooked soup, but I can lend a hand.
Some of the details are bound to be wrong, but the concepts are there.

If you have never programmed in something like C or Pascal and have
never played with SQL, it's gonna be rough. Don't start with soup.
Start with hello world. Work your way up to more difficult apps. Get
familiar with the debugger toolkit and the command line methods for
dumping frames. Don't start with soup.

At 09:19 PM 6/16/2008, you wrote:

>I did a couple of quick-reads through some Newton developer docs, and I'm
>not sure I grasp the "filesystem" on the Newt.

First, don't think of it as a file system. It's more like an SQL
database (hopefully you have played with one of those).

The Newton "filesystem" is more like a big pot of Minestrone, it is a
big pot of soup that contains apps, settings, beep tones, pictures,
databases, all jumbled together. There is a structure to it, but it
is more like a huge C struct where you can paste in new junk anywhere
and of any type and it just sticks around, you don't have to write it
out to disk. Reboot and it's still there.

>If you write Newton code,
>could you please straighten me out:
> Union Soups are the top level of storage.

Have you ever used a Mac? When you put a floppy in the drive, the
floppy contains files that are stored on the desktop and the hard
drive of the Mac has files that are stored on the desktop. Inserting
the floppy makes a bunch of stuff from the floppy stored appear on
the desktop. A logical union of the two file stores.

On the Newton you have soups (much like an SQL table). They can
reside in the flash memory in the Newton or on cards. By forming a
union soup, you combine the two stores together. When you iterate
through the soup, the data shows up in the proper order independent
of where it is kept. You don't have to worry about where the data is
coming from after the union is formed.

New items can be stored on the cards or in the internal store.

It would probably be useful to start at slots and work to union soups
instead of the other way around...but since you asked.

> Union Soups have Soups.

A union soup is the union operation applied to two or more soups.

> Soups have Entries.

Like a spreadsheet has rows, a soup has entries.

> Entries are Frames that are persisted inside Soups.

A Newton app will use frames to haul information around. When you
want it to stay forever you make the frame into a soup entry.

> Entries are accessed in Soups with Indexes.

An index is a fast way of getting at data. Like an index key on an
SQL database. You will have an index, even if it is supplied by the
system. An index is a way of sorting your data. It can be ascending
or descending. You know your data and how it will be accessed, the
index helps.

If you were to add a address book entry, it would probably make sense
to put it in last name alphabetical order. In this case you just add
the frame to the soup and the soup knows about the name slot being
the index and takes care of the ordering for you.

> Frames have slots.

Frames are like structs in C, but better. Like a row in a SQL
database, but unlike a row each frame does not need to have the same
data elements (slots). A frame is a collection of slots. A slot is an
item of data.

If I had a frame that contained a Name and Address, you could make an
address book. Add a phone number slot to the frame and you could look
someone up by name and call them. Add a birthday slot and you could
look them up, phone them, and wish them a happy birthday. A
corporation probably wouldn't have a birthday slot.

> Slots contain any type of data.

A slot is like a variable in your favorite language, but it's type is
determined at run time. Like this; x := 1 , x is a slot that holds
an integer with the value 1. x := "fubar" - x now holds a string. A
slot can equally hold a function or a frame.

You don't have to keep the connection between slot names and slot
types between frames, but as you iterate through your frames doing
the same function to each slot called x, you had better be able to
handle the variations in the structure of the slots or you will be
getting one of those great cryptic error codes.

I hope this helps,

A

====================================================================
The NewtonTalk Mailing List - http://www.newtontalk.net/
The Official Newton FAQ - http://www.splorp.com/newton/faq/
The Newton Glossary - http://www.splorp.com/newton/glossary/
WikiWikiNewt - http://tools.unna.org/wikiwikinewt/
====================================================================
Received on Tue Jun 17 03:13:45 2008

This archive was generated by hypermail 2.1.8 : Tue Jun 17 2008 - 14:30:01 EDT