[Resolved] A Christmas ConCat Bug (ver 7.5)

[jpuziano]

This has already been posted in the bugtracker.

Consider the following script...

Let>SK_DELAY=10

Let>blob=we three kings
Len>blob,number_of_chars

Let>newblob=
Let>k=0

Repeat>k
Let>k=k+1
MidStr>blob,k,1,char
ConCat>newblob,%char%
Until>k,number_of_chars

Send Character/Text>newblob

***

You might think this script would output:

we three kings

...but instead, it outputs:

we three 10ings

The MidStr command works properly, when k=10
it pulls out a k so char=k but then when it hits

ConCat>newblob,%char%

...instead of adding on the letter k, it sees that
a variable called k also exists so it adds on
the value of the variable k instead, adds on 10.

I would like to propose that if the second
parameter of the ConCat command is a variable
surrounded by percent % signs, that it simply
substitute the contents of that variable
and leave it at that. What do you think?

Thanks and Merry Christmas

[support]

Hi,

Add the following line to the top of the script to stop this happening:

Let>VAR_EXPLICIT=1

Not a bug.

[jpuziano]

Thanks for the fast reply. OK, I added...

Let>VAR_EXPLICIT=1

to the top of the script, ran it, bug still there.

It it still comes out as:

we three 10ings

???

[support]

And remove the % signs from char. You only need these if you embed variables:


Let>VAR_EXPLICIT=1
Let>SK_DELAY=10

Let>blob=we three kings
Len>blob,number_of_chars

Let>newblob=
Let>k=0

Repeat>k
Let>k=k+1
MidStr>blob,k,1,char
ConCat>newblob,char
Until>k,number_of_chars


char is on it's own so the % symbols are not necessary.

[jpuziano]

Actually, I found that adding

Let>VAR_EXPLICIT=1

wasn't needed. All I had to do was remove the % signs from char
and it would work as expected... however... that does not explain
why it did the extra substitution (used 10 instead of k) when I did
use %char%.

From your replies and reading the Help, it seems we should only be
using percent signs (%) around variables if we are using EXPLICIT mode
which we can turn on by adding this line in our script:

Let>VAR_EXPLICIT=1

Are you saying then, that percent signs around a variable have no
meaning (or effect) in default mode (when VAR_EXPLICIT=0)?

This cannot be the case, it does make a difference because changing
%char% to char in my example script produces different results.

There is still something strange going on here. At this point, I don't
know if its just with the ConCat command or a problem with variables
in general but here's another example...

This time, no percent signs are used and we'll just leave
VAR_EXPLICT in default mode (0):

Let>newblob=
Let>a=b
Let>b=c
Let>c=d

ConCat>newblob,a
ConCat>newblob,b
ConCat>newblob,c

Send Character/Text>newblob

---

I would expect this to output:

bcd

but instead, it outputs:

ccd

The question is why?

The problem must be happening when it hits the line:

ConCat>newblob,a

- it should find that "a" exists as a variable
- it should look up variable "a" and find that the value is "b"
- it should add a letter "b" to newblob but for some reason... it doesn't
stop there... it makes another substitution... and I'm assuming it
looks for a variable named "b", finds it exists and its value is "c"
and uses that.

But why is it doing this? Surely this is not expected behaviour...
or have I had too much Christmas eggnog?

[support]

et>newblob=
Let>a=b
Let>b=c
Let>c=d

ConCat>newblob,a
ConCat>newblob,b
ConCat>newblob,c

Send Character/Text>newblob

---

I would expect this to output:

bcd

but instead, it outputs:

ccd

The question is why?

Because:

If you set a to b and b to c then a=b=c. Therefore a=c. It is simple logic.

[support]

From your replies and reading the Help, it seems we should only be
using percent signs (%) around variables

- Use % symbols when embedding variables within strings (regardless of VAR_EXPLICIT), e.g.:

Let>name=fred
Let>msg=his name is %name%

- Use % symbols when using VAR_EXPLICIT=1 to resolve the value as a variable rather than a literal:

In this version a would equal "Name" where b would equal "Fred"

