Re: Background Long IDs

[Brian Milby via use-livecode]

I've pushed an initial version to GitHub:
https://github.com/bwmilby/lc-misc/tree/master/ScriptTracker

The code is also there with the stack so it can be viewed online without
downloading the stack.  The code was exported from itself, so you can see
how it constructs the exports.  If you enable the Automatic File Import,
then it will notice changes to the exported files and import them back to
the stack (can't edit itself though).  Don't really know about performance
yet.  Devolution exports 112 files which takes ~450ms on my machine.

Thanks,
Brian

On Sun, May 6, 2018 at 10:46 PM, Brian Milby  wrote:

> Could be where it is being referenced.  From the message box:
> put the long id of background id 1020 of stack "AutoScriptSaver"
> Returns:
> bkgnd id 1020 of stack "/Users/milby/Desktop/AutoScriptSaver.livecode"
> Until after I visit the card, when it changes to:
> group id 1020 of card id 1025 of stack "/Users/milby/Desktop/
> AutoScriptSaver.livecode"
> This was in LC 8.1.9
> The stack uses files(folder, type) so it doesn't work in 8.
>
> On Sun, May 6, 2018 at 9:20 PM, dunbarx via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi.
>>
>> Maybe I am not building this correctly.  I made a new stack of five
>> cards. I
>> placed a BG group on card 3. It has ID 1005.
>>
>> On card 1 in a button script:
>>
>> on mouseUp
>>  put the long id of background ID 1005 of this stack into fld 2
>> end mouseUp
>>
>> In new sessions, whether I visit card 3 or not, I always get "group ID
>> 1005
>> of "
>>
>> Never "bkgnd ID 1005 of ..."
>>
>> LC 8.1.7
>>
>> Craig Newman
>>
>>
>>
>> --
>> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-
>> User-f278306.html
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Background Long IDs

[Brian Milby via use-livecode]

Could be where it is being referenced.  From the message box:
put the long id of background id 1020 of stack "AutoScriptSaver"
Returns:
bkgnd id 1020 of stack "/Users/milby/Desktop/AutoScriptSaver.livecode"
Until after I visit the card, when it changes to:
group id 1020 of card id 1025 of stack
"/Users/milby/Desktop/AutoScriptSaver.livecode"
This was in LC 8.1.9
The stack uses files(folder, type) so it doesn't work in 8.

On Sun, May 6, 2018 at 9:20 PM, dunbarx via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi.
>
> Maybe I am not building this correctly.  I made a new stack of five cards.
> I
> placed a BG group on card 3. It has ID 1005.
>
> On card 1 in a button script:
>
> on mouseUp
>  put the long id of background ID 1005 of this stack into fld 2
> end mouseUp
>
> In new sessions, whether I visit card 3 or not, I always get "group ID 1005
> of "
>
> Never "bkgnd ID 1005 of ..."
>
> LC 8.1.7
>
> Craig Newman
>
>
>
> --
> Sent from: http://runtime-revolution.278305.n4.nabble.com/
> Revolution-User-f278306.html
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: slow listserv

[Mark Wieder via use-livecode]

On 05/06/2018 07:20 PM, Mark Wieder via use-livecode wrote:

Anyone else finding the listserv slow?
I just posted a message and it showed up on the list after an hour and a 
half.




...and of course now it's working again. nvm.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

slow listserv

[Mark Wieder via use-livecode]

Anyone else finding the listserv slow?
I just posted a message and it showed up on the list after an hour and a 
half.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Background Long IDs

[dunbarx via use-livecode]

Hi.

Maybe I am not building this correctly.  I made a new stack of five cards. I
placed a BG group on card 3. It has ID 1005.

On card 1 in a button script:

on mouseUp
 put the long id of background ID 1005 of this stack into fld 2 
end mouseUp

In new sessions, whether I visit card 3 or not, I always get "group ID 1005
of "

Never "bkgnd ID 1005 of ..."

LC 8.1.7

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \\\"Walker\\\" Available

[Mark Wieder via use-livecode]

On 05/06/2018 02:42 PM, Richard Gaskin via use-livecode wrote:

Did copy-on-write get changed in v9, or is the scope of its effects just 
more limited than I had understood it to be?


I'm still at the point of not trusting copy-on-write yet, but I think 
you're misinterpreting your results. If I'm understanding the way in 
which LC has implemented copy-on-write, then whether or not you use 
references in parameters, the "return p-1" code will have to make a copy 
on the stack to return a value - you can't just return a reference. So 
all you're changing by removing the "@" is one level of copying.


Of course, I may well be not quite understanding what's been 
implemented, in which case I welcome any correction.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Alex Tweedly via use-livecode]

