When does a Stack Actually Die in the IDE???
David Burgun
dburgun at dsl.pipex.com
Tue Apr 18 11:02:15 EDT 2006
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
More information about the use-livecode
mailing list