Re: Cubist's first bug report

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...

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Element as @ parameter (was Re: Cubist's first bug report)

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)

Re: Cubist's first bug report

> 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

Re: Cubist's first bug report

> 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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Fun (was Re: Cubist's first bug report)

> 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

Re: Fun (was Re: Cubist's first bug report)

> 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

Re: Fun (was Re: Cubist's first bug report)

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

Re: Fun (was Re: Cubist's first bug report)

> 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

Re: Cubist's first bug report

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

Re: Fun (was Re: Cubist's first bug report)

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

Re: Fun (was Re: Cubist's first bug report)

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

Re: Cubist's first bug report

ar Scott Sent: Sunday, June 05, 2016 3:14 PM To: How to use LiveCode <use-livecode@lists.runrev.com> 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

Re: Fun (was Re: Cubist's first bug report)

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

Re: Fun (was Re: Cubist's first bug report)

> 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

Re: Fun (was Re: Cubist's first bug report)

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

Re: Cubist's first bug report

z.com > Cell: 626 6965561 > > -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 <use-livecode@lists.runrev.com> > Subject: Re: Cubist's f

Re: Fun (was Re: Cubist's first bug report)

> 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

RE: Cubist's first bug report

--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 <use-livecode@lists.runrev.com> Subject: Re: Cubist's first bug report I opened the dictionary. I didn't need to se

Re: Fun (was Re: Cubist's first bug report)

> 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

Re: Cubist's first bug report

estion, but when I see something that >> 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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

uentin 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,0,0,0,0,0,0,0,0,0,0,0" into Fred > repeat 100 times > add 1 to any

Re: Cubist's first bug report

to: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,0,0,0,0,0,0,0,0,0,0

RE: Cubist's first bug report

lore 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 Subject

Re: Fun (was Re: Cubist's first bug report)

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

Re: Fun (was Re: Cubist's first bug report)

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

Fun (was Re: Cubist's first bug report)

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Re: Cubist's first bug report

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

Cubist's first bug report

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