Let>VAREXPLICIT=1
Let>Name=Fred
Let>a=Name
Let>b=%Name%

Whereas here both a and be become "Fred"

Let>VAREXPLICIT=0
Let>Name=Fred
Let>a=Name
Let>b=%Name%

[jpuziano]

Let>newblob=
Let>a=b
Let>b=c
Let>c=d

ConCat>newblob,a
ConCat>newblob,b
ConCat>newblob,c

Send Character/Text>newblob

---

I would expect this to output:

bcd

but instead, it outputs:

ccd

The question is why?

Because:

If you set a to b and b to c then a=b=c. Therefore a=c. It is simple logic.

First off, I found that these two statements address the same variable:

Let a=1
Let A=2

There is only one variable created, the debugger shows it as A.
After the first statement, A=1
After the second statement, A=2
...so I'll just use capitals in variable names from here on in.

Note: I looked but couldn't find anything saying that variable names
are automatically converted to Upper Case. Is this in the Help Files
somewhere? If not, perhaps it should be.

Anyway, back to the issue at hand...

I don't agree, the values of variables A & B & C are definitely not equal
to each other because of the order of the Let> statements.

I agree that if the Let> statements were in reverse order, that would
be true in which case I'd expect variable assignments to go like this:

1. Let>C=d
at this point, there is no var D so var C = the letter "d"

2. Let>B=c
var C exists, its value is "d" so var B = the letter "d"

3. Let>A=b
var B exists, its value is "d" so var A = the letter "d"

However, what I have is this:

1. Let>A=b
there is no var B (or b) at this point so var A = the letter "b"

2. Let>B=c
there is no var C (or c) at this point so var B = the letter "c"

3. Let>C=d
there is no var D (or d) at this point so var C = the letter "d"

And the Macro Scheduler debugger confirms the above.
Here's what I found using the debugger:

after executing the Let> statements:

C=d
B=c
A=b
NEWBLOB=

Note that each variable has a separate and unique value.

after executing ConCat>newblob,a
C=d
B=c
A=b
NEWBLOB=b

That's exactly as I would expect...

after executing ConCat>newblob,b
C=d
B=c
A=b
NEWBLOB=cc

It adds on var B which is a letter "c" onto the end and that's OK but...
*WHY* did the first letter (added by the previous ConCat statement)
magically change from the letter "b" to the letter "c"

this is not documented behavior for ConCat
ConCat should only be adding onto the end of newblob
it should never mess with the characters that are already in newblob
this is the bug I'm trying to point out

after executing ConCat>newblob,c
C=d
B=c
A=b
NEWBLOB=ccd

It adds on var C which is a letter "d" onto the end and that's OK.

After the script has run, the debugger still shows the variables like this:

C=d
B=c
A=b

Once set, these values did not change at all. However, when I try
to use ConCat> statements to build a string consisting of the values
of three variables, expecting to get:

bcd

because of the way ConCat is behaving, I get this instead:

ccd

...and there you have the Christmas ConCat bug.

Has anyone else out there experienced any strange ConCat behavior?
Write in if you have and thanks in advance...

[support]

It adds on var B which is a letter "c" onto the end and that's OK but... *WHY* did the first letter (added by the previous ConCat statement)
magically change from the letter "b" to the letter "c"

Because NEWBLOB is now b, and variable b is equal to value c.

The point is that everything is seen as a variable unless you turn VAR_EXPLICIT on. It keeps resolving. So first time NEWBLOB=b, next time it is referenced it resolves b to c because variable b equals c (b=c, NEWBLOB=b, therefore NEWBLOB=c, add c to it, we now have NEWBLOB=cc. Logic cap'n). You are saying there is a problem but if you follow your scenario through logically it is correct.

I would avoid using the ConCat command if you find this confusing. You can concat more simply with the Let command:

Let>a=1
Let>b=2
Let>newblob=%a%%b%

To avoid confusion with everything being resolved as variables use VAR_EXPLICIT=1. Then ensure you use % symbols when you want to use a variable and omit them when you want the literal value.