I doubt if it would work out faster. A quick test of

 time ls -lR > null

gives 166 ms vs. the 179 I get from the non-recursive tree walker - so 
by the time you gather that output, and re-format back to something more 
usable, I think you'd probably come out the same or slower.


Alex.


On 06/05/2018 21:46, Malte Pfaff-Brill via use-livecode wrote:

I wonder if shelling out to DIR on Windows and LS on Linux/Mac wouldn’t be the 
fastest option…

Cheers,

Malte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory "Walker" Available

[Alex Tweedly via use-livecode]

On 06/05/2018 20:12, Richard Gaskin via use-livecode wrote:

Ah, that makes sense.  It's not so much the recursion per se, but the 
more general advantage of inline processing vs handler calls.



Exactly.
In the test case below you know how many levels deep you're going, 
which seems a good fit for inline loops. But how do we handle cases 
like directory traversal, where we don't know in advance how deep 
we'll need to go?


In this test case I do know how many levels - but the code makes no use 
of that knowledge, it simply exits when we get down to 0.
For an example of how to handle directory recursion, see Ben's earlier 
post in this thread. Or I've included my current version below - I 
return a 2-level array of folder / file / data ... rather than a 
file-per-line.
It's at least comforting to see that while the overhead of handler 
calls is significant, it's mostly in relative comparison: If I read 
that correctly, there are 1000 iterations of 100 operations, for a 
total of 100k operations.  If my coffee is working, that means an 
overhead of just 0.00208 ms per operation when called in a separate 
handler, no? (thinking 273ms total for separate handler - 65ms for 
inline, per 100k operations).


Yep - though it gets higher with more parameters. My recursive 'walker' 
needed 4 parameters, so the overhead was higher.
Note that if I was writing a recursive tree-walker now, I'd make it a 
private function, so I could keep the parameter checks only at the top 
(i.e. public) level, and recurse without repeating them.
I might even move most of the parameters into script-local variables, 
since I know the code is interrupt-safe.
With directory traversal, I'd guess the overhead of physically 
touching each inode would outweigh that manyfold.


Yeah - though it's particularly hard to test adequately. When I was 
trying to benchmark it, I found that to get consistent results, I had to 
run the test 2 or 3 times and ignore the first, highly variable, run. 
Which basically means that I was seeing results with the disk-cache 
fully engaged, and therefore likely to underestimate the importance of 
the disk operations in any real context.
Still useful to keep in mind: when inline code can do the job clearly, 
it will be more efficient.

Below is my current non-recursive walker.
NB - it goes to some trouble to allow you to pass in a relative path 
name, and maintain that in the result. That is the opposite of what is 
commonly done (i.e. using absolute path/file names); I did this to make 
it easier to compare multiple trees. If you want the traditional result, 
simply do

   put the defaultfolder into temp -- gives the absolute path
   getArrayOfFiles temp, tMyArray
but if you want "my" twist, you'd do
   getArrayOfFiles ".", tMyArray

