Get rid of ScriptLimits

[carlo.kokoth]

It would be nice, in the days of highly dynamic applications, if the totally arbitrary (and dare i say malevolent) scriptLimits would finally disapper.

RunRev is quite interesting product, but (at least) I'll never purchase a product that has been crippled just because it's author felt he "just could" - ie. no technical reason at all.

If there is such a reason, please correct me, but i searched the net all over and only thing i found was some (dated) mumbo-jumbo relating to limiting piracy. And i don't like to feel screwed only because my "supplier" (couldn't think of a better term atm.) is a control freak.

PS: Just look around, nearly EVERY interesting lang/platform (ie. .NET, Lisp/Scheme, Haskell, Smalltalk, not talking about scripting/highly dynamic languages) lets you generate/execute ARBITRARILY long code at run time (some even allow dynamic compilation / incremental linking), don't stay behind ("just because you can" ))

[Klaus]

Hi Carlo,

ther reason for this is to prevent that someone creates "another Rev" with Rev, which is possible!
Rev is writen in Rev, if you did not know.


Best

Klaus

[Mark]

Hello,

I don't think that carlo.kokoth understands what the script limits do. You can run virtually infinitely long code in RunRev, but there are specific situations in which the amount of code is limited. One example is the execution of dynamic code through the "do" command.

Best regards,

Mark

[carlo.kokoth]

Please _DO_ enlighten me what would be possible (that would be irony, not everybody is a clueless dumbf***k, i can actually use this strange thingie called brain)...

I've been listening to the same arguments from Lisp and Smalltalk vendors for ages. But they, at least, decided to limit what you can do legally, instead of CRIPPLING their products (or, in the case of Franz - Allegro Lisp vendor - to demand royalties, but Allegro lisp is in an entirely different category than RR).

And please do tell me i don't know what "dynamically" (ie. in the f***ing run-time, in case of rev that would be deployed-binary-runtime maybe) means, and tell me that i can't read the documentation etc. ...

So the answer is "sciptLimits won't be lifted in this millenia either" ?

And it is usual in this community to insist (or expect, believe and treat accordingly to this belief) that everybody who is interested in Revolution is a braindead moron ???

[Klaus]

Hi Carlo,

I do not think that Mark did want to insult you in any way, remember that not all of us are native english
speakers so some misunderstandings may rise from time to time, so please calm down a bit!

So the answer is "sciptLimits won't be lifted in this millenia" ?

The answer to this is yes!


Best

Klaus

P.S.
I have been using Rev/MetaCard for about ten years now and never found that the "scriptlimits"
were limiting my scripting. With the new "behaviours" this is even less important than ever!

[carlo.kokoth]

Hi Carlo,

I do not think that Mark did want to insult you in any way, remember that not all of us are native english
speakers so some misunderstandings may rise from time to time, so please calm down a bit!

Calming down won't be necessary, maybe more smilies were in order (but I've been scolded for using too much of them from time to time), I've tried to be funny as well as sound in the "don't teach the old dog to bark" manner (English is not my native language too, and i know i don't weight words too much, good i at least censored the worst of em ).

So the answer is "sciptLimits won't be lifted in this millenia" ?
The answer to this is yes!

Best

Klaus

P.S.
I have been using Rev/MetaCard for about ten years now and never found that the "scriptlimits"
were limiting my scripting. With the new "behaviours" this is even less important than ever!

That is indeed sad, cause that mean I won't be able to use Rev to build some interesting apps (more or less it means i won't use it at all, cause i percieve the limit as artificial and arbitrary).

For example the thing on which i'm working right now is a kind of data-pump which allows users to specify data-tranformation routines if they desire so. And that is usually impossible to do in ten lines - yeah i could dedicate a script to each column and say "Dear users, no more than 10 lines of script per column, life's a b*tch, you know ..." but that somehow doesn't cut it by my standarts. And creating my own script engine / including an existing one when the runtime I (would) pay dearly for is (could be) more than capable of doing this for me ...

There's more to the app, but hey, I can't show you all my cards (pun intended ). So i guess it's Tcl/Tk for this one. Or F#/.NET ? "Your scripts / transformation routines - VB.NET / C# / whatever - are compiled before execution and run at native .NET speed"; doesn't matter whether I like this style of propagation, it's possible nonetheless .

