I seem to have cracked this one now, by brute force. But the solution really
shows how much this must be the wrong tool for the job - unless there is a
much better way, which there probably is, and I'd love to hear about. And
also would be interested to hear how one was supposed to find it!
On 1/15/08 10:47 PM, Peter Alcibiades [EMAIL PROTECTED]
wrote:
Its a childishly simple problem. There is a file with 15k records. Tab
delimited. Each record has five fields and is of the form:
number eg 123
description eg Pen, Pencil
price eg 2.00
category eg AA, AB...
date eg
. But mainly i can work everythiing from
within a single tool. Keeps my world together.
-Original Message-
From: Peter Alcibiades [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/16/2008 1:37 AM
Subject: Many Cards Versus One Card and a List Field
I seem
Peter, this is untested, but might work reasonably quickly:
on getReport
put file dataFile into tData
set the itemdelimiter to /
repeat for each line L in tData
put word 4 of L line (item 2 of word 5 of L) of the
monthnames into tKey
add word 3 of L to tTotals[tKey]
Sorry, I forgot that Rev won't allow an item of a word, so we have to
factor the month out to another function:
This is tested on some made up data, 20,000 records
function getReport pData
repeat for each line L in pData
put word 4 of L getMonth(word 5 of L) into tKey
add word
--- Peter Alcibiades [EMAIL PROTECTED]
wrote:
[snip]
Then I will do printing by going to full screen and
doing Print Desktop from
the shell. What a horrible kluge! Awk and a text
editor for printing has to
be better than this. It would be embarassing if the
people who will use it
At 6:06 PM -0800 1/15/2008, Richard Gaskin wrote:
J. Downs wrote:
What made it possible to use HC that way was its hint bits, a
system for indexing field contents which is not only proprietary
but patented as well. Hint bits made it ultra-fast for obtaining
data across the otherwise-complex
Ya, this hint bits just sounds like a clever indexing/pointing
system... hard to defend any specific case of this as categorically
owned. This is at base in any fast database incarnation... or it
wouldn't be fast. You have to play access tricks (stack the deck) or
search algorithms will
Richard,
Obviously others have commented on the patent. If the patent hasn't
expired, it is about to, and the technique will be described in the
patent application.
Regardless, there is nothing that stops anyone from circumventing a
patent by reverse-engineering it, which is generally the
Mikey wrote:
Richard,
Obviously others have commented on the patent. If the patent hasn't
expired, it is about to, and the technique will be described in the
patent application.
Regardless, there is nothing that stops anyone from circumventing a
patent by reverse-engineering it, which is
On 16 Jan 2008, at 21:36, Mikey wrote:
Regardless, there is nothing that stops anyone from circumventing a
patent by reverse-engineering it, which is generally the favored
technique.
This is just false. patents are documented, because that is the only
way to enforce them in court.
Maybe I don't understand the question (does happen!) but isn't the answer
something like this.
1) Once data storage gets serious, more than a few thousand records, Rev
alone is not what to do it in. If you want to do the rest of the app in Rev,
you have to add a real database. This means
@lists.runrev.com
Sent: 1/14/2008 6:00 PM
Subject: Re: Many Cards Versus One Card and a List Field
Hello everyone,
Having started this thread, perhaps I can throw in that the question
for me has always been a practical one. If I need to work with and
analyze the data in many records
Does rev offer a table object?
-Original Message-
From: Peter Alcibiades [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/15/2008 12:11 AM
Subject: Many Cards Versus One Card and a List Field
Maybe I don't understand the question (does happen
Does rev offer a table object?
Yes, theoretically, you can drag and drop table fields onto a card, but the
general opinion here seems to have been to stay away from them. Even could
you do it, you're still storing 10s of thousands of records in a text file,
its just a rather inaccessible one.
Lee Reetz wrote:
Does rev offer a table object?
-Original Message-
From: Peter Alcibiades [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/15/2008 12:11 AM
Subject: Many Cards Versus One Card and a List Field
Maybe I don't understand the question (does
Peter, did you look into using arrays and customPropertySets?
In (somewhat) similar circumstances, I've found that these can deal
with largish data sets and provide pretty good performance.
I have 18000+ records in one of my data sets, each record with
between 3 and 30 fields. I save the data
I don't currently have a project where I'm trying to store thousands of
records. To some, maybe that will invalidate my views on the subject.
I just read what Sarah had written below and I was frankly a bit
peeved. I've spent a considerable amount of time learning how to use
stacks as documents
Peter Alcibiades wrote:
Maybe I don't understand the question (does happen!) but isn't the answer
something like this.
1) Once data storage gets serious, more than a few thousand records, Rev
alone is not what to do it in. If you want to do the rest of the app in Rev,
you have to add a
Russell, please don't take this as unfriendly or agressive, and being
quite good at peevish myself, I can understand your point of view.
But if you don't currently need to deal with thousands of records,
then your current level of expertise with using cards will serve you
well, and since the
Russell,
I'm kind of late replying to this comment (re your dismay).
I understand your frustration, and I agree with you. RR has lots of
warts, and this is one of them. I have not been able to use it as my
primary development tool because I develop mainly database-centric
applications, and RR's
Hey Mikey -
Good to see you here.
Even though Bill Atkinson himself said that HyperCard isn't a database,
I can understand the desire of those who've used it as one to use Rev
similarly.
What made it possible to use HC that way was its hint bits, a system
for indexing field contents which
Wrong assumptions. Rev works completely in RAM after loading. Save to
disk is only done under command or script control.
What you're seeing as disk activity is probably virtual memory in
your OS. Rev doesn't touch that.
Most of us have given up the card data metaphor for serious projects.
On Jan 15, 2008, at 1:16 PM, Richard Gaskin wrote:
In this thread we've outlined three distinct ways of managing data
with Rev:
1. 3,000 records: cards work okay
2. 50,000 records: delimited text stored in custom properties
3. 50,000 records: true database engine (SQlite, MySQL, etc.)
What made it possible to use HC that way was its hint bits, a
system for indexing field contents which is not only proprietary
but patented as well. Hint bits made it ultra-fast for obtaining
data across the otherwise-complex structures that make up cards and
fields.
Certainly any such
I believe patents are limited to 14 years, but something like this is
probably more of a copyright issue; copyrights are good for 28 years
and renewable for two additional 28 year periods for a total of 84
years. Of course, I've been wrong before. (sheepish grin)
Joe Wilkins
On Jan 15,
J. Downs wrote:
What made it possible to use HC that way was its hint bits, a
system for indexing field contents which is not only proprietary
but patented as well. Hint bits made it ultra-fast for obtaining
data across the otherwise-complex structures that make up cards and
fields.
Hello Randall,
It's been a while. I could dig it up, but it would be embarrassing
(although the program is still being used). My scripting is like
Johnny Cash's guitar playing was: primitive.
Here's the gist of it, although I'm sure (actually certain) that
there's nothing here that
On Jan 16, 2008 10:06 AM, Richard Gaskin [EMAIL PROTECTED] wrote:
Cool. Let us know what Apples says when you write to ask them for the
code. ;)
I had to smile two days ago, I was on the Apple site registering some
software and noticed that HyperCard is listed there; so I guess Apple think
Cool. Let us know what Apples says when you write to ask them for
the code. ;)
lol. i'd reverse engineer it for you, but haven't the foggiest where
to begin with such an enterprise. :P
j.
___
use-revolution mailing list
Richard Gaskin wrote:
J. Downs wrote:
What made it possible to use HC that way was its hint bits, a
system for indexing field contents which is not only proprietary but
patented as well. Hint bits made it ultra-fast for obtaining data
across the otherwise-complex structures that make up
Well, at least I'm the first to let me know I was wrong. Appears they
changed it in 1995 to 20 years as JD said earlier; and it had been
changed from 14 to 17 years sometime even earlier. You know about
old coots. (smile)
http://www.fda.gov/cder/about/smallbiz/patent_term.htm
Joe Wilkins
I have to admit to not having been able to make Rev work as a storage and
retrieval language and am getting close to giving up after a couple of weeks
hard trying. Its mostly the documentation probably. It must be possible
since people on the list are doing it, but there seems no way to find
Peter,
I'm not sure this will work for you, but it worked for me with HC. I
designed stacks that could be used for printing reports and then
stored data in those stacks when I needed to print new data; the
action stacks, used to acquire and change/revise new data would
pick up the data
I realize I'm kinda late to the party on this topic, but I just want to
express my dismay at finding out that using stacks as databases is
prohibitively slow. That just seems bassackwards.
A big part of why I started looking into HyperCard, SuperCard, and then
Revolution was because I finally got
Russell, how much data and how many cards do you envisage using?
There are many ways of storing data in Revolution, and good
performance is not necessaily hard to achieve.
Can you describe your project a bit?
Best,
Mark
On 14 Jan 2008, at 18:49, Russell Martin wrote:
I realize I'm kinda
On Jan 14, 2008, at 12:49 PM, Russell Martin wrote:
if I can't realistically store large amounts of data
in stacks (and get acceptable speed), then what is the point of
using a
stack based development tool?
Russell,
This is an excellent question. The relevancy of cards (or even stack-
Russell Martin wrote:
I realize I'm kinda late to the party on this topic, but I just want to
express my dismay at finding out that using stacks as databases is
prohibitively slow. That just seems bassackwards.
Some feel the opposite: binding the data to the UI makes one
representation of
Russell,
Jerry put it well.
With Rev you can have the best of both worlds:
1. You can build simple databases simply - using stacks and cards.
2. You can build large, fast databases - differently.
In either case you have the benefit of a graphic UI (the card).
What you have learned about keeping
Jerry,
On many of your points I agree. It is possible (though definitely
not automatic) to store data external to a stack (in a text file) and
use cards as UI modes; different ways of viewing and interacting with
the raw (external) data. When HyperCard was born, data was static or
Randall,
Sounds like a good project, and you have a solid understanding of the
problem. How about YOU being first to solve it?
Seriously,
JD
On Jan 14, 2008, at 3:21 PM, Randall Lee Reetz wrote:
Jerry,
On many of your points I agree. It is possible (though definitely
not automatic)
Randall Lee Reetz wrote:
Who will do it first?
Looks like the field's wide open for you.
--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
Me and you?
-Original Message-
From: Richard Gaskin [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/14/2008 2:29 PM
Subject: Re: Many Cards Versus One Card and a List Field
Randall Lee Reetz wrote:
Who will do it first?
Looks like the field's wide
Randall Lee Reetz wrote:
Richard wrote:
Randall Lee Reetz wrote:
Who will do it first?
Looks like the field's wide open for you.
Me and you?
While I'm flattered at the suggestion and would enjoy breaking new
ground, the areas in which I'm pursuing innovation are far smaller in
scope,
Even as a reality freak, there are times when i really hate reality. Are you
in a tent?
-Original Message-
From: Richard Gaskin [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/14/2008 4:05 PM
Subject: Re: Many Cards Versus One Card and a List Field
Lee Reetz [EMAIL PROTECTED]
To: How to use Revolution use-revolution@lists.runrev.com
Sent: 1/14/2008 4:37 PM
Subject: RE: Many Cards Versus One Card and a List Field
Even as a reality freak, there are times when i really hate reality. Are you
in a tent?
-Original Message-
From: Richard
Hello everyone,
Having started this thread, perhaps I can throw in that the question
for me has always been a practical one. If I need to work with and
analyze the data in many records and the characteristics of those
subsets most of the time (How many in total?, How many are red?, What
Randall Lee Reetz wrote:
Wow, that message was a little short and a lot weird.
No problem. Many of my posts are long and weird. ;)
What i meant was that i think you are correct, that
a working prototype is in order, and that it is very
hard to fit dreams (no matter how rooted in reality)
Thank you for your responses Sarah, Mark, Paul, and Richard,
As always, thoughtful and insightful. You've confirmed what I've
learned with my experience with Revolution, comparing the one-card-per-
record model with the one-card-as-a-display model, so now I'm
convinced that I can abandon
Hello everyone,
I'm interested in your thoughts on a design question. Most of my
stacks are database-like, and it is as important to be able to access
many records resulting from a search as it is to view the individual
records one at a time. So my question is, given the speed of
I'm interested in your thoughts on a design question. Most of my
stacks are database-like, and it is as important to be able to access
many records resulting from a search as it is to view the individual
records one at a time. So my question is, given the speed of
Revolution as compared to
Hi Gregory,
Sarah is right. Keeping data on individual cards makes Revolution
extremely slow. A long time ago, I used the bible to create a
database of approximately 32000 records for a test, i.e. 32000 cards.
Running the test on a 350Mhz iMac, a search for a string could take
an hour if
Gregory,
There are three big benefits from using the one-card approach with Rev.
The programs will run faster.
The stacks will be smaller.
It will be easier to build menus.
BTW, I have found repeat for each line whichLine works faster than
lineOffset and more reliable than filter with/without.
Gregory Lypny wrote:
So my question is, given the speed of Revolution as compared to good
old Hypercard, is there any big advantage to storing data from each
record on individual cards as opposed to maintaining, say, a
tab-delimited list field that populates a single card with the
record's data
54 matches
Mail list logo
