math.or() and math.and() cause parsing errors

[Mark F]

The title says it all. The following cause parsing errors:


temp = math.and(3,1)
temp = math:and(3,1)
temp = math.or(3,1)
temp = math:or(3,1)


Both of these appear as functions on the math object. Am I doing something wrong?

[Promixis]

Yes...

they are keywords so you need..

math ["or"] to make them work !!!


BTW, we are going to fix this today ;)

[Mark F]

Yup, math["or"] and math["and"] work. I should have thought of that. :(

I'll use that until the fix is ready.

Thanks. (The X10 FireCracker is now supported by the new Serial plugin)

[Ron]

Great news Mark!

The fix is uploading as we speak!

[Mark F]

Should the new A7 work on Win '98? (with the wrapper in place)

I'd rather not install just to start the rebooting madness again. :)

[Ron]

I have been testing it on my Win98 VirtualPC and it runs just fine there now. I will be testing every release on Win98 too now.

[Mark F]

Fix confirmed. :D

[Mark F]

Right now, there are 6 methods of the math object that work at the bit level:
band, bor, xor, shiftl, shiftr, bitnot

Could they have more consistant names? Maybe all of them could either start with b or bit? I think this would make them easier to remember when writing code and answering questions.

Although the help file says the mod function is also a Girder extension of the math object, math.mod is included in the LUA 5 distribution.

[Ron]

That sounds like a good idea Mark, I'll also remove the Girder mod.

- Ron