Null and More

[Doug]

Recently I had an interesting and frustrating experience. In the program I have been continuously working on for three decades a couple of odd things happened.

There is little doubt that SuperCard is, at its heart, a database. Lines can be thought of as records, and items as fields, and windows as tables. The Find command can quickly locate any record

With the current setup, a window with a single background with a single field becomes the table and is named by the dataType stored therein. Setting lineDel and itemDel to ASCII's database characters {FS (ASCII 28), aka File Separator; GS (ASCII 29), aka Group Separator; RS (ASCII 30), aka Record Separator; and US (ASCII 31) aka Unit Separator} allows virtually all text characters to be stored in any field of any record. I define the first field of a record as the record's ID which is unique to the record. The Find command can quickly locate any record using its ID.

This method produces dramatically smaller programs as the overhead of a card per record does not exist.

I limit the the data in the bg fld to 2^20 characters and 2^14 records. When either limit is reached a new card is created.

Building a record is just a matter of recording data according to the dataType's field list which is stored as a userProperty named uFields. No need to type the fields as Supercard stores all numbers as text anyway.

When building the record each field is appended by an itemDel (aka field delimiter). Of course, the last field will automatically be appended with a lineDel (aka record delimiter), so it doesn't need an itemDel. To determine if a record is valid, I do two things: determine that the DataID is unique and that the number of fields matched the number of lines in the field list.

Of course, empty fields can exist. Oops! If the last field is empty, then the count of fields will not equal the number of fields.

Solution: Ensure that the last field always has something in it, but that defeats the empty field idea. However, if a null character is placed in the last field, it will not be empty. The caveat is that when reading the field one will have to replace the null with empty.

Hope the readers follow what I am trying to explain.

[David Coggeshall]

What are the

 "odd things that happened."  ?

David Coggeshall

San Francisco Communications

IU RedLab-iSite Practice Leader

415 387-8760

--
You received this message because you are subscribed to the Google Groups "SuperCard Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to supercard-tal...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/supercard-talk/48100da6-23c9-48d4-9ecb-bace8cc5f794n%40googlegroups.com.

[Doug]

Great question.

First odd thing was that when checking the validity of a record, the number of fields was wrong. I explained how to fix that in my very long submission to this list.

Null is a thing that is easily misunderstood, somewhat like the old 100 yard fence with a post every 10 yards not having 10 posts, but 11. Null means nothing but nothing is not 0 or empty. Tricky concepts, hence the "not defined" solution when dividing by nothing.

Second thing happened when importing masses of records from former versions of the program. In order to ensure stability of the program I inserted the recommended line for compacting given in the Language Guide. ("if the freeSize of this project > 2048 then compact."). I stuck a sysBeep command in there so I could monitor, while reading a book, how often this was happening. The computer beeped so often that it was a steady hum of beeps.

I am using Mojave with the APFS filing system on a MacPro 5,1 with upgraded CPU. APFS, unlike HFS+ leaves lots of empty space as it allocates disk memory blocks in a non-contiguous model. That may mean that Supercard's internal filing model sees extra space that it would not have on HFS+. To date, with my meagre capabilities, I have not been able to determine whether this is the problem, or merely a reality that comes along with the expanded bit (32 bit to 64 bit) system in Mac's OS system.

Good news, the program did not crash.

Thanks for the question. It tells me that somebody else out there is also still using SuperCard.