Netlinx Compiler Bugs

AMXJeff

After seeing that strange bug that the NetLinx compiler did not catch. I thought it a good idea to have a thread that we can all show the strange things that the NetLinx compiler catches and in turn misses. So have at it, maybe this will lead to some fixes.

yuri

AMXJeff wrote: »

So have at it, maybe this will lead to some fixes.

this made me laugh

yuri

I spent hours today diagnosing a problem that could have been solved by moving a right parenthesis back 5 spaces.

The issue was, after I issued a system off command to my ADA Suite16 (SWITCH=0:0), the module for the Suite16 would not execute any other commands, responding COMMAND ERROR to each one. I had to reboot the master each time this happened. The Suite16 was in perfect condition - there is a seperate program supplied by ADA to test it. The module was just not passing on any hex strings to the ADA Bus as it should. An AMX Tech had me grab the latest Suite16 module (a Duet one), because I was using an old one. Replacing the module didn't help. As it turns out, when I used Control a Device... on NS to send the command, it was fine, but when I used my touchpanel, it was not.

Here's my button code. See if you can find the mistake. If so you're doing better than the NetLinx compiler did!
Code:

BUTTON_EVENT[arrTP,butHOUSE_OFF]{
PUSH:{
SEND_COMMAND vdvADA_SUITE16, 'SWITCH=0:0'
//SEND_COMMAND vdvAMP_FAMILY_ROOM, 'POWER=0' // amp off
//SEND_COMMAND vdvDVD_FAMILY_ROOM, 'POWER=0' // dvd off
//SEND_COMMAND vdvDVD_MASTER_BED, 'POWER=0' // dvd off
//SEND_COMMAND dvLG_DEN, "'ka 1 0',$0D" // tv off
//SEND_COMMAND dvLG_MASTER_BED, "'ka 1 0',$0D" // tv off
//ADA_QUEUE_EMPTY()
}
RELEASE:{
if(GET_LAST(arrTP != 3)){ // don't unset selection for R4
nRoomsSelected[GET_LAST(arrTP)] = 0;
nTP_Activity[GET_LAST(arrTP)] = 0; // no activity
}
}
}

I'm amazed that this compiled and I have no idea how it affected the code inside the Suite16 module. It's the most elegant bug I've seen not only in NetLinx but maybe in all programming.

as posted by mpullin

Joe Hebert

Flag duplicate function names

Normally when writing code I have a trigger happy compile finger. Whenever I add a function or two or add any significant code I compile to make sure I didn?t screw anything up.

On this particular occasion I was on a cut and paste rampage, adding include files, basically working with code I already trusted. When I finally decided to compile I got the following error.

ERROR: (0): C10580: Internal Error: Major system error occurred during code generation

That error was all I had to go on (no line numbers no nothing) so I started retracing my steps commenting out code that I added until I had the slap my palm into my forehead moment when I realized I had duplicate function names in two different include files.

Anyhow I think the compiler should be smart enough to realize it ran into a duplicate function name and flag the user with the file name and line number instead of generating the major system error with no clue on what to look for.

Thanks.

AMXJeff

Variables in Functions

Here is a fun one...

// ERROR: C:\asd.axs(50): C10201: Syntax error; Illegal or Invalid syntax in code 
DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest
	
	[dvRelay,1] != [dvRelay,1]
}

// Fixed, The compiler thought the first square bracket was part of the variable decleration...
DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest; // <----- Added Semi Colon
	
	[dvRelay,1] != [dvRelay,1]
}

Joe Hebert

Yup, that's an oldie but a goodie. I don't really consider it a compiler bug though but it's definitely a gotcha.

http://www.amxforums.com/showpost.php?p=3587&postcount=5

AMXJeff wrote: »

Here is a fun one...

// ERROR: C:\asd.axs(50): C10201: Syntax error; Illegal or Invalid syntax in code 
DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest
	
	[dvRelay,1] != [dvRelay,1]
}

// Fixed, The compiler thought the first square bracket was part of the variable decleration...
DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest; // <----- Added Semi Colon
	
	[dvRelay,1] != [dvRelay,1]
}

a_riot42

if(GET_LAST(arrTP != 3)){ // don't unset selection for R4

This line doesn't look correct. You are passing a boolean to get_last? How is that going to work?
Paul

a_riot42

AMXJeff wrote: »

Here is a fun one...

DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest
	
	[dvRelay,1] != [dvRelay,1]
}

I can't get either of those examples to compile. Don't you mean [dvRelay,1] =! [dvRelay,1]? I don't know what [dvRelay,1] != [dvRelay,1] could mean in that context even with a semi-colon.

