Can't initialize an instance of the Encoder class

[arilotter]

I can't seem to initialize the Encoder class at all; I'm being thrown a "TypeError: 'int' object is not iterable."
I've simplified my robot code to the bare minimum to trigger this problem:

import wpilib
from wpilib import Encoder, IterativeRobot

class TestRobot(IterativeRobot):
    def robotInit(self):
        Encoder(0, 1)

if __name__ == "__main__":
    wpilib.run(TestRobot)

And here's the full log from my console

https://gist.github.com/aerobit/37ad61b750b8e11b555e

[computer-whisperer]

This is interesting. The problem only occurs when run on a real RoboRIO. I'm looking into this.

[virtuald]

Thanks @computer-whisperer !

[computer-whisperer]

Here is what I have so far.

The method in question is hal.initializeEncoder. The c function is supposed to return a hal_impl.types.Encoder object, as well as an integer value it returns via argument pointer. However, Hal_roborio's _RETFUNC Appears to be only returning the pointer value, and not the Encoder object. This problem exists with several hal functions I have tried.

Past that it is difficult for me to figure out what the intended behavior of this gadgetry is. Perhaps @virtuald or @PeterJohnson could take a look at it?

[virtuald]

Thanks for looking, I'll look too in a few minutes.

[virtuald]

Ok, finally looked at this. I suspect there's a problem with things that have 'out' parameters, as calling hal.initializeMutexNormal() returns a proper object. I'll look some more, but perhaps @PeterJohnson has ran into this previously.

[virtuald]

Ok, after going through the ctypes documentation it appears that if you setup an output parameter, then ctypes no longer returns the result, but only returns the output parameter. If you set up an 'errcheck' function, then you can customize the return values to whatever you want. I don't really like the overhead of adding an extra function call, but that might be the best way to go about this. Maybe we could use a bunch of eval'ed statements.. ;)

This is definitely a major bug, thanks for finding it!

[virtuald]

I'm out of brainpower for the night, off to bed for me.

[PeterJohnson]

I'm working on it.

[PeterJohnson]

Fixed in 095df78

[virtuald]

Thanks Peter! I'll put together a release and ship it!

[virtuald]

Question for @PeterJohnson , you applied these to STATUSFUNC only... shouldn't we put it on RETFUNC instead? I tried it out of course and it broke... but that seems like it would be more robust.

[PeterJohnson]

If we do that, we need to make a STDFUNC or similar for those RETFUNC's where the return value is a status int that should be checked rather than a separate value that should be returned. I can do this tonight, but the current commit should work as-is to get teams up and running.