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
>
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
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 be
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 mu
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 LO
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 c
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. W
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, th
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
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 prope
On Thursday, August 7, 2003, at 10:53 PM, Chipp Walters wrote:
OK,
to play the devils advocate here.
What IF (I have no such knowledge of this) Kevin and Scott said
something
like:
In order to create the next generation: a new and much faster version
of RR,
we're going to have to remove the '
h 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-m
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
On 8/8/03 1:23 pm, Robert Brenstein <[EMAIL PROTECTED]> wrote:
> 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-l
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.
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 a
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 a
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
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
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 preven
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
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 be
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 r
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
Fine rant Xavier - you sure know how to turn a crafted argument into a
plate of spaghetti!
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 ren
On Thursday, August 7, 2003, at 04:31 PM, Dr. John R. Vokey wrote:
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 usin
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 ki
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.
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 re
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
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
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
> 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 w
ually silly person to pass that up. I see no evidence that Kevin or
Scott would do anything to disrupt that steady, high-ROI cash flow, as
Kevin's wise judgement on this script limits issue demonstrates.
--
Richard Gaskin
Fourth World
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 f
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
> im
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 a
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
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
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
...
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
On Wednesday, August 6, 2003, at 05:59 PM, Jeanne A. E. DeVoto wrote:
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 i
On Thu, 2003-08-07 at 06:23, Mark Talluto wrote:
> >
> Hi Jeanne,
>
> I dropped him a line earlier today. I am taking advantage of his
> invitation to discuss this. Talking about his openly may be helpful.
> We can figure out ways to live without this in the event this is going
> to happen.
0 (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, bu
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 r
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,
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
>
>
> 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
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, t
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
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 underst
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
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 g
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
> 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
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
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 i
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.
> 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.
> >
This is just a classic missed mark
OK,
to play the devils advocate here.
What IF (I have no such knowledge of this) Kevin and Scott said something
like:
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 compile
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
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 p
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 us
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
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
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
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
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 way
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
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 c
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 c
>
>
> 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 /
> 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
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'
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 l
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
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
>
>
> 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 (main
>> 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 proce
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
> _th
> 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 l
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 gi
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 th
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
-
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.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperacti
--- 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
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]h
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
88 matches
Mail list logo
