Re: Background Long IDs
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
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
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
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
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
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
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
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
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
@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
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
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
>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
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
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
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
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
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
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
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?
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
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
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
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
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?
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?
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