When does a Stack Actually Die in the IDE???
Mark Smith
mark at maseurope.net
Tue Apr 18 11:29:30 EDT 2006
I time things like this by putting them in a loop:
put the millisecs into stTime
repeat 10000 -- for example
put the short name of this stack into myStackName
end repeat
put the millisecs - stTime
on my machine, this takes 11 millsecs.
But where the engine seemed slower than string slicing, I was passing
the long id of an object to a function, and in that case, parsing the
ID seemed to be quicker than 'get the short name of..', by a factor
of 3 or 4. Obviously, this would only matter if you were doing
something many thousands of times, but you said you were concerned
about it being slow... :)
Best,
Mark
On 18 Apr 2006, at 16:02, David Burgun wrote:
> Yeah!
>
> How do you time things? For instance, how long does a:
>
> put the short name of this stack into myStackName take?
>
> Since I wouldn't have thought that a:
>
> put the short name of the stack of me into myStackName
>
> wouldn't take a lot longer (if it were possible!).
>
> Since (again I assume) when you make a reference to "this stack" or
> "me" then the engine can quickly look up the value rather than
> processing a string.
>
> All the Best
> Dave
>
> On 18 Apr 2006, at 15:53, Mark Smith wrote:
>
>> Ah, I see what you mean. I made the assumption (when will I
>> learn?) that the file name would be a superset of the stack name.
>> Which is a shame, where speed matters, as getting the short name
>> from the engine is quite a bit slower than simply parsing the file
>> name.
>>
>> Best,
>>
>> Mark
>>
>> On 18 Apr 2006, at 15:37, David Burgun wrote:
>>
>>> Hi,
>>>
>>> I have a stack called s1.rev, the short name of the stack is
>>> "untitled 1". If I run this:
>>>
>>> on mouseUp
>>> local myStackName
>>>
>>> set the itemDelimiter to "/"
>>> put (char 1 to -6 of item -1 of the long id of me) into
>>> myStackName,
>>>
>>> end mouseUp
>>>
>>> and step thru it in the debugger, then myStackName is set to "s1"
>>> which is the file name, not the short name (set in the Stack
>>> Property Inspector). If I do a put openStacks in the message box,
>>> I get this list:
>>>
>>> Message Box
>>> revMenubar
>>> revScriptEditor 1
>>> revVariableWatcher
>>> Untitled 1
>>> revTools
>>>
>>> s1 is not among the openStacks, but "Untitled 1" is!
>>>
>>> if I run the following:
>>>
>>> local myStackFilePathName
>>> put value(word wordoffset("stack",the long id of me ) + 1 of
>>> the long id of me) into myStackFilePathName
>>> put the short name of stack myStackFilePathName into myStackName
>>>
>>> Then myStackName is set to "Untitled 1" and so it finds it ok in
>>> the list returned by openStacks.
>>>
>>> Do you get the same results? I'm running RunRev 2.6.6 MacOS 10.4.6
>>>
>>> All the Best
>>> Dave
>>>
>>> On 18 Apr 2006, at 15:09, Mark Smith wrote:
>>>
>>>> stackIsOpen2 takes the long id of an object, gets the short name
>>>> of the stack the object is in, and then checks whether or not
>>>> it's among the lines of the openStacks - which is a list of the
>>>> short names of all currently open stacks, not their file names.
>>>>
>>>> It seems to work perfectly well, here ( I assume the listing
>>>> below is not your actual script, there are typos ).
>>>>
>>>> Best,
>>>>
>>>> Mark
>>>>
>>>> On 18 Apr 2006, at 14:55, David Burgun wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I tried this:
>>>>>
>>>>> function stackIsOpen1 pLongID
>>>>> return (the short name of pLongID is among the lines of the
>>>>> openstacks)
>>>>> end stackIsOpen
>>>>>
>>>>> was, by my measurement, 4 times slower than
>>>>>
>>>>> function stackIsOpen2 pLongID
>>>>> set the itemDelimiter to "/"
>>>>> return (char 1 to -6 of item -1 of pLongID) is among the
>>>>> lines of the openStack
>>>>> end stackIsOpen
>>>>>
>>>>> on mouseUp
>>>>> if stackIsOpen1(the long id of me) then
>>>>> beep
>>>>> end if
>>>>>
>>>>> if stackIsOpen2(the long id of me) then
>>>>> beep
>>>>> end if
>>>>> end mouseUp
>>>>>
>>>>> And both functions always return false! stackIsOpen1() since it
>>>>> takes the short name of the button rather than the stack and
>>>>> stackIsOpen2 since the short name of the stack is not the same
>>>>> as the file name of the stack.
>>>>>
>>>>> The only way I've found to do it is like this:
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ----------
>>>>> --
>>>>> -- ISMGetStackShortName
>>>>> --
>>>>> ------------------------------------------------------------------
>>>>> ----------
>>>>> function ISMGetStackShortName theObjectLongID
>>>>> local myStackFilePathName
>>>>> put value(word wordoffset("stack",theObjectLongID )+ 1 of
>>>>> theObjectLongID) into myStackFilePathName
>>>>>
>>>>> return the short name of stack myStackFilePathName
>>>>> end ISMGetStackShortName
>>>>>
>>>>> if ISMGetStackShortName(theObjectLongID) is not among the lines
>>>>> of openStacks then
>>>>>
>>>>> end if
>>>>>
>>>>>
>>>>> All the Best
>>>>> Dave
>>>>>
>>>>> On 18 Apr 2006, at 14:07, Mark Smith wrote:
>>>>>
>>>>>> Well, since
>>>>>>
>>>>>> function stackIsOpen pLongID
>>>>>> return (the short name of pLongID is among the lines of the
>>>>>> openstacks)
>>>>>> end stackIsOpen
>>>>>>
>>>>>> was, by my measurement, 4 times slower than
>>>>>>
>>>>>> function stackIsOpen pLongID
>>>>>> set the itemDelimiter to "/"
>>>>>> return (char 1 to -6 of item -1 of pLongID) is among the
>>>>>> lines of the openStack
>>>>>> end stackIsOpen
>>>>>>
>>>>>> I wouldn't assume that the engines routines for getting short
>>>>>> names etc, are going to be faster than string slicing.
>>>>>>
>>>>>> I've no idea what kind of overhead there is in calling
>>>>>> externals, and it'd have to be a pretty good external to beat
>>>>>> Rev's string handling, I think...
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> On 18 Apr 2006, at 13:28, David Burgun wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was really just after some speed. The problem is that this
>>>>>>> quite a common thing to want to do, you can do it, but it
>>>>>>> means parsing a string, which although the solution provided
>>>>>>> by the wonderful people on this list is pretty fast, it's
>>>>>>> still slow for doing something like this, which seems pretty
>>>>>>> silly really since I assume that this information would be
>>>>>>> almost instantly available in the Engine. I was actually
>>>>>>> considering writing an External Command to do this, but not
>>>>>>> sure how fast that would be and whether the solutions
>>>>>>> provided thus far would be quicker. Any ideas???
>>>>>>>
>>>>>>> Thanks a lot
>>>>>>> All the Best
>>>>>>> Dave
>>>>>>>
>>>>>>> On 18 Apr 2006, at 13:18, Mark Smith wrote:
>>>>>>>
>>>>>>>> I see what you mean. Maybe what's needed is a library of
>>>>>>>> functions to deal with this sort of thing.
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On 18 Apr 2006, at 10:34, David Burgun wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The problem with that is if you have groups or nested
>>>>>>>>> groups, you then have to loop thru until you find the card
>>>>>>>>> or stack.
>>>>>>>>>
>>>>>>>>> All the Best
>>>>>>>>> Dave
>>>>>>>>>
>>>>>>>>> On 15 Apr 2006, at 13:07, Mark Smith wrote:
>>>>>>>>>
>>>>>>>>>> Well, you could try using 'the owner of'. I haven't
>>>>>>>>>> experimented with it much, so I don't know how flexible it
>>>>>>>>>> is.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Mark
>>>>>>>>>> On 15 Apr 2006, at 12:54, David Burgun wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot for this. One thing that has puzzled me is
>>>>>>>>>>> why you can't access things like the stack or card of an
>>>>>>>>>>> object. For instance why can't I just do this:
>>>>>>>>>>>
>>>>>>>>>>> put the short name of the stack of the long id of me
>>>>>>>>>>> into myStackName
>>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>> put the short name of the card of the long id of me
>>>>>>>>>>> myCardName
>>>>>>>>>>>
>>>>>>>>>>> Which would return the name of the stack/card that the
>>>>>>>>>>> object resides in.
>>>>>>>>>>>
>>>>>>>>>>> It just seems like this ought to work, in fact when I
>>>>>>>>>>> found out that RunRev didn't support this I was surprised!
>>>>>>>>>>>
>>>>>>>>>>> Any ideas why this isn't supported?
>>>>>>>>>>>
>>>>>>>>>>> All the Best
>>>>>>>>>>> Dave
>>>>>>>>>>>
>>>>>>>>>>> On 15 Apr 2006, at 02:33, J. Landman Gay wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Mark Smith wrote:
>>>>>>>>>>>> > I just had a doh! moment in response to your <the
>>>>>>>>>>>> short name of
>>>>>>>>>>>> > pStackLongID>, but then in order to see how much
>>>>>>>>>>>> faster the engine does
>>>>>>>>>>>> > this, I tested it the same way I tested my first tries
>>>>>>>>>>>> (which was
>>>>>>>>>>>> > actually with 10000 iterations, not 1000), and
>>>>>>>>>>>> >
>>>>>>>>>>>> > function stackIsOpen pLongID
>>>>>>>>>>>> > return (the short name of pLongID is among the lines
>>>>>>>>>>>> of the openstacks)
>>>>>>>>>>>> > end stackIsOpen
>>>>>>>>>>>> >
>>>>>>>>>>>> > takes nearly 600 ms!
>>>>>>>>>>>>
>>>>>>>>>>>> Interesting. I never time these things enough. It looks
>>>>>>>>>>>> like if a script needs to make repeated calls to the
>>>>>>>>>>>> function, then your way would be preferable because of
>>>>>>>>>>>> the speed increase.
>>>>>>>>>>>>
>>>>>>>>>>>> It's been an interesting experiment, I like when the
>>>>>>>>>>>> list does these things.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jacqueline Landman Gay |
>>>>>>>>>>>> jacque at hyperactivesw.com
>>>>>>>>>>>> HyperActive Software | http://
>>>>>>>>>>>> www.hyperactivesw.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
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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