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 th
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: An informal poll....
On Thursday, August 7, 2003, at 11:44 AM, Shari wrote: All of this talk about something working with a licensed Home stack versus as standalone make me wonder How many, who have purchased licenses, use MC/Rev to build standalones, that will be distributed to others? That was THE REASON I purchased. Instead of migrating from Hypercard to C/C++, I moved to MC. I don't create much for my own use. 99% of everything I do, is for distribution, to produce income. The rest of you? -- I have a pro license for commercial work. Everyone makes small tools to make their day go by better. I am in that category as well. 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
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
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:36 AM, Richard Gaskin wrote: 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. 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. Best regards, Mark Talluto http://www.canelasoftware.com ___ 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
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
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