Also some other cases (a minority, I know) would benefit from unlimited scripting (Simulation software, Game-builders or programmable games, etc.). But what the heck, in case it's a no-no i can happily live without Revolution (sadly never getting more than a glimpse at what the elegance that makes it so powerful is).

Thx anyway,
Carlo.

PS: As techniques for run-time compilation (and incremental [re]linking / dynamic [re]loading of libs), embeddable scripting languages (Lua, Io, Falcon; the first two even have .NET versions of the runtime) etc. are finally coming to the mainstream (google for example .NET compiler as a service), i think the decision whether to lift the limits or become obsolete will have to be made, eventually.

[FourthWorld]

Maybe it would be helpful if we looked at this from a different angle: what specific task do you want to accomplish?

Theoretically, there are a great many things Rev doesn't have that other languages do, and vice versa. So stepping back from the theoretical to the applied may help us point you to a solution that completely solves the problem at hand and lets you move forward completing your project.

If you truly need to be able to set scripts longer than 10 executable lines at runtime you can request a special build from RunRev to do that. Given the risk exposure such an engine creates for them it may be accompanied by a special license with an explicit non-compete clause; I don't know, I've never needed it myself, but Kevin Miller has made the offer publicly so I know that option's available.

That might seem onerous, but the language is just flexible enough to create a competing product in a few days if one were sufficiently motivated, essentially letting RunRev deliver 90+% of what one would need to drive them out of business. This is not purely hypothetical, it's happened once before in this family of languages, in which the vendor found the sales of their product cannibalized by a direct competitor made with their engine. FOSS languages have no such concerns, but the FOSS world has yet to produce a good xTalk (though I wish they would; as a consultant nothing would be better for my work than an open source xTalk).

So that's the story with scriptLimits, but as you know from C/C#/C++, etc., most of the world is driven by non-runtime-modifiable code, and still they're able to implement things like genetic algorithms and other dynamic behaviors which can be done in Rev too, using the version you have right now.

And remember, within the IDE there are no sciptLimits, so there's no limit to what you can do to automate scripting tasks. And since RevMedia is free, sharing your automated scripting solutions with others costs them nothing, and is a win-win all around: folks get turned on to RevTalk, and you don't need to document 3000 tokens for them since Rev's already done it.

To help find a good solution we'll need to know more about the specifics of the problem you're looking to solve.

[richmond62]

I have a funny feeling about Mr Kokoth:

1. his postings are abusive in a way which quite belies his excuse that he is not a native English-speaker: certainly native-like, so understands
very well the effect his words will have.

2. all of his postings are belligerent and combative.

Now we all know that RunRev has its limitations (one wonders what computer programming language does not have limitations); what RunRev also
has is a tremendous amount of capabilities. Surely it is better to explore and attempt to stretch these capabilities than rubbish "problems" such as
rather insignificant script limits?

I don't know how long Mr Kokoth has been using RunRev; I have been using it approximately 9 years; and Richard Gaskin was "on it" almost
simultaneously with his mother's milk.

About 8 years ago I authored a CD-ROM that required long scripts (well, about 120 lines) and I managed this with a free version that had a
10 line script limit: if that were possible then my answer to those who start moaning about script limits is this:

Think! Use your brain! There is ALWAYS a way round limitations.

[carlo.kokoth]

I have a funny feeling about Mr Kokoth:
1. his postings are abusive in a way which quite belies his excuse that he is not a native English-speaker: certainly native-like, so understands
very well the effect his words will have.

It was just a statement, not an excuse. I also cannot really know what exactly will others think / do, other than expect that rattling the closet containing a skeleton and remarking about the strange noises it makes and the funny smell will wake them up. Mission accomplished, now maybe it's time to get past the denial phase ("nobody really needs scripts longer then 10 lines and those who do are welcome to overcome the limitation on their own..." pardon me ? am I reading it correctly ?), and take it for what it is: an artificial barrier (which does not seem logical to me) and IMO an artifact from dawns of time.

2. all of his postings are belligerent and combative.

I had to look up belligerent (thx, by the way), and I agree i could have crawled here on my knees begging, but sometimes a fresh perspective (lots of folks around give away the same kind of functionality unlimited and matter-of-factly, some even do it for free; and I'm not trying to imply that Rev should be free, just stating a fact), even (and sometimes because of) presented in a despectful manner can force the other side to wake up (sometimes friendly referred to as pulling one's head from some place unmentionable, at least here, where people seem somewhat allergic to a IMO healthy dose of sarcasm; irony and humor are my ways to grok the not-so-great reality).