-- Alex.
# Produce an array of folders + files with the "full" relative paths
command getArrayOfFiles pFolder, @pA, pIgnoreDotFolders, pIgnoreDotFiles
   local tFiles, tFolders
   local tThisFolder
   if pIgnoreDotFolders is empty then
  put TRUE into pIgnoreDotFolders
   end if
   if pIgnoreDotFiles is empty then
  put TRUE into pIgnoreDotFiles
   end if

   put the defaultfolder into tThisFolder

   local tAbsFolder, tFoldersLeft, tSub
   set the defaultfolder to pFolder
   put the defaultfolder into tAbsFolder   -- changes relative into 
absolute


   put CR into tFoldersLeft
   repeat until tFoldersLeft is empty
  put line 1 of tFoldersLeft into tSub
  delete line 1 of tFoldersLeft
  set the defaultFolder to (tAbsFolder & tSub)
  if the result is not empty then
 -- skip or report as needed
 next repeat
  end if
  try
 put folders() into tFolders
  end try
  if pIgnoreDotFolders then
 filter tFolders without ".*"
  else
 filter tFolders without "."
 filter tFolders without ".."
  end if
  repeat for each line L in tFolders
 put tSub & "/" & L & CR after tFoldersLeft
  end repeat

  try
 put the detailed files into tFiles
  end try

  if pIgnoreDotFiles then
 filter tFiles without ".*"
  end if
  repeat for each line L in tFiles
 put item 2 to -1 of L into pA[pFolder & tSub][item 1 of L]
  end repeat
   end repeat
end getArrayOfFiles


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Stephen Barncard via use-livecode]

there's actually a directory walker search one can use in a shell command
 on mac that is quite speedy...

let me report back.

sqb

--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

On Sun, May 6, 2018 at 2:29 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Malte Pfaff-Brill wrote:
>
> > I wonder if shelling out to DIR on Windows and LS on Linux/Mac
> > wouldn’t be the fastest option…
>
> Maybe, but there's overhead in setting up the shell session.
>
> Even if it's measurably faster, I would be surprised if it were noticeably
> faster.
>
> Anything that depends on touching the disk with each call is likely to be
> far more I/O-bound than CPU-bound.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Background Long IDs

[Brian Milby via use-livecode]

@Mark, same as before.  If the card has been visited then it starts with
group, if not it starts with bkgnd.

@Richard, probably more than you asked, but this is the project in a
nutshell...

The end goal is to enable a binary stack to have the scripts within tracked
via GitHub.  A closely related goal is to enable editing of said scripts
via an external editor.  Script only stacks are not the way that I want to
go for these projects (they are distributed as stacks and used within the
IDE as plugins).  I've got import/export working and a directory watcher
that will start an import when a file is updated.  Unlike lcVCS, this does
not attempt to do anything with tracking the other parts of the stack, just
the scripts.

Part of each file that I export includes a header with a "Script"
declaration (so they are actually valid livecodescript files).  I also
include the long ID and long name in the header as a comment.  For
backgrounds, I list all cards that contain the background.  If the object
has a behavior, then that is listed.  Objects with a behavior and no script
are also exported for the header.  The idea is that from any script file,
you can easily know what other script files are in the message path.  The
files are named by stack, object type, and ID.  I'm using an MD5 hash of
the script (including the generated header) to detect in IDE script
changes.  I'm using file modification times to track external changes.
Eventually I'll probably start using IDE messages to know about script
changes within the IDE to trigger updates.  I'll also connect the open
stack and save stack messages.

Due to the need to have a consistent file name, I decided to code my own
handler to return my version of a long name/ID for backgrounds.  I have to
detect groups that don't have a name set (since I then need to use the
ID).  I already know that the ID is for a background when I'm building the
long ID so that one was easy.  When I get to where I need the long name, I
look at the first word of the long ID and go from there (if it isn't bkgnd,
then just have the engine return it).

The exporter does a diff for each export to allow for tracking of changes
without using Git (one file per export).  My thought there is more of a
short history so I can see what I changed between saves.  It is also a kind
of safety net to allow me to back track if something didn't import like I
thought it should.

