Peter TB Brett writes:
> Just to be entirely clear -- this is not a problem with the LiveCode
> script parser. It's working just fine.
>
> The problem lies in the way that chunk expressions are handled when the
> script is _running_, i.e. during execution.
Er... yes... sorry, that's what I r
On 06/06/2016 22:32, Mark Wieder wrote:
Mark-
Thanks so much for adding insight to this discussion. You raise some
very interesting points here.
And I realize the parser is the problem here, so I'd only add that
Just to be entirely clear -- this is not a problem with the LiveCode
script pars
Mark-
Thanks so much for adding insight to this discussion. You raise some
very interesting points here.
And I realize the parser is the problem here, so I'd only add that
function addOneToIndex
add 1 to sIndex
return sIndex
end function
would be an error in functional progr
I tried to make LiveCode crash fiddling with side-effects using this. So far,
I have not been able to. As most of us have come to realize; there are some
very smart people in Scotland.
This is a very handy feature. I usually use a functional style (using lots of
simple, pure functions) but
> On Jun 6, 2016, at 11:06 AM, Mark Waddingham wrote:
>
> variable sIndex
>
> command whatShouldThisDo? sInput
>add char sIndex of line addOneToIndex() of sInput to tSum
> end command
>
> function addOneToIndex
>add 1 to sIndex
>return sIndex
> end function
My eyes see sIndex
> On Jun 6, 2016, at 11:06 AM, Mark Waddingham wrote:
>
> This is because we changed the way that array subscripting operations work
> then they are used as a container (i.e. read/write) so that the 'path' to the
> element is only evaluated once. A side-effect of this was that we were able
>
Hi Quentin,
I just thought I'd sum up the situation with this bug and provide a
little more explanation.
On 2016-06-05 16:12, Quentin Long wrote:
...
This handler *should* end up generating a 16-item string of integers
which sum to exactly 100. What it *actually does* end up generating,
is a
Hi
Just read further back through the thread and looks like Monte has a handle
on it
I’ve taken a little look into it and yes it does appear the chunk is being
> evaluated twice: Add left to right
> - get value to add by and evaluate chunk if any
> - get destination value and evaluate chunk if an
HI It looks to me that the ANY command/function is reusing a global
variable of some type
or if there is an optimizing stage it is reusing the "register" whether in
the bytecode interpreter instructions
or the bytecode interpreter per se.
The larger the number the items reach a limit which I would
> On 6 Jun 2016, at 06:33, Monte Goulding wrote:
>
> Hmm… certainly an interesting idea:
>
> put 1,2,3 into tVar
> myAdd 5, item 3 of tVar
>
> command myAdd pToAdd, @xAddTo
> put pToAdd+xAddTo into xAddTo
> end myAdd
>
> tVar = 1,2,8
>
> I doubt we should get our hopes up Dar ;-)
>
> Of c
> On 6 Jun 2016, at 3:15 PM, Dar Scott wrote:
>
> The problem is more general than the use of any and random(). It applies to
> functions with side effects.
>
> And if the compiler is allowed to combine like-looking expressions (as in
> your example), it should prove that there can be no s
The problem is more general than the use of any and random(). It applies to
functions with side effects.
And if the compiler is allowed to combine like-looking expressions (as in your
example), it should prove that there can be no side effects.
One solution would be to allow the building o
> On 6 Jun 2016, at 12:47 PM, Mark Wieder wrote:
>
> Turns out an additional note was needed to cover "any".
I am less concerned about the quirky behavior of any and random chunks
considering it is easy to work around it than I am about the re-evaluation of
the chunk expression which could be
This double-evaluation bug has existed since MC v4.2 (the earliest engine I
have immediately to hand).
[snip]
on mouseUp
put "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" into myVar
repeat 1000
add zero to any item of myVar
end repeat
put myVar
end mouseUp
[/snip]
Hugh Senior
FLCo
On 06/05/2016 05:04 PM, Monte Goulding wrote:
I suspect not. I didn't realise one was open ;-)
Turns out an additional note was needed to cover "any".
http://quality.livecode.com/show_bug.cgi?id=7919
http://quality.livecode.com/show_bug.cgi?id=17795
--
Mark Wieder
ahsoftw...@gmail.com
On 06/05/2016 05:00 PM, Dar Scott wrote:
I missed Mark's comment. Sorry about poking at this while it was actually
understood.
Actually, I thought you came up with some very interesting nuances.
These should make it into the test suite.
--
Mark Wieder
ahsoftw...@gmail.com
___
une 05, 2016 3:14 PM
To: How to use LiveCode
Subject: Re: Cubist's first bug report
I opened the dictionary. I didn't need to select the API tab or the
LiveCode Script API, those were selected. I typed "any" in the search box,
but did not hit return or click the search button.
I suspect not. I didn't realise one was open ;-)
Sent from my iPhone
> On 6 Jun 2016, at 9:52 AM, Mark Wieder wrote:
>
> There are two bug reports on this already. Do you need a third?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Pleas
> On Jun 5, 2016, at 5:52 PM, Mark Wieder wrote:
>
> Yes, I believe that's the gist of LCMark's comment in the bug report.
Ah, looks like they have it on the run.
I missed Mark's comment. Sorry about poking at this while it was actually
understood.
Dar
On 06/05/2016 04:03 PM, Monte Goulding wrote:
I’ve taken a little look into it and yes it does appear the chunk is being
evaluated twice:
Yes, I believe that's the gist of LCMark's comment in the bug report.
Please submit a bug report so we can look into it further...
There are two bug repo
965561
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Dar Scott
> Sent: Sunday, June 05, 2016 3:14 PM
> To: How to use LiveCode
> Subject: Re: Cubist's first bug report
>
> I opened the dictionary. I did
> On 6 Jun 2016, at 6:06 AM, d...@swcp.com wrote:
>
> I suspect that random(16) is being evaluated twice based on a first glance
> at the pattern.
I’ve taken a little look into it and yes it does appear the chunk is being
evaluated twice:
Add left to right
- get value to add by and evaluat
65561
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Dar Scott
Sent: Sunday, June 05, 2016 3:14 PM
To: How to use LiveCode
Subject: Re: Cubist's first bug report
I opened the dictionary. I didn't need to select the API tab or t
> On Jun 5, 2016, at 2:26 PM, [-hh] wrote:
>
> And this, not this much funny, creates a CRASH (showing "inf"):
> on mouseUp
> put "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" into myVar
> repeat 1000
>add 1 to item (any item of myVar) of myVar
> end repeat
> put myVar into fld 1
> end mouse
; is new to me, I have to explore it and its uses.
>>
>> Sincerely,
>>
>> Clarence Martin
>> Email: chi...@themartinz.com
>> Cell: 626 6965561
>>
>> -Original Message-
>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com]
On 05/06/16 23:06, Jerry Jensen wrote:
I just spent a few minutes in the 8.0.1 dictionary and did not find it. That thing
is useless! Maybe its because I’m new to 8, but where is “any" documented? How
in the world does one find it?
.Jerry
https://livecode.com/resources/api/#livecode_script/an
me, I have to explore it and its uses.
>
> Sincerely,
>
> Clarence Martin
> Email: chi...@themartinz.com
> Cell: 626 6965561
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Quentin Long
> Sent: Sund
livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Quentin Long
> Sent: Sunday, June 05, 2016 7:12 AM
> To: use-livecode@lists.runrev.com
> Subject: Cubist's first bug report
>
> Code which exhibits the bug:
>
> on mouseUp
> put "0,0,0,0,0,
o explore it and its uses.
Sincerely,
Clarence Martin
Email: chi...@themartinz.com
Cell: 626 6965561
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Quentin Long
Sent: Sunday, June 05, 2016 7:12 AM
To: use-livecode@lists.runrev.com
Su
Dar Scott wrote
> on mouseUp
>put "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" into myVar
>repeat 1000
> add zero to any item of myVar
>end repeat
>put myVar
> end mouseUp
Your example is really convincing, nothing to say more.
This introduces, still funny, some variation:
on m
on mouseUp
put "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" into myVar
repeat 1000
add zero to any item of myVar
end repeat
put myVar
end mouseUp
> On Jun 5, 2016, at 2:06 PM, d...@swcp.com wrote:
>
> Just for fun:
>
> on mouseUp
> put LF into newLine
> put 0 into sRandomCount
Just for fun:
on mouseUp
put LF into newLine
put 0 into sRandomCount
put "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16" into myVar
repeat 100
add zero to any item of myVar
put myVar & newLine after myTempList
end repeat
put sum(myVar) & newLine & myTempList
end mouseUp
Here's a script (derived from Mark's) that illustrates the double call:
local sRandomCount
on mouseUp
put LF into newLine
put 0 into sRandomCount
put "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" into myVar
repeat 100
add 1 to item myrandom(16) of myVar
Very good test!
I mentioned in crossed email that I suspect reevaluation. Since the problem
shows up with item and not array subscripts, I would suspect the reevaluation
is done to avoid some problem. Even so, the item number should be computed
once and saved even if the character location in
Very nice and clean example code.
Also, as you hinted, this does have the problem:
add 1 to item random(16) of myVar
I infer from this that the problem is very likely not in how 'any' counts
items.
This also applies to subtract and multiply. I suspect that random(16) is being
eval
What's the culprit for that? I dare say:
= It's not the random (as Mark S. proved with his example)
= It's not a random-incompatible "add" (see example below)
It is the basic problem that LC has with counting items,
lines, words or other chunks. The number of is
defined in a logically inconsiste
Hi Quentin,
I see the same results, when I try your code. However, if I first store
the random value and add 1 to an item in the string in the next line in
the script, it works correctly. Apparently, the random function and the
add command are incompatible.
on mouseUp
put "0,0,0,0,0,0,0,0
On 06/05/2016 07:12 AM, Quentin Long wrote:
This handler *should* end up generating a 16-item string of integers which sum
to exactly 100. What it *actually does* end up generating, is a 16-item string
of integers whose sum may or may not fall somewhere within the range 80-120.
Not sure what
Code which exhibits the bug:
on mouseUp
put "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" into Fred
repeat 100 times
add 1 to any item of Fred
put Fred into line (1 + the number of lines in fld "testbed") of fld
"testbed"
end repeat
put sum (Fred) into line (1 + the number of lines in
39 matches
Mail list logo