Now we all know that RunRev has its limitations (one wonders what computer programming language does not have limitations); what RunRev also has is a tremendous amount of capabilities. Surely it is better to explore and attempt to stretch these capabilities than rubbish "problems" such as
rather insignificant script limits?

I'm sure there are people who don't consider this a liability, and even those who feel limits are OK as long as they can break or sidestep them. I'm able to cope with limitations coming for example from implementation details / OS deficiencies or whatever, what I do have a problem with are artificially imposed limits (no matter whether they are showstoppers or nuisances).

Yes, I've seen the thread where there somebody was explaining how it's done, i just don't like ugly warts on otherwise clean and _to-the-point_ code.

And it's even a matter of principles for me, even though everybody have the right to package and sell his product in a way he deems right, that doesn't mean i have to agree with it, and in the event I don't I wont support his endeavours. How exactly can one change world to be a better place than not doing and not supporting things that he considers wrong / unfair / questionable ?

I don't know how long Mr Kokoth has been using RunRev; I have been using it approximately 9 years; and Richard Gaskin was "on it" almost simultaneously with his mother's milk.

Mr. Kokoth was trying Revolution for a few days and freely admits he knows sh*t about it. He's been heard saying that he hopes it doesn't imply he's entirely stupid, but then again, he had only used it for a couple of days so he might be too dumb to realize it (no dissing of R.G. intended).

About 8 years ago I authored a CD-ROM that required long scripts (well, about 120 lines) and I managed this with a free version that had a
10 line script limit:

Good for you, if there were no artificial barriers you'd have one less thing to brag about .

if that were possible then my answer to those who start moaning about script limits is this:
Think! Use your brain! There is ALWAYS a way round limitations.

Exactly, so why there have to be any ? Every protection can be breached or side-stepped, that doesn't mean I should have to. I don't think my work should consist of fighting my tool/environment. On the contrary, the most joy i felt coding was using languages such as Lisp and Smalltalk (even Haskell does have bytecode interpreter and can embed its own compiler as library and generate / replace code at runtime, and we are talking about one of the most strongly statically typed language ever known to mankind - even side-effects have their own type, and don't get me started on GHC implementation & libs, the only thing it doesn't have is Rev's UI metaphor; again, I'm not trying to diss Rev, if it didn't look like it had something to offer I wouldn't touch it with a ten foot pole, I'm very picky concerning languages / tools I use), where one basically plugs into a wonderful live environment which he further customizes to serve his needs until an application emerges and is separated from development tools.

I'm sure Rev can do the same, stacks / behaviors / message routing also seems nice, found it a bit lacking in a few areas (missing true thread support can hurt when you _really_ need it; processes are a resource-hungry and messy/ugly alternative), then decided not to use it because i simply wont even try to stomach some business practices. But that is of no importance, the bulk of what i wanted to communicate (with some sauce added so it wouldn't be so dry) was :

Runtime code evaluation / compilation seems pervasive today
Runtime code evaluation / compilation cannot be sidestepped when truly needed (ie algorithms are changing / inputs)
There are some people (at least one ) who feel strongly about artificially imposed barriers

[carlo.kokoth]

Maybe it would be helpful if we looked at this from a different angle: what specific task do you want to accomplish?

I don't really want to talk about it (I'd like to be the first one to implement it ...), but one part of the whole is a user entering some scripts to be used for data transformation. I want it to scale, handle huge data sets through lazy evaluation, no limits imposed on how many data sources, and so of course no limits can be applied on the length of scripts which have to combine this data (I like to make things as general and as flexible as possible). But even in the case of a few sources and handful of rows the logic easily gets longer than 10 lines.