I'm sure an inevitable "why" would be asked, so I'll try answer that now.
In the IDE, the list of open stacks includes all script only stacks as
well.  If I scriptify a plugin that doesn't use "rev" named stacks, then
every object now shows as a user stack.  I can't see how having dozens or
hundreds of entries in the stack list would be good for performance.  So,
the first reason is to have text file versions of the scripts without
adding to the IDE list of open stacks.  The second reason is mentioned
above - distribution.  Having all of the code self-contained in a single
file makes moving it around much easier (this is for stacks, not compiled
applications).

I am close to being able to let others look at the project.  Initially it
will just tackle a single mainstack, but eventually I want to use it as a
plugin that can watch any number of stacks.  My intent is to put this up on
GitHub - where the scripts will be easily viewable online but the actual
stack will be a single file download.

Thanks,
Brian

On Sun, May 6, 2018 at 1:55 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Brian Milby wrote:
>
>  > I'm working on a script exporter...
>
> What do you do with the exported scripts?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \\\"Walker\\\" Available

[Richard Gaskin via use-livecode]

Bernd wrote:
> Richard wrote:
>> Which version of LC did you test with?
>> I was under the impression that since LC switched to copy-on-write
>> for all >arguments we should no longer need to use "@" for
>> performance, only for for logic.
>
>
> I tested using LC 9 GM, what kind of results do you get?

Well, so much for copy-on-write.

As written:
31
84
109
81

After removing "@":
33
95
177
93

Looks like I'll go back to the old habit of adding otherwise-unnecessary 
"@"s in time-sensitive handlers, being as careful as I used to have to 
be not to modify anything unless that's what I truly want.


Did copy-on-write get changed in v9, or is the scope of its effects just 
more limited than I had understood it to be?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Richard Gaskin via use-livecode]

Malte Pfaff-Brill wrote:

> I wonder if shelling out to DIR on Windows and LS on Linux/Mac
> wouldn’t be the fastest option…

Maybe, but there's overhead in setting up the shell session.

Even if it's measurably faster, I would be surprised if it were 
noticeably faster.


Anything that depends on touching the disk with each call is likely to 
be far more I/O-bound than CPU-bound.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \\\"Walker\\\" Available

[Niggemann, Bernd via use-livecode]

>Which version of LC did you test with?

>I was under the impression that since LC switched to copy-on-write for all 
>>arguments we should no longer need to use "@" for performance, only for for
>logic.



Richard,

I tested using LC 9 GM, what kind of results do you get?


Kind regards

Bernd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Malte Pfaff-Brill via use-livecode]

I wonder if shelling out to DIR on Windows and LS on Linux/Mac wouldn’t be the 
fastest option…

Cheers,

Malte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Richard Gaskin via use-livecode]

Bernd Niggemann wrote:

> a combination of "private" and referenced variables (@) improves the
> speed of the calls somewhat.

Which version of LC did you test with?

I was under the impression that since LC switched to copy-on-write for 
all arguments we should no longer need to use "@" for performance, only 
for for logic.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory \"Walker\" Available

[Niggemann, Bernd via use-livecode]

Alex,

a combination of "private" and referenced variables (@) improves the speed of 
the calls somewhat.

Kind regards
Bernd

--
on mouseup
   local t1, t2
   constant K = 1000
   
   local x
   constant KX = 100
   
   put the millisecs into t1
   repeat K times
  put KX into x
  repeat
 if x = 0 then exit repeat
 subtract 1 from x
  end repeat
   end repeat
   put the millisecs into t2
   put t2 - t1 & CR after msg
   
   put the millisecs into t1
   repeat K times
  put KX into x
  repeat
 if x = 0 then exit repeat
 put myfunc(x) into x
  end repeat
   end repeat
   put the millisecs into t2
   put t2 - t1 & CR after msg
   
   put the millisecs into t1
   local tA, tB, tC, tD
   put 1 into tA
   put 2 into tB
   put "333" into tC
   put "444" into tD
   repeat K times
  put KX into x
  repeat
 if x = 0 then exit repeat
 put manyParameters(x, tA, tB, tC, tD) into x
  end repeat
   end repeat
   put the millisecs into t2
   put t2 - t1 & CR after msg
   
   put the millisecs into t1
   repeat K times
  put KX into x
  recursive x
  put the result into x
   end repeat
   put the millisecs into t2
   put t2 - t1 & CR after msg
