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 th
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
"/U
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
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
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 a
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'
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/0
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 f
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:
> M
@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
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
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
>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
___
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
pre
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 perfo
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
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: mouseLo
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
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 mon
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 th
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, presum
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, w
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...@fou
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 -
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
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..
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
27 matches
Mail list logo