[dvRelay,1] =! [dvRelay,1] should really be written as [dvRelay,1] = ![dvRelay,1] so that it is clear what is being negated.
Paul

DHawthorne

a_riot42 wrote: »

if(GET_LAST(arrTP != 3)){ // don't unset selection for R4

This line doesn't look correct. You are passing a boolean to get_last? How is that going to work?
Paul

It can't, that was the problem. The point is, the compiler didn't catch it.

jweather

I think you're expecting too much of the poor compiler, personally... compiler error messages are notoriously hard to generate accurately, and it's nearly impossible to get the line numbers correct. You should be grateful it's giving you a line number and not just an "internal error" like Joe ran into (I agree that one should be fixed) I'd much rather see the effort be put into fixing some of the actual bugs in Studio.

yuri

jweather wrote: »

I think you're expecting too much of the poor compiler, personally... compiler error messages are notoriously hard to generate accurately, and it's nearly impossible to get the line numbers correct. You should be grateful it's giving you a line number and not just an "internal error" like Joe ran into (I agree that one should be fixed) I'd much rather see the effort be put into fixing some of the actual bugs in Studio.

if you see the difference between axcent compiler errors and netlinx compiler errors i'm very gratefull it has 'advanced'. Still, those 'silly' compiler errors should be fixed

richs

Another miss or two

The compiler accepted the line below, which I copied from another programmer's code, thinking it elegant:

IF (7 < nTIMEHOUR < 19)
{
...do something...
{

The compiler accepts this just fine, but the parenthetical expression appears to evaluate at run time to true, regardless of value of the integer nTIMEHOUR.
I put back the code I had in the first place - IF ((nTIMEHOUR > 7) && (nTIMEHOUR < 19)) and all worked well again. I asked the other fellow about this and he mumbled something vague ....

BTW, I did also find another problem with this same routine - I originally named the variable nHOUR, and the routine did not work (with the correct version of the code). In debugging I found that nHOUR appeared to always be zero even right after the statement nHOUR = TIME_TO_HOUR (TIME); it appears that nHOUR is used somewhere in the system routines and so created a conflict, a problem which the complier did not have the grace to inform me. Changing the variable name solved the problem.

I have also gotten the "general system error" message, several times. I forget what I did but I recall it was obvious when I did realize it; perhaps it was duplicate functiion or subroutine names.

a_riot42

richs wrote: »

The compiler accepted the line below, which I copied from another programmer's code, thinking it elegant:

IF (7 < nTIMEHOUR < 19)
{
...do something...
{

I wouldn't expect this to work as you think. I am guessing the compiler evaluates 7 < nTIMEHOUR first, and the result would be either 0 or 1 depending on the value of nTIMEHOUR, and then evaluates 0 or 1 < 19 which of course is always true. While you cannot expect the compiler to stop poor programming practise I do expect it to do what the docs say it does, which is often is not the case.
Paul

mpullin

a_riot42 wrote: »

I wouldn't expect this to work as you think. I am guessing the compiler evaluates 7 < nTIMEHOUR first, and the result would be either 0 or 1 depending on the value of nTIMEHOUR, and then evaluates 0 or 1 < 19 which of course is always true. While you cannot expect the compiler to stop poor programming practise I do expect it to do what the docs say it does, which is often is not the case.
Paul

I agree, I think the programmer that showed you that was trying to sell you some snake oil. The notation a < b < c should stay in a math classroom :-|

Chip Moody

Guess I'm just too old skool for this. I never would have considered that, and instead done

[Relay,1] = ![Relay,1]

Or to be even more anal-retentive (picture me waving):

[Relay,1] = (![Relay,1])

I've gotten parenthetically anal retentive and do stuff like that by default, having been bitten by more complex evaluations that get past the compiler, but don't give the result I want. I figure if I'm going to have to be that specific in larger evaluations, I'll be that specific in the smaller ones just to keep the habit.

And while we're talking about old school-ness, get rid of all that "dvThis" and "dvThat" crap. Talk about extra typing that doesn't help anything. If I can't tell from looking at the identifier name that it's representing a variable or a device, I think I've got bigger issues.

Same goes for variables.

- Chip (Crotchety old programmer)

AMXJeff wrote: »

Here is a fun one...

// ERROR: C:\asd.axs(50): C10201: Syntax error; Illegal or Invalid syntax in code 
DEFINE_FUNCTION Test()
{
	STACK_VAR INTEGER nTest
	
	[dvRelay,1] != [dvRelay,1]
}

SCOTTYP

ERROR: (0): C10580: Internal Error: Major system error occurred during code generation

I had this one too, it ended up being two functions with same name...both in my main program.