Thousands of cards (Was RE: very strange rev behavior)
Jacque wrote: The recommended number of cards is around 5 thousand, give or take a few, depending on how many objects are on the cards. I've done okay with 10,000 in one project. I wouldn't go much more than that. The public recommendation is 5-6K. OK... time for a dumb question. What kind of application would have 5,000 or 10,000 cards? Is it because the application is using cards to hold records of data instead of using a database? Otherwise, I can't even imagine it. Also, wouldn't an application with a stack with this many cards be a huge memory hog? Aloha from Hawaii, Jim Bufalini ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Thousands of cards (Was RE: very strange rev behavior)
Jim Bufalini wrote: OK... time for a dumb question. What kind of application would have 5,000 or 10,000 cards? Is it because the application is using cards to hold records of data instead of using a database? Otherwise, I can't even imagine it. Also, wouldn't an application with a stack with this many cards be a huge memory hog? The problem is that you've been making software too long. :) If you've ever shipped a version 2.0 of something, you realize very clearly the traditional benefits of separating code, UI, and content, so you can enhance the UI without affecting the user's data. But HC made it very convenient to store data on cards, and out of the box provided no way to work with any database at all (SQLite hadn't even been invented yet). Bill Atkinson said more than once that HyperCard is not a database, but the convenience of using it as one encouraged people to do so. Memory wasn't an issue, because HC paged from disk. Remember, it was designed to work in early Macs, back when 2 GB of RAM was an unimaginable dream. Paging from disk meant only a limited number of cards were in memory at any given time (though the frequency of 5454 errors -- file corruption -- told the other half of the story, the inherent complexity and potential brittleness of paged systems for anyone who didn't make a religion of compacting regularly to rebuild the file). So flash forward: 20 years later, HC has been dead for more than a decade, Rev is growing, and there are a lot of legacy systems built in HC looking for a new home. But as you know, Rev loads the entire stack file into memory at once, which gives it a certain robustness and contributes to its excellent performance, but means that storing 20,000 cards in a stack just isn't practical. Dr. Raney was nothing if not pragmatic, so optimizing his structures to accommodate that many cards was not something he ever bothered to invest time in because it only encouraged people to things that would lead to other problems down the road (like making a v2.0 that enhances one's UI). So this means that while Rev's support for the HC file format makes it a good choice for porting legacy HC stacks, in many cases those stacks need to be restructured to make good use of it. This often means very fundamental changes, like moving the data out of the UI, which are unintuitive for someone coming from a system where that wasn't needed. I believe there are so many benefits in separating code, UI, and content that it's well worth the effort, and the clients for whom I've ported large HC stacks have been pleased with the results Rev offers. But I also recognize it's a bit of a head-scratcher when you do it for the first time. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Thousands of cards (Was RE: very strange rev behavior)
Richard Gaskin wrote: The problem is that you've been making software too long. :) If you've ever shipped a version 2.0 of something, you realize very clearly the traditional benefits of separating code, UI, and content, so you can enhance the UI without affecting the user's data. But HC made it very convenient to store data on cards, and out of the box provided no way to work with any database at all (SQLite hadn't even been invented yet). Bill Atkinson said more than once that HyperCard is not a database, but the convenience of using it as one encouraged people to do so. Memory wasn't an issue, because HC paged from disk. Remember, it was designed to work in early Macs, back when 2 GB of RAM was an unimaginable dream. Paging from disk meant only a limited number of cards were in memory at any given time (though the frequency of 5454 errors -- file corruption -- told the other half of the story, the inherent complexity and potential brittleness of paged systems for anyone who didn't make a religion of compacting regularly to rebuild the file). So flash forward: 20 years later, HC has been dead for more than a decade, Rev is growing, and there are a lot of legacy systems built in HC looking for a new home. But as you know, Rev loads the entire stack file into memory at once, which gives it a certain robustness and contributes to its excellent performance, but means that storing 20,000 cards in a stack just isn't practical. Dr. Raney was nothing if not pragmatic, so optimizing his structures to accommodate that many cards was not something he ever bothered to invest time in because it only encouraged people to things that would lead to other problems down the road (like making a v2.0 that enhances one's UI). So this means that while Rev's support for the HC file format makes it a good choice for porting legacy HC stacks, in many cases those stacks need to be restructured to make good use of it. This often means very fundamental changes, like moving the data out of the UI, which are unintuitive for someone coming from a system where that wasn't needed. I believe there are so many benefits in separating code, UI, and content that it's well worth the effort, and the clients for whom I've ported large HC stacks have been pleased with the results Rev offers. But I also recognize it's a bit of a head-scratcher when you do it for the first time. Alright, this answers my question and why I said, I couldn't imagine it. Yes, going back more like 26 years ago, SQLite wasn't invented but I was using DB and Rev (only that Rev was called Revelation which was a just released development language/environment for the original IBM PC by a brand new company called Cosmos and based on PICK, which had been around since the '60s). When I first heard of Revelation by Cosmos, I wasn't sure if it was a programming language or a cult. ;-) But, from almost the very beginning of my developing applications for others, code was script in libraries (very similar to our Rev's script including chunks, no variable typing, amazingly similar built-in commands and functions, English like, optional variable declarations, and it too was script level compilation, so you ran and programmed at the same time), which was separate from the UI, which was just that, and which in turn was separate from data, which was in a PICK database. There was some mixing of script and database in that a database could have a field which was actually script. By this I mean, you could have a field called FirstName which was a script that returned word 1 of an actual field called Name that contained a full name, or visa versa, a field called FullName that was a script that returned the concatenation of FirstName space MiddleName space LastName or that did a calculation, etc. There was some mixing of script and the UI, in that there were hooks (there was no OS messaging in that day) that were triggered say entering an entry field or exiting that allowed calling say an IConv or OConv (In Conversion, Out Conversion) which would be a function in one of your libraries that say checked user input or changed the UI based on user input or opening or closing a window, etc. And, in that day, you did have to drop down to C occasionally to modify the engine (which they allowed) or write the equivalent of what we call externals. It is why, for me, finding Revolution was like returning home after over a decade of having left Revelation and working with traditional languages (with hours of re-typing variables) and SQL. I knew the Rev language and the concepts of chunks and scripting before writing my first line of Rev code. But... the lack of database was a big drawback and the idea of using text files or cards (which I considered the UI) to hold data was arcane to me and just wrong and so, while I did use text files, I never could bring myself to use cards to hold data and I didn't use Rev for
RE: Thousands of cards (Was RE: very strange rev behavior)
Hi Richard, But HC made it very convenient to store data on cards, and out of the box provided no way to work with any database at all (SQLite hadn't even been invented yet). Bill Atkinson said more than once that HyperCard is not a database, but the convenience of using it as one encouraged people to do so. The sample stacks with HC sort of encouraged this though - you had a pretty usable PIM there as I recall. But along with what you say about SQLite, back then I don't think it was completely conceivable that one would have thousands of contacts in a personal file. I believe there are so many benefits in separating code, UI, and content that it's well worth the effort, and the clients for whom I've ported large HC stacks have been pleased with the results Rev offers. It sure would be nice if someone wrote an updated Runrev: Best Practices book, or many somebodies wrote chapters of one. Best regards, Lynn Fredricks President Proactive International, LLC - Because it is about who you know.(tm) http://www.proactive-intl.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
very strange rev behavior
For some reason, Rev has started taking 50 times as long to open as it used to, and the menus are so slow as to be completely unusable. I thought the program was frozen, just a spinning beach ball for minutes on end as it started up, then slowly it went through the process of opening and finally opened. But choosing any menu item just creates a spinning beach ball that lasts for several minutes. Clicking on the Close button in a window also produces a good minute of beach ball spinning. I downloaded a new copy of Rev and installed it, same problem. It seems to only be Rev that is affected by this, though it seems to be REV vs OS interface issue. I thought perhaps some Preferences file was trashed but replaced those I could find. I'm running Enterprise version 4.0 under Mac OS X Server Verision 10.5.8, on a Power Mac 2.66Gz Quad Core Intel Xeon with 8Gb of memory. I S miss Rev, I hadn't realized how important it is to my daily workflow! Rand Valentine University of Wisconsin-Madison ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: very strange rev behavior
On Fri, Mar 5, 2010 at 12:51 PM, rand valentine jrval...@wisc.edu wrote: For some reason, Rev has started taking 50 times as long to open as it used to, and the menus are so slow as to be completely unusable. I thought the program was frozen, just a spinning beach ball for minutes on end as it started up, then slowly it went through the process of opening and finally opened. But choosing any menu item just creates a spinning beach ball that lasts for several minutes. Clicking on the Close button in a window also produces a good minute of beach ball spinning. I downloaded a new copy of Rev and installed it, same problem. It seems to only be Rev that is affected by this, though it seems to be REV vs OS interface issue. I thought perhaps some Preferences file was trashed but replaced those I could find. I'm running Enterprise version 4.0 under Mac OS X Server Verision 10.5.8, on a Power Mac 2.66Gz Quad Core Intel Xeon with 8Gb of memory. I S miss Rev, I hadn't realized how important it is to my daily workflow! When Rev starts up, it connects to the Rev servers to check for updates and to show the data in the Start Center. Do you have it showing the Start Center on startup? If so, try turing that off and trying in case, just in case your firewall is blocking some connection. Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: very strange rev behavior
rand valentine wrote: For some reason, Rev has started taking 50 times as long to open as it used to, and the menus are so slow as to be completely unusable. I thought the program was frozen, just a spinning beach ball for minutes on end as it started up, then slowly it went through the process of opening and finally opened. But choosing any menu item just creates a spinning beach ball that lasts for several minutes. Clicking on the Close button in a window also produces a good minute of beach ball spinning. That sounds like the symptoms of opening a stack with many thousands of cards. Are you working on something like that? If you are launching Rev by double-clicking a large stack, then that would account for the startup delay. The menus stall out because on each mousedown in the menu, Rev has to rebuild it's groups list and some other menu items. It has to look at each card briefly to do the groups. The recommended number of cards is around 5 thousand, give or take a few, depending on how many objects are on the cards. I've done okay with 10,000 in one project. I wouldn't go much more than that. The public recommendation is 5-6K. The MetaCard IDE is more responsive with large stacks because it does very little behind the scenes. You could try switching to that in a pinch, but MC lacks a lot of the niceties you may depend on. It's pretty much raw engine. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