end mouseup

private function myfunc @p
   return p-1
end myfunc

private function manyParameters @p, @p1, @p2, @p3, @p4
   return p-1
end manyParameters

private command recursive @p
   if p=0 then return 0
   subtract 1 from p
   recursive p
end recursive
--
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Locating the mouse

[Richmond Mathewson via use-livecode]

Thanks Klaus: however, as you'll see, I fired off a question 2 minutes 
before I found the answer.


Nothing new there.

Richmond.

On 6/5/2018 10:31 pm, Klaus major-k via use-livecode wrote:

Hi Richmond,


Am 06.05.2018 um 21:26 schrieb Richmond Mathewson via use-livecode 
:

Yer: I know: mouseLoc

BUT, that only returns the loaction of the mouse relative to the top-left of a 
stack.
Let us suppose one has a stack measuring 100 by 100 pixels at the centre of 
one's monitor . . .
And one wants to know the position of the mouse in terms of the monitor rather 
than the stack . . .
So that one can determine IF the mouse is 100 pixels away from the left-hand 
side of the stack, or 200 pixels.
This would, of necessity, have to be in a stackScript or a cardScript and NOT 
involve any mouseClicks as that
would take focus away from the stack.

you are looking for -> the ScreenMouseLoc
Maybe monitor this property in a "mousemove" handler in the card or stack 
script...


Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Locating the mouse

[Richmond Mathewson via use-livecode]

And here he goes again: Richmond answers his own posting:

screenMouse Loc

On 6/5/2018 10:26 pm, Richmond Mathewson wrote:

Yer: I know: mouseLoc

BUT, that only returns the location of the mouse relative to the 
top-left of a stack.


Let us suppose one has a stack measuring 100 by 100 pixels at the 
centre of one's monitor . . .


And one wants to know the position of the mouse in terms of the 
monitor rather than the stack . . .


So that one can determine IF the mouse is 100 pixels away from the 
left-hand side of the stack, or 200 pixels.


This would, of necessity, have to be in a stackScript or a cardScript 
and NOT involve any mouseClicks as that

would take focus away from the stack.

Richmond.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Locating the mouse

[Klaus major-k via use-livecode]

Hi Richmond,

> Am 06.05.2018 um 21:26 schrieb Richmond Mathewson via use-livecode 
> :
> 
> Yer: I know: mouseLoc
> 
> BUT, that only returns the loaction of the mouse relative to the top-left of 
> a stack.
> Let us suppose one has a stack measuring 100 by 100 pixels at the centre of 
> one's monitor . . .
> And one wants to know the position of the mouse in terms of the monitor 
> rather than the stack . . .
> So that one can determine IF the mouse is 100 pixels away from the left-hand 
> side of the stack, or 200 pixels.
> This would, of necessity, have to be in a stackScript or a cardScript and NOT 
> involve any mouseClicks as that
> would take focus away from the stack.

you are looking for -> the ScreenMouseLoc
Maybe monitor this property in a "mousemove" handler in the card or stack 
script...

> Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Locating the mouse

[Richmond Mathewson via use-livecode]

Yer: I know: mouseLoc

BUT, that only returns the loaction of the mouse relative to the 
top-left of a stack.


Let us suppose one has a stack measuring 100 by 100 pixels at the centre 
of one's monitor . . .


And one wants to know the position of the mouse in terms of the monitor 
rather than the stack . . .


So that one can determine IF the mouse is 100 pixels away from the 
left-hand side of the stack, or 200 pixels.


This would, of necessity, have to be in a stackScript or a cardScript 
and NOT involve any mouseClicks as that

would take focus away from the stack.

Richmond.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Sean?

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

So... has anyone heard from Sean yet?


