Re: Script Limits - clarify please (JR)
As the original poster of that message, I too am pleased at the clarification that has ensued. Left to our own speculation, we can only entertain wild (and unfounded) ideas about how things are progressing. These 'well crafted' responses have been very helpful to dispell rumors and 'myths'. You must understand the orientation from which we (the end user) must 'speculate' from. The only changes I have seen (real changes, not just promises) have been in RunRev's best interest...not mine. I have decided to have faith that the promises that I have been reading on this post (from Kevin, and others) are not merely 'damage control', but 'real' promises. Only time will tell now, and I wish you [RunRev] all the blessings you deserve...good luck! JR Let me join with the thanks for making a clear and exhaustive statement, Kevin. I am glad to hear that my fears were unfounded and the interests of this group are important to Rev. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Fri, 2003-08-08 at 14:12, jbv wrote: And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I'm not so interested in the content of the answer, but much more in knowing if any answer has been received... Yes I did, too - and no answer yet. But because I - as a romantic person - believe in the good of mankind, I am hopeful. Have a look at the Runrev site. First figures for license renewals are there, although nothing for Metacard users so far. The upgrade of the three-weeks old Express edition (from 2.0x to 2.1) costs 20 US$, the upgrade for the Studio edition from 2.0 to 2.1 50 US$. The new version Rev 2.1B2 (which is Metacard 2.5.1B2) contains minor changes - among them are an export snapshot command and a drawer command that opens another stack as a drawer attached right, bottom or left, and a lot of decorations changes. I tried the drawer command and find that to change the size of a stack to simulate a drawer and after that again collapse it would need only slightly more scripting and is more elegant. Regards, Wilhelm Sanke ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Mark Talluto wrote: You bring up a point I did not think of till now. Saving small snippets of data in a script is the only way to save encrypted data in a stack. Data in a custom property can be viewed. I know there are other ways to encrypt data, but this is a nice simple way. I just did a test with MC 2.5: I made a stack with one field, and put This is field data into it. Then I added a custom prop and put This is prop data into it. Then I put --this is script data into the stack script. I saved it, then did a Save As, set the password, and saved this copy again. I quit MC and opened both stack files in TexEdit (any app that lets you open binries will do). In the non-password-protected stack, all three text strings are readable. In the password-protected stack none of them are. It seems a change was introduced in the engine at some point that now provides complete protection for all three types of data storage. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On Thu, 2003-08-07 at 13:13, Klaus Major wrote: I still think the free StarterKit was the best thing ever. One could play with it, get used to the app and even build useful things :-) ...and 30 (contiguous?) days may be not enough, even with no script limits... 30 days is not enough for a significant market sector (students) to decide they can build a business around creating Rev built products to justify the licence fee. P.S. I confess i build a (not too) commercial CD-ROM with the starterkit and bought my first MC license with the salary for that :-) (Simple Image and video presentation, but what the egg...) My guess is that it took you longer than 3 months to learn, build test and release this product? Maybe that's what they are afraid of in scotland? ;-) Easy - I'm half Scottish :) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
Second, the problem with the MC licensing scheme is that it was too easy to abuse... Here, I fully understand RR's way. You build a chain of buttons never breaking the limit of the 10 script lines but despite that, I dont know anyone who would in their right mind want to use such an IDE. Also, to Scott's demise, allowing compilation of an executable is a nice feature for a demo but it's part of the problem with runaway licenses... Actually, this was an acceptable way to earn your wings and test the MC environment. Chaining 10-lines was not breaking any licenses AFAIK. I believe the reasoning was that any serious developer would pay rather than struggle all the time, but people who were not serious wouldn't pay anyway. Some post in this thread seem to confirm that this worked. (But then some complained that they can't truly evaluate the product with 10-line limit.) No many IDE's have this feature on the other hand! Also, note that other than optimizing the IDE to improve your workflow, I dont see why anyone would want to go through the pain of creating an IDE. Most RR and MC users create applications for their clients. None of them want their clients to develop more themselves! It was not about competing GUI as far as I know. MC allowed for alt GUIs (it is Rev that had this restriction). However, if not for the script limiting, one unscrupulous programmer could produce a standalone that gave full access to the engine in developer mode for anyone. Indeed not a desirable situation for anyone seriously interested in this product. This is why standalones have always been running in the demo mode so do speak. Full features of the engine were only available in the development (paid) environment. As a result, we had a severly limited or full environment but nothing in between. As Scott explained to me at some point, there were some markets that he left out for that reason. Now Rev is changing the equation by further restricting the 'limited' end, crippling capabilities for our products even further. My reading on that is that Rev is focusing more on people who work only within dev environment rather than producing standalones distributed to others. In other words, while MC was meant as a tool for professional developers, Rev is mostly after the hobbyst market. Following Robert's comments earlier, the removal of a feature or limiting a feature like dynamic scripting (the DO script), is IMOHO a terrible mistake and a SEVERE limit to the IDE's possibilities. Of which this one is almost unique among other IDEs. Since using 'do' one can relatively easily work around the 'set script to' restriction (performance issues aside), we can only expect further elimination of 'do' in standalones (do limit set to 0) in a near future. It would be a logical followup to fully close that loophole. This line of product development really scares me, particularly as it is a rather expensive product (I paid for full MC license plus renewal) comparing to either RB or CWP. I have my doubts about cutting off multiplatform features from cheaper licenses but I see this as Rev trying to maximize their income. I have no problems if the demo is restricted in terms of dynamic scripting. But the engine embedded when producing a standalone from a licensed environment could retain current limits. Since the limits are clearly kept as parameters, there must be ways to control them accordingly, including setting arbitrary values for specific projects (as I suggested). I had big and long-term plans for a number of MC-based projects, but the recent developments really make me wonder whether I bet on the right horse. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
As the discussion has raised a number of points I had also tried to express in a post to the use-revolution list on July 21st (when most of the Revolution team was at the Mac Expo in New York) I repeat this post here for those members of the Metacard list that are not at the same time reading the revolution list: July 21st Subject: Re: Rev 2.02/New pricing To: [EMAIL PROTECTED] (snip) On Thu, 17 Jul 2003 Geoff Canyon [EMAIL PROTECTED] wrote: The problem with the 10 line limit in the Starter Kit is that it's both too big and too small. It's too small in that anyone unfamiliar with Revolution thinks it's worthless. (snip) But it's also too large, in that anyone who knows what they're doing and are willing to put out the effort can get almost anything done in ten lines or less. So the Starter Kit has the dual problem of not being as effective as it could be at bringing in new users, and also of hurting sales because people find they can do whatever they need with it. regards, Geoff Canyon These points could also be seen from a different perspective. My impression is that the Starter Kit did *not* hurt sales. It did not hurt you (the Revolution team) in amassing enough money so you could buy out Metacard. The Starter Kit and the Free Edition helped you to get the necessary money in the medium run, because quite a number of people tried the Free Edition for a time longer than the meager thirty days of a trial version and then bought a full license. The Free Edition compares favorably with a number of other low-end authoring systems (in the price range up to 150 US$) - in that is has at least their potential - and will therefore diminish the sale of such products. On the other hand you are right when you say that almost anything (can) be done in ten lines or less with the Starter Kit - that is one of the many (may I say former) beauties of Metacard/Revolution. There may be indeed that occasional programmer that puts out a wonderful application, because he has overcome the ten-lines barrier with much effort and ingenuity. But for any programmer - other than a casual hobbyist - that intends to create applications on a more regular basis, the effort and time needed to overcome the ten-lines barrier by far outweighs the money saved by not buying a regular license. This occasional programmer will not hurt sales, on the contrary, by showing what could be achieved with so much effort, his application could be an incentive to buy a regular license that allows creating similar programs without such tremendous effort and in much less time.-- We have a special problem here in case the Starter Kit should really die: In addition to a full license we have used the Starter Kit for a number of years as an introductory tool for the (university) students in our multimedia seminars and workshops. The students need to be able to work on projects at home outside class hours. They can experiment, try out basic functions, and put together small projects. On the other hand, they can get - or download from our ftp server (or from the many sites that offer Metacard and Revolution stacks) - examples that have been developed with a full edition and run them with the Starter Kit. These stacks will be mostly small, because they are not standalones, and because of that can be downloaded quickly (which is an important consideration, because not many students have a DSL connection at home). The students get a printed documentation introducing them to a basic set of commands and algorithms and a number of sample stacks especially designed for this level. When the semester finishes, they still have the Starter Kits and can take second looks and maybe start anew exploring Revolution and showing it to others. Both by experimenting on their own and by looking at examples (and their scripts) - also such produced with a full version -they can develop a feeling for the rich potential of Metacard/Revolution and could either be prospective buyers or people that spread the word and encourage others to buy such a wonderful product. From obvious reasons it would be out of the question to expect that these students would buy a product for 75 US$ (assuming this will be the educational price for the Express version) at the beginning of a workshop, a product they do not yet know at this point. Given our budget restrictions it would be likewise impossible that our institution could buy a number of new licenses each semester for the students. Quite a number of students have written research papers connected to or supported by a Metacard/Revolution project. Since the pressure to produce research papers is great - in most courses of studies leading to M.A. level about 60 research papers have to be handed in before admission to the M.A. examination process - students that have participated in classes using the Starter Kit like to take advantage of this creative situation and combine their projects with a research paper.
Re: Script Limits and solid IDE evolution!
Hi all, On Thu, 2003-08-07 at 11:50, [EMAIL PROTECTED] wrote: First, without the 10 line script limit, I would be using java or VBS and would have never made a test product to justify buying MC let alone renew the license. This proves that the 10 line script limit is a minimum for anyone who wants to try MC. Of course, a one month limit is as nice if not better without the 10 line limit. But that wasn't available then... Roughly the same for me. Think I used the starter kit for around 4 months to build things before getting a licence. I would be using another language if I had not been able to do this. Using do alone would not suffice as I'd have lost the speed reasons for using MC. 100 ACK... Same for me... I still think the free StarterKit was the best thing ever. One could play with it, get used to the app and even build useful things :-) ...and 30 (contiguous?) days may be not enough, even with no script limits... Regards Klaus Major [EMAIL PROTECTED] www.major-k.de P.S. I confess i build a (not too) commercial CD-ROM with the starterkit and bought my first MC license with the salary for that :-) (Simple Image and video presentation, but what the egg...) Maybe that's what they are afraid of in scotland? ;-) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
Hi David, On Thu, 2003-08-07 at 13:13, Klaus Major wrote: I still think the free StarterKit was the best thing ever. I really could convince some of my customers to install the MC version for their OS, after explaining that there would not be thousands of DLLs on their HD after installation, and that it would be nothing more than a MC-Player (sic!) ;-), so i could deliver some of my projects as stacks... ...which is a fine thing, filesize-wise :-) In the future i would have to spend some extra time to create some kind of MC-Player from scratch. OK, its doable, but should be avoidable... One could play with it, get used to the app and even build useful things :-) ...and 30 (contiguous?) days may be not enough, even with no script limits... 30 days is not enough for a significant market sector (students) to decide they can build a business around creating Rev built products to justify the licence fee. Exactly! P.S. I confess i build a (not too) commercial CD-ROM with the starterkit and bought my first MC license with the salary for that :-) (Simple Image and video presentation, but what the egg...) My guess is that it took you longer than 3 months to learn, build test and release this product? Hmm, i still learn something new in MC every day (and especially in RR ;-), but having a HC/SC background i could finish that CD in about 2 months, including image editing in Photoshop (which i really love :-)... It wasn't really more than something like go next cd etc..., but someone had to do it ;-) But yes, the learning curve IS very steep, but only because MC/RR is s powerful! :-) Maybe that's what they are afraid of in scotland? ;-) Easy - I'm half Scottish :) Ooops, half apologizes then :-D Regards Klaus Major [EMAIL PROTECTED] www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
Mark Talluto wrote: On Thursday, August 7, 2003, at 06:30 AM, Robert Brenstein wrote: Since using 'do' one can relatively easily work around the 'set script to' restriction (performance issues aside), we can only expect further elimination of 'do' in standalones (do limit set to 0) in a near future. It would be a logical followup to fully close that loophole. This line of product development really scares me, particularly as it is a rather expensive product (I paid for full MC license plus renewal) comparing to either RB or CWP. I have my doubts about cutting off multiplatform features from cheaper licenses but I see this as Rev trying to maximize their income. I have no problems if the demo is restricted in terms of dynamic scripting. But the engine embedded when producing a standalone from a licensed environment could retain current limits. Since the limits are clearly kept as parameters, there must be ways to control them accordingly, including setting arbitrary values for specific projects (as I suggested). I had big and long-term plans for a number of MC-based projects, but the recent developments really make me wonder whether I bet on the right horse. Roger all that! Cripple the demo version. Keep things the way they are for paid versions of Rev. The script limits do not come into play so long as there is a licenced Home stack. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
At 1:33PM -0700 8/6/03, Mark Talluto wrote: I know that this limitation will cause of to rewrite sections some of my existing products. I don't see why this limitation must be imposed. I'd urge people to drop a line to Kevin if this change would impact their products, describing how you use the capability. I can't speak for Kevin but I know he listens carefully to concerns of current customers when changes are being considered. -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] Runtime Revolution Limited - Software at the Speed of Thought http://www.runrev.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
I personally dont see an economic reason why this should be limited. I do see reasons to abandon MC/RR more and more... Sad but true... I dont mind evolution of products, but Im against limiting of features while essential things like a good Script Editors or debugger are still as arcane as an sword against an automatic rifle which put a major brake on your productivity are still not being improved as they should. Same remark for antialiased vector graphics which are non-existent in MC/RR,and that would make of MC a good competitor to Flash... Without competition most of the world would be made of communist or socialists and using microsoft DOS. Well, things aren't so straightforward... Please remember that USSR was thefirst country to put a spaceship in orbit, to have robots landing on Mars... And BTW DOS wasn't invented by K. Marx... But this is getting OT... The choir : "Wow! there's a communist on this list..." More features, more freedom = more users, more clients, more applications, more power to the developper = MORE competitive IDE = more users = less competition! Well, these days too often competition leads to standardization monotony... At least we can agree on the following : more features + more power to the developper = less users tempted to switch to another IDE... JB
Re: Script Limits
On 8/8/03 2:43 pm, Robert Brenstein [EMAIL PROTECTED] wrote: And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I did. No answer. But I did not list any specific product that is immediately impacted. My current personal response time is averaging around 10 days. Please be patient. And in case anyone is confused, I do not provide technical support - that queue is only on my personal mail box. Our technical support is running smoothly at the moment with no unexpected delays. Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited: Software at the Speed of Thought Tel: +44 (0) 870 747 1165. Fax: +44 (0)1639 830 707. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Script Limits vs dynamic programming
On Thursday, August 7, 2003 Jeanne A. E. DeVoto wrote: I don't understand what you mean by this. Your extensible stacks are your products. (Product does not mean commercial product, nor is it restricted to standalone applications.) It sounds from your description like your products would in fact impact the products you make, so my suggestion of discussing this with Kevin is still my advice. This is missing the point. The principle advantage of metacard/RR is that it provides for dynamic programming *and* it does so in a cross-platform way. I have and use c, c++ compilers, Futurebasic, RealBasic, and so on, but for different purposes. None of these other programming environments is *dynamic*. Scott Raney's important statement that metacard is written in metacard was not to make the point that, as with c or Basic or Fortran compilers one could write a c, or Basic or Fortran compiler with it, but rather that the system is bootstrapped. The possibility of producing ``standalones'' in hypercard and metacard has unfortunately helped disguise this fact to the point where many (Shari C is a fine example, here, and more power to her) think of metacard/RR as just another IDE with fine cross-platform capabilities. That it no doubt is, but that's not what makes it either unique or important: it is the possibility for dynamic programming that the engine provides, as with hypercard. Limiting script length and ``do'' to non-licensed RR users means that *only* licensed RR users of the stacks I produce can can partake of the dynamic nature. Thus, rather being an essential part of metacard/RR, this dynamism becomes a feature *only* licensed users (developers?) can use, but can't retain in the stacks they produce. By all means, strip it out of standalones if need be, but leave it as an essential feature of stacks. For those who remember them, think of the completely different experience one has programming in and using TILs (threaded interpretative languages) such as APL, and forth: as with hypercard, programming is not distinct from using; they are seamlessly integrated. *That* is what we will be losing by these limits. For those who use metacard/RR to produce applications without those dynamic capabilities, I can understand why they don't feel these limits amount to much. But for some, at least me, it is the dynamism that is my whole reason for using metacard, recommending it to students, and so on. John R. Vokey ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
I know that this limitation will cause of to rewrite sections some of my existing products. I remember in HC and OMO using scripts of controls to hold data. In case scripts of controls in MC are used for the same purpose (holding data, and not executable code), could custom props be a nice workaround ? Just asking, as I've never used custom props much... JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits vs dynamic programming
On Thursday, August 7, 2003, at 04:31 PM, Dr. John R. Vokey wrote: Thus, rather being an essential part of metacard/RR, this dynamism becomes a feature *only* licensed users (developers?) can use, but can't retain in the stacks they produce. By all means, strip it out of standalones if need be, but leave it as an essential feature of stacks. I'm not sure I'm following this. To be used, a stack needs to be either in a standalone, used by a standalone, run by an engine or used in a development environment. In the past there was the free version that--like the standalone--was unlicensed. It could run stacks but in doing so was limited in set the script of ... capability to 10 lines. So, the limit is not in the stack but in the environment and in the intended use of the stack. In some sense (and perhaps in a real sense) the engine is just a naked standalone. It is the player that is handicapped to license or don't set the script. Or am I completely missing your point? Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Thursday, August 7, 2003, at 02:42 AM, jbv wrote: I know that this limitation will cause of to rewrite sections some of my existing products. I remember in HC and OMO using scripts of controls to hold data. In case scripts of controls in MC are used for the same purpose (holding data, and not executable code), could custom props be a nice workaround ? Just asking, as I've never used custom props much... You bring up a point I did not think of till now. Saving small snippets of data in a script is the only way to save encrypted data in a stack. Data in a custom property can be viewed. I know there are other ways to encrypt data, but this is a nice simple way. In my case, I usually am updating code to controls with the set the script of There is no other way to use the same control with new code. You will have to literally replace the entire old control with a new one that is stored on an update card. I do this now when the control that needs to be replaced has more than 10 lines of code anyways. It goes something like this: 1. Version 1 standalone of a product makes a particular document. 2. You find bugs or better ways of doing something. So you update the script in those controls. You have a replica of each of those controls that get updated in the new standalone on an update card that the user never sees. 3. User downloads version 1.1 of standalone. Opens up their save doc in new version and the standalone recognizes that they have a version 1 doc. It updates their doc by replacing all the old controls with the updated versions from the new standalone. Losing the set the script of will take away the ability to easily update a card stack script. Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Wednesday, August 6, 2003, at 08:50 AM, Ken Ray wrote: I would still like to know exactly what the new changes will affect, in case it is something that my current projects use. Shari, What it means is that any of your projects that use the phrase set the script of ... will fail. You used to be able to do this, but the scripts had to be less than 10 lines. With the new changes, you won't be able to do it at all. Is this going to affect licensed copies? Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits vs dynamic programming
This is missing the point. The principle advantage of metacard/RR is that it provides for dynamic programming *and* it does so in a cross-platform way. I have and use c, c++ compilers, Futurebasic, RealBasic, and so on, but for different purposes. None of these other programming environments is *dynamic*. Scott Raney's important statement that metacard is written in metacard was not to make the point that, as with c or Basic or Fortran compilers one could write a c, or Basic or Fortran compiler with it, but rather that the system is bootstrapped. The possibility of producing ``standalones'' in hypercard and metacard has unfortunately helped disguise this fact to the point where many (Shari C is a fine example, here, and more power to her) think of metacard/RR as just another IDE with fine cross-platform capabilities. That it no doubt is, but that's not what makes it either unique or important: it is the possibility for dynamic programming that the engine provides, as with hypercard. Limiting script length and ``do'' to non-licensed RR users means that *only* licensed RR users of the stacks I produce can can partake of the dynamic nature. Thus, rather being an essential part of metacard/RR, this dynamism becomes a feature *only* licensed users (developers?) can use, but can't retain in the stacks they produce. By all means, strip it out of standalones if need be, but leave it as an essential feature of stacks. For those who remember them, think of the completely different experience one has programming in and using TILs (threaded interpretative languages) such as APL, and forth: as with hypercard, programming is not distinct from using; they are seamlessly integrated. *That* is what we will be losing by these limits. For those who use metacard/RR to produce applications without those dynamic capabilities, I can understand why they don't feel these limits amount to much. But for some, at least me, it is the dynamism that is my whole reason for using metacard, recommending it to students, and so on. John R. Vokey Well said, John. I am actually in both shoes. I produce standalones that do not need the dynamic scripting or function fine with the current limits, but I would love to use MC/Rev for dynamic scripting as well. Except that 10-line limit is too restrictive for me. I tried to get over it in the past, but the solution offered by MC was too expensive and Rev never followed with my inquiry. Kevin's tinkering with the script limits now just set me off to not only stop it but rather go the other way and create means to increase those limits when needed. I am afraid, though, that such uses continue to be too small market for Rev to worry about. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and Starter Kit
Roughly the same for me. Think I used the starter kit for around 4 months to build things before getting a licence. I would be using another language if I had not been able to do this. Using do alone would not suffice as I'd have lost the speed reasons for using MC. I, also, used the starter kit for awhile before buying a license. I actually did plan to build a project with the starter kit, but the 10 line script limit was just too big of a hassle to do a proper job. And I got far enough into it, that I knew I liked it. So I bought it. My philosophy as a developer, when I create software that I hope folks will buy, is never to take it away so that they will delete the program and move on. I limit functionality, as MC/Rev have done so far, but allow a very basic version to continue on forever. It's hard to say what would happen were I to change this philosophy. But logically, I believe it is the best philosophy. I know that programs I download, if they work 20 times and stop, get deleted, and do not get downloaded again. I have NEVER purchased shareware that just stopped functioning. I may not buy it immediately. But if it stays on my computer, and gets used, there is a chance I will buy it eventually. I have programs I will be purchasing this year, that fall into this category. Only reason I haven't purchased yet, is Mac changing from PPC to OSX, and I need to get the OSX versions of these programs, so that I do not have to purchase twice. My migration from PPC to OSX has been a slow one. Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Currently I do not believe you can set a script in a standalone. A Hypercard game I created used setting scripts. When I recreated the game in Metacard, I had to remove that because it didn't work once the game was compiled into a standalone. Something about the limitations apparently prevented it. Just tested it. Works fine. Made a stack with two buttons. button one sets the card script to: on fred answer 1 end fred button two calls the script: on mouseUp fred end mouseup Works. So presumably, this is not something that the new limit affects. Shari C Gypsy King Software -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard -- Rodney Tamblyn 44 Melville Street Dunedin New Zealand +64 3 4778606 http://rodney.weblogs.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On Thursday, August 7, 2003, at 09:50 AM, Richard Gaskin wrote: The script limits do not come into play so long as there is a licenced Home stack. I thought that standalones were going to be affected by this change? Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Robert Brenstein wrote: That is a nice approach if switching scripts was to support multiple functionality. However, it will not work if the 'set script' is used to update a distributed stack to a new version or fix a bug without having to replace the whole stack. Not necesarily. After all, the MC 2.5 engine still runs great so there's no reason an updater couldn't be made with the current engine. Or you could use a frontscript tp trap and reroute messages as needed. Fortunately none of this seems likely to be necessary: with a near 100% consensus against this move I'd be surprised if the proposal is enacted. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
El 8/8/2003 15:22, jbv escribió: And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I'm not so interested in the content of the answer, but much more in knowing if any answer has been received... JB I did it the same day he posted, but no answer until this moment. Seems that 'old' days when you got an answer in hours are gone. Jose L. Rodriguez ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Mark Talluto wrote: On Thursday, August 7, 2003, at 09:44 AM, Richard Gaskin wrote: Mark Talluto wrote: In my case, I usually am updating code to controls with the set the script of There is no other way to use the same control with new code. While I agree that the proposed change to script limits is likely more of a problem in itself than a solution, there is at lease one other alternative for your scenario. Rather than writing self-modifying code you could set a property in the object and handle the various behaviors in a backscript using a switch block: on MySpecialBehavior switch the uBehaviorClass of the target case Something doSomnething break case SomethingElse doSomethingElse break end switch end MySpecialBehavior The overhead of the switch block is a fraction of a millisecond and allows you to centralize your code into a common library. This may simplify debugging, and likely simplify maintenance as well should you ever need to alter the behavior. Good idea Richard! I would need to have the ability to set the script of one more time to update all their controls to use this new method though. I better not delete my copy of MC 2.5 just yet. I have yet to use the frontscript/backscript features. Bring your questions to the next revDevCon and let's see if we can shorten that learning cycle. :) -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
No, if you mean running a stack under Rev GUI. Standalones are not licensed, so, yes, they all will be affected. May be we will have licensing for standalones as well one of these days :) Robert Oh god, don't give them any ideas! You want them to charge us MORE to create extra licensing? Pay once for the tools to create the software you want to develop, and pay again once you create it, so that it will run? No.! Bite your tongue! (My friend Robert, a C programmer not on this list, calls me his best worst case scenario person. If he wants to know the worst that could happen, he calls me. He runs the situation by me. And without effort, my first thoughts are the Worst That Could Happen If... He finds this useful, for some strange reason, and often calls me with Life Questions :-) Shari -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits vs dynamic programming
On Thu, 2003-08-07 at 22:31, Dr. John R. Vokey wrote: Thus, rather being an essential part of metacard/RR, this dynamism becomes a feature *only* licensed users (developers?) can use, but can't retain in the stacks they produce. for some, at least me, it is the dynamism that is my whole reason for using metacard, recommending it to students, and so on. John R. Vokey For me as well - it is the whole reason I chose metacard over other options. Now I have to add the other reason that my business (selling solutions to goverment and NGO's) is based on an open source strategy for which I am keen (working with the people on and off the list) to help build an open source community around the langauge. The community is currently a little small and not yet working together on coding projects very actively, but this can be changed and grow. To grow the community there must be a free downloadable product (the demo or a stacks running from a standlaone that I create), which can allow people to start to get involved. This requires that you can do do some limited coding in the tools that are distributed. This is what is being removed ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Thu, 2003-08-07 at 09:40, Robert Brenstein wrote: What I meant in my earlier post is that maybe Rev can introduce procedure to lift these limits for specific projects (they could review them to ensure that the app can't be used to bypass their licensing and thus reduce sales) for a reasonable additional fee. That would be a step forwards in my mind, comparing to the current situation. This would not affect standalones as they are now. I think this is a great idea. As an example the Open Source IDE could be granted such a licence. This is a bit like the duel licencing of open source technologies, where a foundation reserves the right to sell one off licences to developers who want to distribute closed source products that use their open source code. This leaves the control firmly in RunRev's hands, while leaving some flexibility (and even encouragement) for innovative products that would help to extend market share. NB: a danger is that such arrangements are only temporary and the rug can be pulled away as and when RunRev require. I licence with a long enough time-out period would sort this issue for most developers / participants. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
jbv wrote: I remember in HC and OMO using scripts of controls to hold data. In case scripts of controls in MC are used for the same purpose (holding data, and not executable code), could custom props be a nice workaround ? More than a workaround, there are many advantages: - Custom properties can hold any data, even binary. - You can have as many custom props as you like in any object. - You can have any number of custom property sets in any object. For example you could store your user prefs in a stackfile that has a custom property set for each user, with each pref item stored as a property within that set, e.g.: ask Please login: put it into tUserName set the customPropertySet of stack PrefsStack to tUserName get the uSetupInfo of stack PrefsStack -- it now contains the value of the uSetupInfo of the -- property set which matches the login name, with each login -- name havings its own parallel set of props. - You can use array notation for custom properties, useful for numeric indexing or stepping through a list of keys, e.g,: put the hilitedtext of fld Users into tUserList repeat for each line tUser in tUserList put the uUserStats[tUser] of btn Data cr after tReport end repeat put tReport into fld Login Report - It leaves the object's script free to contain code without having to worry about altering data. Custom properties are a very powerful feature of not only Rev but other xTalks as well, including ToolBook, Gain Momentum, and SuperCard. Well worth taking an evening to experiment with... -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
No, if you mean running a stack under Rev GUI. Standalones are not licensed, so, yes, they all will be affected. May be we will have licensing for standalones as well one of these days :) Robert Oh god, don't give them any ideas! You want them to charge us MORE to create extra licensing? Pay once for the tools to create the software you want to develop, and pay again once you create it, so that it will run? No.! Bite your tongue! The idea is not really new per se. If I want to use do without 10-line restriction in a standalone, I need to buy the embedded engine license, which costs way too much to be practical for people like myself. Finding (the hard way) those 'set script' and 'do' limits in standalones was my biggest disappointment when I moved from Hypercard. In most cases, some workaround was possible but I still have a big project on a shelf that can't be realized in MC because of the 'do' limit (it was discussed on this list some time ago). What I meant in my earlier post is that maybe Rev can introduce procedure to lift these limits for specific projects (they could review them to ensure that the app can't be used to bypass their licensing and thus reduce sales) for a reasonable additional fee. That would be a step forwards in my mind, comparing to the current situation. This would not affect standalones as they are now. Of course, Shari, your worry is somewhat justified. Rev may see this as money-making opportunity -- set all limits to 0 and lift/increase them only for a fee. If them setting the first limit to 0 is the first step in that direction, they probably thought about it already though. The most worrisome of all of this is that we can't be ever sure anymore that whatever we have / they promise will last. Taking away dynamic setting of scripts is a big step backwards and removal of a major feature which was taken for granted so far. It also reduces further the utility of standalones for a number of projects. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Mark Talluto wrote: In the non-password-protected stack, all three text strings are readable. In the password-protected stack none of them are. It seems a change was introduced in the engine at some point that now provides complete protection for all three types of data storage. I just did another test in MC 2.5: While it is true that the data is safe in a text editor, it is not safe when you do the following: Try opening that stack you created in MC. You can not get to the script data, but you can surely open up the custom property and read what you put in there. Good point. But while there mare good reasons to have self-modifying scripts, I'm not sure that having script space double as data storage is the optimal answer. Ironically the habit began with users of HC and OMO, neither of which provided options for protecting scripts at all Maybe better would be a development-level password protection: when the devPasskey is set, before a stack can be opened in any IDE it would need to have a matching devPassword. Of course one could build their own IDE, but if the data's that interesting it really needs something stronger than the engine's DES-based encryption anyway. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Fri, 2003-08-08 at 14:12, jbv wrote: And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I'm not so interested in the content of the answer, but much more in knowing if any answer has been received... yes I did - and no answer yet. It is the Edinburgh festival though :) PS: if such big differences exists between MC and Rev users, why don't we (MC users) get organised as an (informal) think tank Yes - for me this would be the same thing as a group of open source developers using MC based collaborative tools - to develop code libraries and recoommend which features should be incorporated into the engine.The lead open source developers would provide the role and feedback that RunRev / Scott require. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Tuesday, August 5, 2003, at 04:29 PM, Shari wrote: What would this affect? Presumably if we create a standalone, and distribute it, this would affect scripts within the standalone, correct? It is my understanding that these are OK. The limit of 0 for standalones would apply to 'set the script of ... during the execution of the standalone. If you don't do that in your scripts, then you are OK. Right now a standalone can have unlimited lines in the script, but not in a do command. I don't know about other folks, but I use the do command a LOT in my standalones. Even with the 10 line limit. It is not clear to me what the 'do' limit will be. I expect it will remain at 10 or increase, but we will have to wait and see. Dar Scott Dar Scott Consultinghttp://www.swcp.com/dsc/Programming Services ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On 7/8/03 2:30 pm, Robert Brenstein [EMAIL PROTECTED] wrote: Actually, this was an acceptable way to earn your wings and test the MC environment. Chaining 10-lines was not breaking any licenses AFAIK. I believe the reasoning was that any serious developer would pay rather than struggle all the time, but people who were not serious wouldn't pay anyway. Some post in this thread seem to confirm that this worked. (But then some complained that they can't truly evaluate the product with 10-line limit.) Right. And with either a purchase of $995 or a free product, pros would pay $995 and everyone else would use the free product. But now, we have Revolution Express - list $149 and currently on intro-offer at $75. The Starter Kit would cannibalize sales of that. And it did not make a good demo, it is less effective than a 30 day trial. That isn't some kind of theoretical debate, we have done our homework - 10 lines of code frustrated a lot of people using the demo. Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited: Software at the Speed of Thought Tel: +44 (0) 870 747 1165. Fax: +44 (0)1639 830 707. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
Hi, I think that setting the script of an objetc/stack is widely used, so with a very serious problem of backwards compatibility for already shipped products, and limiting new ones. There are more situations than already discussed (speed, dynamic programming, limits of 'do') on which setting the scripts is very important. For example: - upgrading old version of documents created with a MC/RR standalone. New versions of the standalone may include new functionalities for the documents and you have to update the scripts in the document or add objetcs to the interface, etc - letting the user to password his documents. You may put the password into a custom property but this not sure as to put it into a script and protect the stack. If you put the password out (external pref file) of the document/stack then it is more difficult to distribute/send it. Really I do not understand the reasons for this. The consequence seems a move to let developers develop plug-ins and stacks for use inside the IDE more than real and competitive applications for end users. It is very strange that you have language features on the IDE not present on the standalone (they are addressed only to the developers!). Hope this is not a decission taken... José L. Rodríguez ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Mark Talluto wrote: In my case, I usually am updating code to controls with the set the script of There is no other way to use the same control with new code. While I agree that the proposed change to script limits is likely more of a problem in itself than a solution, there is at lease one other alternative for your scenario. Rather than writing self-modifying code you could set a property in the object and handle the various behaviors in a backscript using a switch block: on MySpecialBehavior switch the uBehaviorClass of the target case Something doSomnething break case SomethingElse doSomethingElse break end switch end MySpecialBehavior The overhead of the switch block is a fraction of a millisecond and allows you to centralize your code into a common library. This may simplify debugging, and likely simplify maintenance as well should you ever need to alter the behavior. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
BTW could someone eventually post Shari's informal poll to the Rev list ? I'm not on the Rev list myself... I believe that such a list-based poll makes no sense for a number of reasons. If we are serious about it, it should be set up somewhere on the web and an address to posted to both lists. We will get better participation and more immediate results (and if IP addresses are recorded, we can judge if someone was trying to skew the results). And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I did. No answer. But I did not list any specific product that is immediately impacted. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
It is my understanding that these are OK. The limit of 0 for standalones would apply to 'set the script of ... during the execution of the standalone. If you don't do that in your scripts, then you are OK. Currently I do not believe you can set a script in a standalone. A Hypercard game I created used setting scripts. When I recreated the game in Metacard, I had to remove that because it didn't work once the game was compiled into a standalone. Something about the limitations apparently prevented it. So presumably, this is not something that the new limit affects. Shari C Gypsy King Software -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
What would this affect? Presumably if we create a standalone, and distribute it, this would affect scripts within the standalone, correct? Right now a standalone can have unlimited lines in the script, but not in a do command. I don't know about other folks, but I use the do command a LOT in my standalones. Even with the 10 line limit. I use custom properties a lot, as well. What exactly would this affect? Shari C Gypsy King Software As part of the transition process in the MetaCard acquisition, we're working out what to with the scriptLimits property when not developing with a licensed IDE or the 30 day trial. We plan to reduce the first value in the property, the one that lets you set scripts of 10 lines, to 0. So you'll still be able to use do but otherwise this loophole will be closed. If anyone has any objections to this, please contact me off list. The main objection I can see that someone might have is that they use this in their existing standalone. If that is the case, we'll work something out with you before making this change. Kind regards, Kevin -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On 07/08/2003 15:03:12 metacard-admin wrote: Fine rant Xavier - you sure know how to turn a crafted argument into a plate of spaghetti! Sorry, I dont have macoronis anymore... On Thu, 2003-08-07 at 11:50, [EMAIL PROTECTED] wrote: First, without the 10 line script limit, I would be using java or VBS and would have never made a test product to justify buying MC let alone renew the license. This proves that the 10 line script limit is a minimum for anyone who wants to try MC. Of course, a one month limit is as nice if not better without the 10 line limit. But that wasn't available then... Roughly the same for me. Think I used the starter kit for around 4 months to build things before getting a licence. I would be using another language if I had not been able to do this. Using do alone would not suffice as I'd have lost the speed reasons for using MC. The issues about using dynamic scripts is not one of speed but one of unprecedented flexibility. For example a script can edit a script before running it. (It's an integral part of the Matrix. =) Visit us at http://www.clearstream.com IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries. END OF DISCLAIMER
Re: Script Limits and solid IDE evolution!
I still think the free StarterKit was the best thing ever. One could play with it, get used to the app and even build useful things :-) and 30 (contiguous?) days may be not enough, even with no script limits... And BTW is this 30 days trial a valid / useful protection ? I know ppl who build huge projects by re-downloading again and again Flash MX (or other apps) evaluation versions every 30 days... Telling the truth I downloaded the Rev 2.01 (AFAIR) about 2 weeks ago, but haven't downloaded the key yet, as I'm not sure I'll have enough time within the next 30 days to explore every feature... JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Script Limits
On Fri, 2003-08-08 at 04:53, Chipp Walters wrote: In order to create the next generation: a new and much faster version of RR, we're going to have to remove the 'set the script' command and treat Transcript just as other compilers-- like C++, etc.. Would this make a difference? IOW, if instead of removing features for no customer gain (IMHO always a bad idea) they were removing features for customer gain. Doesn't help me or several of the other people that are objecting. The reason is that we choose MC over the complier approach becasue we can distribute and have a powerful set of tools to maintain and update code to a wide user base without paying royalty costs. Removing the set script... ability of standalones / demo removes one of the most powerful techniques - others are work arounds which may work in some cases - but over time result in an ugly hack. For me and I'd say the community it is even worse than that because it hampers releasing an professional educational product that teaches and allows students to practice scripting. This is bad for the product, bad for the MC community (there are plently of colleges that would take up such tools especially if released open source as LGPL), and even worse for the longer term health of the community - as it restricts any open source development to licenced users - which is a contradiction in marketing and probably licencing terms. Open source users will not pay for the ability to start coding and learning and this is a growing educational market. The 20 line restriction (freudian slip) works as a compromise - you can code for free but it's a pain without the licence. Time limited demo's don't count in this world view. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Robert Brenstein wrote: That is a nice approach if switching scripts was to support multiple functionality. However, it will not work if the 'set script' is used to update a distributed stack to a new version or fix a bug without having to replace the whole stack. Not necesarily. After all, the MC 2.5 engine still runs great so there's no reason an updater couldn't be made with the current engine. Or you could use a frontscript tp trap and reroute messages as needed. Fortunately none of this seems likely to be necessary: with a near 100% consensus against this move I'd be surprised if the proposal is enacted. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site Richard, what you suggest are all workabouts. And the fact that this groups is 100% against the change does not mean it will not go into effect. This issue barely caused a blink on Rev list and that is where majority of Rev users are. We are soon to be a true minority and our interest in retaining MC as it was will make us dinosaurs :( Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
At 9:54 am -0700 7/8/03, Mark Talluto wrote: On Thursday, August 7, 2003, at 09:36 AM, Richard Gaskin wrote: I just did a test with MC 2.5: I made a stack with one field, and put This is field data into it. Then I added a custom prop and put This is prop data into it. Then I put --this is script data into the stack script. I saved it, then did a Save As, set the password, and saved this copy again. I quit MC and opened both stack files in TexEdit (any app that lets you open binries will do). In the non-password-protected stack, all three text strings are readable. In the password-protected stack none of them are. It seems a change was introduced in the engine at some point that now provides complete protection for all three types of data storage. I just did another test in MC 2.5: While it is true that the data is safe in a text editor, it is not safe when you do the following: Try opening that stack you created in MC. You can not get to the script data, but you can surely open up the custom property and read what you put in there. This is true, but you can use a sneaky getprop handler to prevent access to a custom property unless you supply a secret key. To do this, you would set the properties you want to keep secure in a custom property set. E.g. set the cSecuredata[PIN] of stack secureStack to 1234 Then you would use a getprop handler like this: getprop cSecuredata[tKey] if item 1 of tKey is yohoho then ## yohoho is the secret key return the cSecuredata[item 2 of tKey] of me else return empty end if end cSecuredata So to get the PIN property, you would have to do this: get the cSecuredata[yohoho,PIN] of stack securestack Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits - not good
I too must voice an opinion...I would NOT like this to change. JR Roughly the same for me. Think I used the starter kit for around 4 months to build things before getting a licence. I would be using another language if I had not been able to do this. Using do alone would not suffice as I'd have lost the speed reasons for using MC. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Richard, what you suggest are all workabouts. And the fact that this groups is 100% against the change does not mean it will not go into effect. This issue barely caused a blink on Rev list and that is where majority of Rev users are. We are soon to be a true minority and our interest in retaining MC as it was will make us dinosaurs :( Same feeling here...:( BTW could someone eventually post Shari's informal poll to the Rev list ? I'm not on the Rev list myself... And BTW again, did anyone contact Kevin privately about this script limit thing, as suggested in his original message ? And did anyone get an answer ? I'm not so interested in the content of the answer, but much more in knowing if any answer has been received... JB PS: if such big differences exists between MC and Rev users, why don't we (MC users) get organised as an (informal) think tank / users union, in order to provide RR with smart criticism, wise suggestions and even source code in order to improve the MC engine, in exchange for free (or lower prices on) licences ? Yes, I know, it's a weird mix between naive hippie idealism and open source philosophy, and it certainly needs to be improved, but well it doesn't cost anything (except some bandwidth) to post it... According to recent messages on this list, if things at RR evolve the wrong way, it seems that many of us won't upgrade to Rev and will switch to another tool... So at first glance it looks like each side would gain from that : - Rev would have a bunch of pro / experienced beta testers / critics / contributors / whatever - we would keep our favorite tool and watch it evolve in ways we like - MC/Rev will improve and be a strong competitor (for Director etc) and eventually attract new users, which means more market shares for Rev... Of course, these contributions would rather concern the engine than the GUI... And since I didn't spend more than 5 minutes on this idea, there are certainly numerous flaws that everyone will be happy to point out... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Wednesday, August 6, 2003, at 08:50 AM, Ken Ray wrote: I would still like to know exactly what the new changes will affect, in case it is something that my current projects use. Shari, What it means is that any of your projects that use the phrase set the script of ... will fail. You used to be able to do this, but the scripts had to be less than 10 lines. With the new changes, you won't be able to do it at all. Is this going to affect licensed copies? No, if you mean running a stack under Rev GUI. Standalones are not licensed, so, yes, they all will be affected. May be we will have licensing for standalones as well one of these days :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Hi Mark, ... In the non-password-protected stack, all three text strings are readable. In the password-protected stack none of them are. It seems a change was introduced in the engine at some point that now provides complete protection for all three types of data storage. I just did another test in MC 2.5: While it is true that the data is safe in a text editor, it is not safe when you do the following: Try opening that stack you created in MC. You can not get to the script data, but you can surely open up the custom property and read what you put in there. That's sad, but true... Getting a bit off-topic: One of the few features i liked in Director was to be able to protect (forgotten the correct term) files before creating a standalone. (If you were not putting all the files into the standalone...) This way these files could ONLY be played back by the projector (the Director standalone engien). They could NEITHER be opened NOR changed in the IDE anymore... (But i have no idea if this is easy/hard to implement... I think the latter one ;-) Best regards, Mark Talluto http://www.canelasoftware.com Regards Klaus Major [EMAIL PROTECTED] www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Wednesday, August 6, 2003, at 02:56 PM, jbv wrote: I'm afraid this script limit thing might be the first of a long list of unexpected (and undocumented / unexplained) changes, and discussions about them might clutter this list in coming weeks... I confess that this news hit me pretty hard; we got the same news on the Revolution list. However, there always has to be a first mention. This mail is much better than finding an engine doesn't work as expected after downloading it. There is no indication that this change will be undocumented. Last but not least, I think that getting messages from Kevin saying we're working on this and that... If anyone has any objections to this, please contact me off list. isn't the best strategy / politics to convince MC users to upgrade to Rev... In best light, I think we can see that Kevin is giving folks a heads-up on what is coming. It also indicates that Kevin is desiring to work with people who currently have standalone product that will be affected by this. Knowing Kevin, I expect things can be worked out. I agree that the 'off list' part may give an impression of dampening discussion of bad news and I can only guess of Kevin's motives there. I agree that this news along with licensing changes can make one wonder about the future. Dar Scott kibitzing rev user ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
I bet you were trying to set the scripts that had more than 10 lines and exactly that limit prevented you from doing so. If you test, you will see that setting shorter scripts works. Once they change the limit to 0, setting scripts in standalones will not be possible at all. From what I understand, the do limit will remain at 10. I think that they are becoming slowly more paranoid about someone producing a competing interface or producing programs that bypass the licensing system. Yes it was more than 10 lines. The way the game was written in Hypercard, if the object had a script, it was *active*. If it didn't, it was inactive. Objects were activated/inactivated this way. Only one object, or group of objects, could be active at a time, and I set this at the start of the round, by setting/deleting scripts. No big deal. I just did this another way in Metacard. Though I sure wish I had know from the get-go. It would have saved me a lot of time and frustration. Here I had a project that worked, all bugs had been squashed. I ported it to Metacard, made sure it worked, compiled it into a standalone, and voila. It broke. I jumped thru a bunch of hoops trying to figure out why. At the time I didn't know that the standalone had limits over the stack, nor was it very clear in the docs everything those limits affected. So I whittled away I don't know how many days trying to get to the bottom of that one. Which brings me back to the original question: I would still like to know exactly what the new changes will affect, in case it is something that my current projects use. If I upgrade, I want to know beforehand what upgrading will break. I would rather not go thru several months of beta testing for a project that has had a minor feature added, in order to make sure the new MC engine doesn't break something that wasn't broke before. A this is what you can't do anymore FAQ would save us a lot of time and frustration. We can read it, determine whether our projects will be affected, and change them if necessary. Much better than trying to track down a bug that didn't used to be there. I'd like to see this change from MC to Rev, be smoother than the change from HC to MC. Shari C Gypsy King Software -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On Thursday, August 7, 2003, at 06:30 AM, Robert Brenstein wrote: Since using 'do' one can relatively easily work around the 'set script to' restriction (performance issues aside), we can only expect further elimination of 'do' in standalones (do limit set to 0) in a near future. It would be a logical followup to fully close that loophole. This line of product development really scares me, particularly as it is a rather expensive product (I paid for full MC license plus renewal) comparing to either RB or CWP. I have my doubts about cutting off multiplatform features from cheaper licenses but I see this as Rev trying to maximize their income. I have no problems if the demo is restricted in terms of dynamic scripting. But the engine embedded when producing a standalone from a licensed environment could retain current limits. Since the limits are clearly kept as parameters, there must be ways to control them accordingly, including setting arbitrary values for specific projects (as I suggested). I had big and long-term plans for a number of MC-based projects, but the recent developments really make me wonder whether I bet on the right horse. Roger all that! Cripple the demo version. Keep things the way they are for paid versions of Rev. Have us a sign a EUA that protects the Rev rights. Lets get back to work. Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
Hi everyone, Great subject. I've been waiting for the right arguments to jump in... Mostly to present some hope for more features, not more limits! Im open to criticism as usual! I dont want to rant that much but in view of the situation... First, without the 10 line script limit, I would be using java or VBS and would have never made a test product to justify buying MC let alone renew the license. This proves that the 10 line script limit is a minimum for anyone who wants to try MC. Of course, a one month limit is as nice if not better without the 10 line limit. But that wasn't available then... Second, the problem with the MC licensing scheme is that it was too easy to abuse... Here, I fully understand RR's way. You build a chain of buttons never breaking the limit of the 10 script lines but despite that, I dont know anyone who would in their right mind want to use such an IDE. Also, to Scott's demise, allowing compilation of an executable is a nice feature for a demo but it's part of the problem with runaway licenses... Nonetheless, RR has improved on the product and for good reason. Their IDE is VERY nice compared to the clunky-over-simplified MC GUI. The only problem I see with the demo is allowing to make executables and/or saving large projects! You need enough to make a test, prove it can work, basta. But if my project is even a small neural network or statistic package, 10 lines is ridiculous and I'll grab another IDE. Following Robert's comments earlier, the removal of a feature or limiting a feature like dynamic scripting (the DO script), is IMOHO a terrible mistake and a SEVERE limit to the IDE's possibilities. Of which this one is almost unique among other IDEs. Even considering that this could allow you to make an executable IDE, dynamic scripts have too many advantages to be discarded. And for RR's peace of mind, they are hard to make and impossible to debug but they are by far one of the most modern features of RR/MC/HC. So why throw that away? Robert is already blocked and most of us dont use this. I am forced to port a 1 card stack that was a dynamic script loader for cached execution and I'll probably never will (read as yet another loss). I personally dont see an economic reason why this should be limited. I do see reasons to abandon MC/RR more and more... I dont see why we couldn't create our own IDE... And it's not even an IDE, it's just a GUI without hardly any serious compiling capabilities (like C++ or even the veteran HC CompileIT) If this GUI redesign was more present as a feature in MC/RR, imagine how popular it could become! How many products today have skinning and GUI building built-in? LOTS! And most OS's too... No many IDE's have this feature on the other hand! Also, note that other than optimizing the IDE to improve your workflow, I dont see why anyone would want to go through the pain of creating an IDE. Most RR and MC users create applications for their clients. None of them want their clients to develop more themselves! And those of us who build IDE tools do it for the good of either our workflow or for the RR/MC community. Blocked by this, many of us would just jump ship to another IDE that is more efficient... Building a HyperTalk macro language is a breeze in any language... Did anyone think that without this feature RR' wouldn't even exist and all RR users would be forced using another product or MC's barebone GUI. Now Im thinking of porting hypertalk to PHP... I dont mind evolution of products, but Im against limiting of features while essential things like a good Script Editors or debugger are still as arcane as an sword against an automatic rifle which put a major brake on your productivity are still not being improved as they should. Competition for RR? Come on. Give me a break! Competition is very small, and it makes ya healthy. Also, you'd have to go through RR for a license renewal eventually which Im sure they would prevent... Without competition most of the world would be made of communist or socialists and using microsoft DOS. More features, more freedom = more users, more clients, more applications, more power to the developper = MORE competitive IDE = more users = less competition! Think about it... I welcome your rants and flames openly Xavier Visit us at http://www.clearstream.com IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states
Re: Script Limits
On Thursday, August 7, 2003, at 01:24 PM, Richard Gaskin wrote: Mark Talluto wrote: In the non-password-protected stack, all three text strings are readable. In the password-protected stack none of them are. It seems a change was introduced in the engine at some point that now provides complete protection for all three types of data storage. I just did another test in MC 2.5: While it is true that the data is safe in a text editor, it is not safe when you do the following: Try opening that stack you created in MC. You can not get to the script data, but you can surely open up the custom property and read what you put in there. Good point. But while there mare good reasons to have self-modifying scripts, I'm not sure that having script space double as data storage is the optimal answer. Ironically the habit began with users of HC and OMO, neither of which provided options for protecting scripts at all Maybe better would be a development-level password protection: when the devPasskey is set, before a stack can be opened in any IDE it would need to have a matching devPassword. Of course one could build their own IDE, but if the data's that interesting it really needs something stronger than the engine's DES-based encryption anyway. Ahhh...another good point. We do need a better solution for encryption of data in stacks. Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
On 7/8/03 2:30 pm, Robert Brenstein [EMAIL PROTECTED] wrote: In other words, while MC was meant as a tool for professional developers, Rev is mostly after the hobbyst market. Not at all. Revolution Express is after the low end market, but Studio and Enterprise are aimed at professionals. When you cross-grade from MetaCard, you get Enterprise - i.e. pro. No platform limitations, no marketing exit screen, etc. Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited: Software at the Speed of Thought Tel: +44 (0) 870 747 1165. Fax: +44 (0)1639 830 707. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Tuesday, August 5, 2003, at 08:59 PM, Shari wrote: It is my understanding that these are OK. The limit of 0 for standalones would apply to 'set the script of ... during the execution of the standalone. If you don't do that in your scripts, then you are OK. Currently I do not believe you can set a script in a standalone. A Hypercard game I created used setting scripts. When I recreated the game in Metacard, I had to remove that because it didn't work once the game was compiled into a standalone. Something about the limitations apparently prevented it. So presumably, this is not something that the new limit affects. There is a 15 line limit on setting the scripts in a standalone. Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
It is my understanding that these are OK. The limit of 0 for standalones would apply to 'set the script of ... during the execution of the standalone. If you don't do that in your scripts, then you are OK. Currently I do not believe you can set a script in a standalone. A Hypercard game I created used setting scripts. When I recreated the game in Metacard, I had to remove that because it didn't work once the game was compiled into a standalone. Something about the limitations apparently prevented it. So presumably, this is not something that the new limit affects. Shari C Gypsy King Software I bet you were trying to set the scripts that had more than 10 lines and exactly that limit prevented you from doing so. If you test, you will see that setting shorter scripts works. Once they change the limit to 0, setting scripts in standalones will not be possible at all. From what I understand, the do limit will remain at 10. I think that they are becoming slowly more paranoid about someone producing a competing interface or producing programs that bypass the licensing system. Personally, I do not have a problem with them changing those limits IF they institute a mechanism of allowing to change it on application basis and with reasonable licensing. In practical terms, their are cutting off people who produced MC/Rev programs with the demo -- the new approach is that people get 30-day fully functioning demo but then pay or nothing. That is a big change in strategy but in parallel with them cutting down cross-platform features for cheaper license options. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
Richard Gaskin : Custom properties are a very powerful feature of not only Rev but other xTalks as well, including ToolBook, Gain Momentum, and SuperCard. Well worth taking an evening to experiment with... Which confirms my first impression. BTW I guess that a custom property can also include some code that can be activated / executed via a do command... Execution speed might be slowed down a bit, but could this be a workaround for the 10 (or 0) lines script limit ? JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Thursday, August 7, 2003, at 01:03 PM, David Bovill wrote: The classic reason for not doing this is the fear that it will undercut the market for the full product. This fear is completely unfounded. It is also completely un-Scottish. I think this so, but I mention it with hesitation, because I respect RunRev's analysis. Consider this scenario comparison (numbers off by several orders of magnitude): With free version-- 18,000,000 free version users in 2006 2,500,000 licensed version users in 2006 Cost to support free version $15,000 in 2006 Without free version-- 20,000 free version users in 2006 90,000 licensed version users in 2006 Cost to fight free versions: $150,000 in 2006 All of those numbers might be way off, I have not given this much consideration, but they should reflect my gut feel in this, which may not have any value at all. My gut feel says my gut feel has no sense. Dar Scott I hear I'm part Scottish. I think I'm probably related to St. Patrick and Adam Smith and some of those guys portrayed in the movies wearing blue. And I shout Freedom! whenever I'm tortured. (OK, Patrick was Roman-Scottish and lived mostly in Ireland, but I still claim him as a relative.) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
On Thursday, August 7, 2003, at 09:44 AM, Richard Gaskin wrote: Mark Talluto wrote: In my case, I usually am updating code to controls with the set the script of There is no other way to use the same control with new code. While I agree that the proposed change to script limits is likely more of a problem in itself than a solution, there is at lease one other alternative for your scenario. Rather than writing self-modifying code you could set a property in the object and handle the various behaviors in a backscript using a switch block: on MySpecialBehavior switch the uBehaviorClass of the target case Something doSomnething break case SomethingElse doSomethingElse break end switch end MySpecialBehavior The overhead of the switch block is a fraction of a millisecond and allows you to centralize your code into a common library. This may simplify debugging, and likely simplify maintenance as well should you ever need to alter the behavior. Good idea Richard! I would need to have the ability to set the script of one more time to update all their controls to use this new method though. I better not delete my copy of MC 2.5 just yet. I have yet to use the frontscript/backscript features. I need to do some reading. It has been on my to do list for some time. Best regards, Mark Talluto http://www.canelasoftware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits and solid IDE evolution!
Mark Talluto wrote: The script limits do not come into play so long as there is a licenced Home stack. I thought that standalones were going to be affected by this change? Yes, as there is no licensed Home stack. But in the IDE you can still make all the automated script-generating tools you like. The post I replied to was concerned about do, which is not affected by the proposed change at all. And given the clear preference for maintaining script limits, I'd be surprised if even that went into effect. I think we're all clear: we don't want to see a Digital Chisel for Rev. But in my understanding even Digital Chisel was able to work out an equitable royalty arrangement with Allegiant, so there's no reason for any fears along those lines here. After all, it does no one any good to piss off the party making your engine; any company that did would position itself for self-destruction. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Script Limits
I would still like to know exactly what the new changes will affect, in case it is something that my current projects use. Shari, What it means is that any of your projects that use the phrase set the script of ... will fail. You used to be able to do this, but the scripts had to be less than 10 lines. With the new changes, you won't be able to do it at all. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Script Limits
I would still like to know exactly what the new changes will affect, in case it is something that my current projects use. Telling the truth, I must confess that I share Shari's worries. I'm afraid this script limit thing might be the first of a long list of unexpected (and undocumented / unexplained) changes, and discussions about them might clutter this list in coming weeks... Last but not least, I think that getting messages from Kevin saying we're working on this and that... If anyone has any objections to this, please contact me off list. isn't the best strategy / politics to convince MC users to upgrade to Rev... And certainly not the best official answer to all the questions raised lately... As Shari wrote, we need an official FAQ showing that there are still ppl at RR reading this list, and not only a bunch of biznessmen busy with marketing strategies... Yes, I know I'm overreacting a bit, but better now than too late... JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Script Limits
Hi, As part of the transition process in the MetaCard acquisition, we're working out what to with the scriptLimits property when not developing with a licensed IDE or the 30 day trial. We plan to reduce the first value in the property, the one that lets you set scripts of 10 lines, to 0. So you'll still be able to use do but otherwise this loophole will be closed. If anyone has any objections to this, please contact me off list. The main objection I can see that someone might have is that they use this in their existing standalone. If that is the case, we'll work something out with you before making this change. Kind regards, Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited: Software at the Speed of Thought Tel: +44 (0) 870 747 1165. Fax: +44 (0)1639 830 707. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
script limits in front/back scripts
I'm curious about why scriptLimits are imposed on scripts inserted in frontscripts/backscripts. The insert command requires user to specify an object script to be inserted. Surely the limits should apply to the object, in the same way as they normally do. Frontscripts/backscripts must be of limited usefulness in any standalone applications as these have scriptlimits imposed (these limits don't apply to scripts already created during authoring with a licensed home stack). Rodney -- Rodney Tamblyn 44 Melville St Dunedin, New Zealand +64 3 4778606 025 2667321 http://rodney.weblogs.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
Hi all On Wednesday, May 15, 2002, at 02:08 PM, erik hansen wrote: according to the archives and the index there are no script limits. are there any special circumstances, or can i put 200,000 chars in a script without problems? I think the limit is 4 GB -Mark Talluto I KNOW the script limit is 4 GB ;-) Regards Klaus Major [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
At 8:24 PM -0500 5/15/02, J. Landman Gay wrote: On 5/15/02 4:50 PM, erik hansen wrote: i will assume that mac OS 9.2.2 can handle a lot more than 30,000. If I remember right, the script limit is in gigabytes -- 4, I think. It's in the docs someplace. Everything that has a limit of 4 gigabytes has to live in the same 4 gigabytes. So all your scripts combined with all your fields, etc., has to total less than 4 gigabytes. When someone bumps into _that_ limit, I'd like to see the project. ;-) I should add that, of course, 4 gigabytes will be a tight fit in less than 10 years. I hope Scott is ready by then ;-) -- regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
I should add that, of course, 4 gigabytes will be a tight fit in less than 10 years. I hope Scott is ready by then ;-) We're already there: MetaCard has already been ported to 64-bit systems, including DEC Alpha (which as it turns out we no longer support: Compaq discontinued that processor line because apparently the world doesn't really need 64 bit computing just yet ;-) You'll still be limited to 4GB per object until/unless we change the file format, but that 4GB address space is not shared on 64-bit systems like it must be on 32-bit systems. Regards, Scott -- regards, Geoff Canyon [EMAIL PROTECTED] Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
on 16/5/02 8:35 AM, Geoff Canyon at [EMAIL PROTECTED] wrote: It's in the docs someplace. Everything that has a limit of 4 gigabytes has to live in the same 4 gigabytes. So all your scripts combined with all your fields, etc., has to total less than 4 gigabytes. When someone bumps into _that_ limit, I'd like to see the project. ;-) well... we've produced quite a few projects (not in MC) over 4GB - images, text, buttons, etc - (these are mostly touchscreen interactive 'kiosk' publications, though we're currently working on a DVD-ROM) I think the largest one is currently about 19GB, and expanding. But admittedly all the data isn't loaded into RAM simultaneously, so it doesn't really count. But it does make the point that humans can assemble very large quantities of quality content (and we're not wasteful with space, honest). Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com| Fax : +44 (0)1273-728866 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
I should add that, of course, 4 gigabytes will be a tight fit in less than 10 years. I hope Scott is ready by then ;-) We're already there: MetaCard has already been ported to 64-bit systems, including DEC Alpha (which as it turns out we no longer support: Compaq discontinued that processor line because apparently the world doesn't really need 64 bit computing just yet ;-) You'll still be limited to 4GB per object until/unless we change the file format, but that 4GB address space is not shared on 64-bit systems like it must be on 32-bit systems. Regards, Scott Nice to know you're thinking ahead, Scott -- I can hardly wait to get started writing systems with multiple gigabyte-plus scripts! ;-) -- regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
Nice to know you're thinking ahead, Scott -- I can hardly wait to get started writing systems with multiple gigabyte-plus scripts! ;-) -- I was wondering : when compared to my projects made with HC and OMO between 1987 and 96, the size of my current projects under MC has increased (mainly due to all the pix, sounds QT movies). But does the size of scripts increase as well ? With all the build-in functions, it's often possible to use 1 single line of code for what took a whole handler several years ago... I remember writing scripts 32 kbytes long in OMO, when a few kbytes are enough today, and for projects of similar (and even greater) complexity... Do you folks share the same experience ? One last question (from the devil's advocate) : does MC really features the right tools to write (and debug) several GB of script ? Cheers, JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
At 11:58 PM + 5/16/02, jbv wrote: One last question (from the devil's advocate) : does MC really features the right tools to write (and debug) several GB of script ? Heck no! I'd be curious to see what a field would do trying to display such a script, but I'm betting it wouldn't be pretty. Then if it did, think about trying to scroll through perhaps twenty million lines of code! Or deal with, oh, half a million handlers. It reminds me of the classic Tick comic, Night of a Million Billion Ninjas -- regards, Geoff Canyon [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
combining all the handlers for a stack into one script avoids many problems, but opening a 70k script is slooower. = [EMAIL PROTECTED]http://www.erikhansen.org __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
erik hansen wrote: according to the archives and the index there are no script limits. are there any special circumstances, or can i put 200,000 chars in a script without problems? = [EMAIL PROTECTED]http://www.erikhansen.org __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Hello, I'm using, in a 24/7 production context, on the linux platform, mc-based web applications that include some fat scripts (up to 795000 chars each° without any troubbles. Best Regards, Pierre Sahores WEB VPN applications databases servers Inspection académique de Seine-Saint-Denis Qualifier produire l'avantage compétitif ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
--- Pierre Sahores [EMAIL PROTECTED] wrote: I'm using, in a 24/7 production context, on the linux platform, mc-based web applications that include some fat scripts (up to 795000 chars each° without any troubbles. merci bien, i will assume that mac OS 9.2.2 can handle a lot more than 30,000. of course, this changes everything. = [EMAIL PROTECTED]http://www.erikhansen.org __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: script limits
On Wednesday, May 15, 2002, at 02:08 PM, erik hansen wrote: according to the archives and the index there are no script limits. are there any special circumstances, or can i put 200,000 chars in a script without problems? I think the limit is 4 GB -Mark Talluto ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