I have few other use cases, some of which might not even require scripts, I won't argue, but that's not as important to me. It's not only about what i need (i can and will turn elsewhere if only because real threads aren't a bad thing to have - unavoidable blocking calls, parallelism / concurrency and zero-copy message-passing are among reasons why to have them - as an implementation tool, not to scare users with 'em ), it 's also about the fact that my opinion on the matter of "protection" seems to differ with the general opinion of Rev denizens (I just wanted to voice it and I acknowledge that I might have done so too loud according to somebody's taste / standarts).

Theoretically, there are a great many things Rev doesn't have that other languages do, and vice versa. So stepping back from the theoretical to the applied may help us point you to a solution that completely solves the problem at hand and lets you move forward completing your project.

If you truly need to be able to set scripts longer than 10 executable lines at runtime you can request a special build from RunRev to do that. Given the risk exposure such an engine creates for them it may be accompanied by a special license with an explicit non-compete clause; I don't know, I've never needed it myself, but Kevin Miller has made the offer publicly so I know that option's available.

Sadly google hadn't brought this up when i hunted for "scriptLimits revolution some-other-bulls**t", thx for the info.

I allways considered this to the the default for any development environment (you cannot just overwrite our copyright and ship your version), bar the free ones. When/if this becomes true for Revolution I'll consider purchasing the license both because Rev seems like a nice solution for a broad spectrum of applications (i have some niche cases which it wouldn't fit just yet, but overally it's really nice client side development tool), and to support the IMO right move.

That might seem onerous, but the language is just flexible enough to create a competing product in a few days if one were sufficiently motivated, essentially letting RunRev deliver 90+% of what one would need to drive them out of business. This is not purely hypothetical, it's happened once before in this family of languages, in which the vendor found the sales of their product cannibalized by a direct competitor made with their engine. FOSS languages have no such concerns, but the FOSS world has yet to produce a good xTalk (though I wish they would; as a consultant nothing would be better for my work than an open source xTalk).

Is there an "hacker" skilled both in say Lisp/Haskell and xTalk who could somehow sum up his feelings about both alternatives ? I only scratched the surface of RevTalk, i'm sure of it, I'm trying to get some incentive to want to learn more about it; while it looks somewhat speech-like and like it contains a lot of conveniences, it also look highly irregular compared to said languages. And languages like Smalltalk/Io/Falcon/Tcl/Factor allow for nearly same degree of linguistic shenanigans while offering (not every language necessarily each of the mentioned): coroutines or even full blown first-class continuations, time-traveling debugger, just-in-time compilation, full run-time introspection / redefinability, even to the point that "there is no syntax/it's anything you make it" / "everything can be redefined" and image-based application-state persistence.

Revolution have some of these and couldn't dream of others, I've heard a lot of overall praise (even if some of it must be attributed to the fact that some just cannot grasp the complexity that other languages incur trying to adhere rather to a strict set of general rules enabling other kinds of productivity / elegance rather than trying to sound like a bed-time story ), but I miss some juicy details / insight into where exactly lies RevTalk's true mojo/power.

Can this arcane knowledge be taught / transfered to others, can others be pointed to a shortcut or must one just soak in the concentrated goodness until the zen AHA moment ? Or are there documented cases of people so twisted (fancier word for "used to"; I'm really not trying to provoke as much as some would attribute to me, it's just my style of expression, and when one doesn't see me grinning like an idiot, it might get interpreted as open hostility ) by traditional (i know some langs I mentioned really stretch or even don't meet with the word) languages so that they weren't able to see the light ?

So that's the story with scriptLimits, but as you know from C/C#/C++, etc., most of the world is driven by non-runtime-modifiable code, and still they're able to implement things like genetic algorithms and other dynamic behaviors which can be done in Rev too, using the version you have right now.

One thing no amount of "design time" effort can supplement is some kind of run-time evaluation / interpretation / execution of an algorithm that has been supplied during run-time. You can (more or less) implement your own scripting language or something like it, you can bind to another scripting engine or you can just use the host language. Oh, wait, you cannot, certainly not on the first date. You have to dine and wine em for a while .

And remember, within the IDE there are no sciptLimits, so there's no limit to what you can do to automate scripting tasks. And since RevMedia is free, sharing your automated scripting solutions with others costs them nothing, and is a win-win all around: folks get turned on to RevTalk, and you don't need to document 3000 tokens for them since Rev's already done it.

A valid point and surely something to keep in mind, thx.

But on the other hand, there are people who cannot be trusted with an IDE (if it would depend on me I wouldn't trust them with a mouse and keyboard ) and it wont work for corporate / commercial environment (enforceability of business rules etc). And i don't think I just verified it the free version cannot handle database connections, which disqualifies it right away.

To help find a good solution we'll need to know more about the specifics of the problem you're looking to solve.

Thanks for the offer (really) but I already know the answer (or the better part of it anyway, cause it's still open-ended, now its time to stop prototyping and start building it for real to see how far it can grow) to my problem and I'm just looking for the most flexible implementation environment. Different environments impose different constraints and shape the resulting product, that's why I am trying a bunch of different tools to see which would fit my intents the best / allow me to offer more functionality.