I have not.  He has not yet responded to a message I sent him on 
LinkedIn, and his last Twitter posts were just a few hours before he 
last posted here.


I sent a connection request to his partner at his company (same last 
name, presumably a relative), and will inquire with him if the request 
is accepted.


Going on four days the radio silence is disconcerting

--
 Richard Gaskin
 Fourth World Systems

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Has Anyone Got A Directory "Walker" Available

[Richard Gaskin via use-livecode]

Ah, that makes sense.  It's not so much the recursion per se, but the 
more general advantage of inline processing vs handler calls.


In the test case below you know how many levels deep you're going, which 
seems a good fit for inline loops. But how do we handle cases like 
directory traversal, where we don't know in advance how deep we'll need 
to go?


It's at least comforting to see that while the overhead of handler calls 
is significant, it's mostly in relative comparison: If I read that 
correctly, there are 1000 iterations of 100 operations, for a total of 
100k operations.  If my coffee is working, that means an overhead of 
just 0.00208 ms per operation when called in a separate handler, no? 
(thinking 273ms total for separate handler - 65ms for inline, per 100k 
operations).


With directory traversal, I'd guess the overhead of physically touching 
each inode would outweigh that manyfold.


Still useful to keep in mind: when inline code can do the job clearly, 
it will be more efficient.


--
 Richard Gaskin
 Fourth World Systems


Alex Tweedly wrote:


On 05/05/2018 01:29, Richard Gaskin via use-livecode wrote:


How does recursion impair performance so significantly?
In general, there's significant work involved in a function or handler 
call and return - you need to establish a new context for locals, copy 
or calculate, parameters, etc.  My claim that recursion is slow relative 
to a serial- or loop-based version is language-independent (though there 
might be specific exceptions like LISP :-)


Compiler writers spend considerable effort minimizing the overhead of 
function calls - but still recursion is common, and indeed recognizing 
"tail-recursion" and optimizing it away is worthwhile.


I don't know enough (i.e. I know nothing) about LC's engine, so don't 
know specifically what might be involved for LC.


But here's a minimal test case (code below)
1.  65 : serial
2. 288 : many function calls
3. 471 : same number of calls as 2, more paramters
4. 273 : same number of calls as 2, but recursive

Note : result for 2 and 4 are the same - caused by the number of calls, 
not the fact that it's recursion.

Note : 3 (same as 2 but with extra parameters) is slower.

This does point the way towards possible improvements in recursive 
solutions (and specifically in the code I used in my earlier recursive 
directory walker function). I'll try those out and see if they make a 
difference.


Anyway - here's the code that gave the above results:

on mouseup
local t1, t2
constant K = 1000

local x
constant KX = 100

put the millisecs into t1
repeat K times
   put KX into x
   repeat
  if x = 0 then exit repeat
  subtract 1 from x
   end repeat
end repeat
put the millisecs into t2
put t2 - t1 & CR after msg

put the millisecs into t1
repeat K times
   put KX into x
   repeat
  if x = 0 then exit repeat
  put myfunc(x) into x
   end repeat
end repeat
put the millisecs into t2
put t2 - t1 & CR after msg

put the millisecs into t1
repeat K times
   put KX into x
   repeat
  if x = 0 then exit repeat
  put manyParameters(x, 1, 2, "333", "444") into x
   end repeat
end repeat
put the millisecs into t2
put t2 - t1 & CR after msg

put the millisecs into t1
repeat K times
   put KX into x
   put recursive(x) into x
end repeat
put the millisecs into t2
put t2 - t1 & CR after msg

end mouseup

function myfunc p
return p-1
end myfunc

function manyParameters p, p1, p2, p3, p4
return p-1
end manyParameters

function recursive p
if p=0 then return 0
return recursive(p-1)
end recursive

-- Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Background Long IDs

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> I'm working on a script exporter...

What do you do with the exported scripts?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Multiple Quicktime driven MP3/MP4 Track Player

[Klaus major-k via use-livecode]

Hi Francis,

