ID:80701
 
Resolved
The ASSERT() macro did not compile correctly when provided a list index, e.g. ASSERT(L[i]).
BYOND Version:454
Operating System:Windows Vista Ultimate
Web Browser:Firefox 3.5.2
Applies to:DM Language
Status: Resolved (475)

This issue has been resolved.
Descriptive Problem Summary:
You can use ASSERT() on most things, including lists, to make sure that something is what you need to be. However, if you try to ASSERT() a list index, you get a load of syntax errors

Code Snippet (if applicable) to Reproduce Problem:
mob/verb/Test()
var/list/L = params2list("a&b&c&d&e&f")

for(var/i in 1 to L.len)
ASSERT(L[i]) // this line causes it to fail


Expected Results:
This would ASSERT() each element in the list.

Actual Results:
*.dm:5:error: ]: expected )
*.dm:5: unterminated text (expecting ")
*.dm:5: Inconsistent indentation or missing '}'.
*.dm:5:error: bad embedded expression []
*.dm:5:error: ]: expected }
*.dm:5:error: location of top-most unmatched {
*.dm:5:error: ]: expected }
*.dm:5:error: location of top-most unmatched


Workarounds: Use a temporary variable
mob/verb/Test()
var/list/L = params2list("a&b&c&d&e&f")

for(var/i in 1 to L.len)
var/temp = L[i]
ASSERT(temp)


In that list, I don't see anything that should fail, but, also, I got it working like this, so, why are you doing it like that?

mob/verb/Test()
var/list/L = params2list("a&b&c&d&e&f")
for(var/i in L)
ASSERT(i)


But, I don't see anything that should fail an assert there.
Superbike32 wrote:
But, I don't see anything that should fail an assert there.

The ASSERT isn't failing. The compiler is failing.
Well, you could use ASSERT(i) in your specific case there, and it will ASSERT like you are wanting it to, so, I don't see why you're trying to use ASSERT(L[i]) instead.

Anyways, for a bug i've found since testing your stuff here myself, if you try and combine a normal list and params2list() then it will fail, but, the best I see in yours is that you should change ASSERT(L[i]) to ASSERT(i), as this is working for me.
Superbike32 wrote:
I don't see why you're trying to use ASSERT(L[i]) instead.

Because I am, there's a reason for that functionality. Consider that you need to modify the value of some number at position i in the list. You write up this code:
mob/verb/Test()
var/list/L = list(1,2,3,4)

for(var/i in 1 to L.len)
ASSERT(isnum(L[i]))

L[i] = L[i] + 1

If you try for(var/i in L) you can't do this.

You're presented with 8 errors, though nothing is wrong with the code. So if this was intermixed with much, much more code (which it was when it happened to me), it may be hard to figure out that the reason why you're getting errors is because the compiler is failing and that you've actually done nothing wrong.
Here is a working piece of that same code.

var/list/L = list(1,2,3,4)
mob/verb/Test()
var/count
for(var/i in L)
ASSERT(isnum(i))
L[++count] = i + 1
mob/verb/Display()
world<<""
for(var/i in L)
world<<i
world<<""


On your original code, L[i] would be passing whatever number it is in the list, not it's position, so once one of the numbers becomes 5, and there is not that many items in the list, it would error, even if that code did compile.

The only way it would work, is if you used Find() on the element i, but I think a counter works just as well, so I saw no point to make it search when it could simply just know the location.

Plus, Find() could return an earlier item if two of the same number were in the list.

EDIT:Well, just to take back what I said, your code might work if it compiled, but the other way I mentioned here works, and it seems to be pretty speedy, finishes with 0.0000 with debug on for over 5000 items in the list, I do have an OK computer though, quad core 1.80 GHZ, but given BYOND uses mostly only one core, I don't see that it is an issue.
Superbike32 wrote:
Here is a working piece of that same code.

You are stupid, my friend. I'm not reporting this because I failed to write some code to accomplish what I was trying to do. See the Workarounds part of the original bug report? Yeah, it's easy to make it work.

The point is that there is an error in the compiler. If someone's programming, their program fails to compile at no fault of their own, and it may not be easy to spot why it's not working if it's part of a large program.

Your "working piece of that same code" is overly complicated just so that you can do for(var/i in L)
Kuraudo wrote:
Superbike32 wrote:
Here is a working piece of that same code.

You are stupid, my friend. I'm not reporting this because I failed to write some code to accomplish what I was trying to do. See the Workarounds part of the original bug report? Yeah, it's easy to make it work.

The point is that there is an error in the compiler. If someone's programming, their program fails to compile at no fault of their own, and it may not be easy to spot why it's not working if it's part of a large program.

Your "working piece of that same code" is overly complicated just so that you can do for(var/i in L)

Overly complicated? Mine is easy, all it does is add in the counter so it knows what position it is in, plus, to add in, it needs to know what the data is, so regardless of whether you hold the L[i] variable in another, or hold the counter into one, it ends in the same result, it just then becomes a matter of which is faster.

So, even if that is part of a large program, you should know what you recently changed, so that part becomes a non-issue.

If it compiled in previous versions, your bug report should've said that, but unless it compiled before and now doesn't, it is not an issue as per being part of a large program, because, they will know they touched that code recently, and will try just removing it.
Let's not make me need to ban someone over a bug report.