Script Limits in 2.8.0 [was Spreadsheet]

David Bovill david at openpartnership.net
Sun May 13 14:26:15 EDT 2007


There are two examples which are not reated to self modyfyin code really:

  1) Spread sheet type applications where the user can do simple stuff but
extend the manipulations to any level using an embedded scripting language
that is as easy to understand and write ans Transcript

 2) Component frameworks in which high end components can be created by
developers and then customised with a built in scripting language, or even

 3) Components created within a free environment and made available to be
used in the commercial IDE, which has extended workflow tool sets over and
above the pure language..

On 13/05/07, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
> Roger.E.Eller wrote:
> > I still believe it to be an unnecessary constraining factor in a
> > developers ability to create dynamic code in their standalones when
> > law could be used instead to enforce anti-piracy.
>
> If a fly-by-nighter steals RunRev's work, RunRev could sue the culprit
> for everything they had and chances are with someone playing at such a
> low level it won't amount to a fraction of the money the company would
> have lost.
>
> The most effective enforcement is prevention.
>
> Since the product was born in 1992, the method of preventing this form
> of piracy has been scriptLimits.
>
>
> > Certain application types need this flexibility such as AI. My
> > preference would be either the removal of the limitation completely
> > or to expand it to 25 lines (or more). It would still be limiting
> > enough to prevent mischievous persons from stealing RRs business,
> > yet broad enough that most developers could accomplish their
> > goals when longer dynamic scripts are really needed.
>
> Personally, I'd like to see it go much further and make the entire
> engine fully open source with no limits of any kind.
>
> But then again I don't follow Eric Raymond's economic theories, and
> certainly don't begrudge the folks at RunRev a chance to get some ROI
> and earn a living.
>
> So in the meantime, let's take a look at this:
>
> Can you describe the algorithms that need self-modifying code, and how
> those are handled in compiled languages like C?
>
> What's happening in those 15 extra lines that makes the difference in
> usefulness?
>
> I'll bet some of the folks here can find a solution that's at least
> workable, possibly even more efficient and easier to maintain than the
> caveats and migraines traditionally associated with self-modifying code.
>    ;)
>
> If we find that yours is the unique circumstance where there really
> isn't any way to take advantage of classic compiled algorithms, perhaps
> you could take Kevin up on his offer and see what can be worked out for
> your app.
>
> But I'd be interested in seeing folks chew on this first, if only
> because I love a good problem-solving session and almost always learn a
> lot from it.
>
> --
>   Richard Gaskin
>   Fourth World Media Corporation
>   ___________________________________________________________
>   Ambassador at FourthWorld.com       http://www.FourthWorld.com
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the use-livecode mailing list