> Am 06.05.2018 um 19:46 schrieb Francis Nugent Dixon via use-livecode 
> :
> 
> Hi from Beautifull Brittany,
> 
> I built an app which plays indivdual MP3 and MP4 tracks from a list (one line 
> per filename).
> Simple play sequence (1 - show player - start player.  2 -  hide player - 
> stop player).
> I can stop the play function anywhere during the play sequence, but must 
> eventually  hit  "Stop"
> before manually selecting the next "Play" sequence . (I think ..).
> Now I want to hang on a multiplay sequence : choosing random line numbers to 
> play a succession of
> tracks, until the cows come home.
> How do I know that an MP3/MP4 track has ended, before stopping and starting 
> another play sequence ?
> (Please don't tell me I can calculate the duration, 'cos the strategy isn't 
> perfect and doesn't satisfy me )
> Hazy explanations using strange commands found in the dictionary and on 
> Internet, are nowhere near clear
> enough for me to code the script (I'm Irish!, although I have more than 25 
> years Hypercard and LiveCode).
> I reckon that Jacque or Klaus could come up with an answer. I have seen them 
> answering similar queries. 
> OH ! I'm on Mac 10.12.8 but only Livecode 5.5 (I'm a poor retired engineer 
> !), using Quicktime.
> 
> The answer is out there ... !!

:-)

You could use the "playstopped" message in the card or stack script to check 
which player has stopped and
take appropriate actions.

If you need to see if the sound has really ended and the player has not been 
stopped manually by your user(s),
in case you have implemented this, you could then check "the currenttime" 
against "the duration" of the player, capisce?

> -Francis

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Multiple Quicktime driven MP3/MP4 Track Player

[Francis Nugent Dixon via use-livecode]

Hi from Beautifull Brittany,

I built an app which plays indivdual MP3 and MP4 tracks from a list (one line 
per filename).
Simple play sequence (1 - show player - start player.  2 -  hide player - stop 
player).
I can stop the play function anywhere during the play sequence, but must 
eventually  hit  "Stop"
before manually selecting the next "Play" sequence . (I think ..).
Now I want to hang on a multiplay sequence : choosing random line numbers to 
play a succession of
tracks, until the cows come home.
How do I know that an MP3/MP4 track has ended, before stopping and starting 
another play sequence ?
(Please don't tell me I can calculate the duration, 'cos the strategy isn't 
perfect and doesn't satisfy me )
Hazy explanations using strange commands found in the dictionary and on 
Internet, are nowhere near clear
enough for me to code the script (I'm Irish!, although I have more than 25 
years Hypercard and LiveCode).
I reckon that Jacque or Klaus could come up with an answer. I have seen them 
answering similar queries. 
OH ! I'm on Mac 10.12.8 but only Livecode 5.5 (I'm a poor retired engineer !), 
using Quicktime.

The answer is out there ... !!

-Francis
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: error Error 0 on socket?

[Tom Glod via use-livecode]

nevermind ..the array i was "test" sending was way bigger than i thought it
was  so I am unlikely to have that problem with the regular requests i
am anticipating.  so the problems were first coming from the arraydecode
function  and then turning into that weird socket error somehow..


On Sun, May 6, 2018 at 12:13 PM, Tom Glod  wrote:

> Hi Folks, I'm getting a strange socket error when I POST some base64
> encoded data to a URL that has HTTPD Server running.
>
> Everything works fine when I send just a w bit of data... but a
> bigger chunk is giving me this error. "error Error 0 on socket"
>
> Does anyone have any idea what the size limitation is all about and how to
> get around it?
>
> Thanks,
>
> Tom
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

error Error 0 on socket?

[Tom Glod via use-livecode]

Hi Folks, I'm getting a strange socket error when I POST some base64
encoded data to a URL that has HTTPD Server running.

Everything works fine when I send just a w bit of data... but a
bigger chunk is giving me this error. "error Error 0 on socket"

Does anyone have any idea what the size limitation is all about and how to
get around it?

Thanks,

Tom
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode