Hi all I try to update python-openzwave and I've got some problems. The first is an ambiguous overloaded method when trying to compile I try to compile it on 0.14 (oneiric) and 0.15 (precise) Here is the pyx :
ctypedef unsigned int uint32 ctypedef unsigned long uint64 ctypedef int int32 ctypedef int int16 ctypedef unsigned char uint8
def setValue(self, id, value): ''' Sets the value of a device valueid. Due to the possibility of a device being asleep, the command is assumed to suceeed, and the value held by the node is updated directly. This will be reverted by a future status message from the device if the Z-Wave message actually failed to get through. Notification callbacks will be sent in both cases. @param id the ID of a value. @param value the value to set ''' cdef float type_float cdef bint type_bool cdef uint8 type_byte cdef int32 type_int cdef int16 type_short cdef string type_string
if values_map.find(id) != values_map.end(): datatype = PyValueTypes[values_map.at(id).GetType()]
if datatype == "Bool": type_bool = value self.manager.SetValue(values_map.at(id), type_bool) elif datatype == "Byte": type_byte = value self.manager.SetValue(values_map.at(id), type_byte) elif datatype == "Decimal": type_float = value self.manager.SetValue(values_map.at(id), type_float) # TODO: this gives me an "ambiguous overloaded method", I don't understand why. elif datatype == "Int": type_int = value self.manager.SetValue(values_map.at(id), type_int) #elif datatype == "Short": # type_short = value # self.manager.SetValue(values_map.at(id), type_short) elif datatype == "String": type_string = string(value) self.manager.SetValue(values_map.at(id), type_string)
> Hi all
> I try to update python-openzwave and I've got some problems. The first is > an ambiguous overloaded method when trying to compile
> I try to compile it on 0.14 (oneiric) and 0.15 (precise)
> Here is the pyx :
> if values_map.find(id) != values_map.end(): > datatype = PyValueTypes[values_map.at(id).GetType()]
> if datatype == "Bool":
> type_bool = value
> self.manager.SetValue(values_map.at(id), type_bool)
> elif datatype == "Byte":
> type_byte = value
> self.manager.SetValue(values_map.at(id), > type_byte)
> elif datatype == "Decimal":
> type_float = value
> self.manager.SetValue(values_map.at(id), type_float)
> # TODO: this gives me an "ambiguous overloaded method", I don't > understand why.
> elif datatype == "Int":
> type_int = value
> self.manager.SetValue(values_map.at(id), type_int)
> #elif datatype == "Short":
> # type_short = value
> # self.manager.SetValue(values_map.at(id), type_short)
> elif datatype == "String":
> type_string = string(value)
> self.manager.SetValue(values_map.at(id), type_string)
Note that the first parameter that is passed into the method is not a C++
reference type but the plain value type. Just a guess, but that might lead
to a slight difference in the signature matching that prevents an exact
match. IMHO, it shouldn't.
As a work-around, use the github version of their code.
> bibi21000, 29.08.2012 21:38: > > Hi all > > I try to update python-openzwave and I've got some problems. The first > is > > an ambiguous overloaded method when trying to compile > > I try to compile it on 0.14 (oneiric) and 0.15 (precise) > > Here is the pyx :
Yes. As I've said in the previous post, I try to update it.
You've surely seen that it is no longer maintained. It use an very old release of openzwave which have a poor set of functions and doesn't compile on recent distribs (precise for example)
> Note that the first parameter that is passed into the method is not a C++ > reference type but the plain value type. Just a guess, but that might lead > to a slight difference in the signature matching that prevents an exact > match. IMHO, it shouldn't.
> yes but it find the right methods for bint, unit8, float and string. The
problem only appears with int32 and int16
From cython documentation :
1.
If the header file uses typedef names such as word to refer to platform-dependent flavours of numeric types, you will need a corresponding ctypedef<http://docs.cython.org/src/userguide/language_basics.html#ctypedef>statement, but you don’t need to match the type exactly, just use something of the right general kind (int, float, etc). For example,:
ctypedef int word
will work okay whatever the actual size of a word is (provided the header file defines it correctly). Conversion to and from Python types, if any, will also be used for this new type
Sould it be the problem ?
cython uses the same type to map int16 and "int32" so it couldn't find the right method after that ?
As a work-around, use the github version of their code.
> Le jeudi 30 août 2012 13:01:25 UTC+2, Stefan Behnel a écrit :
>> bibi21000, 29.08.2012 21:38: >>> I try to update python-openzwave and I've got some problems. The first >>> is an ambiguous overloaded method when trying to compile >>> I try to compile it on 0.14 (oneiric) and 0.15 (precise) >>> Here is the pyx :
>>> if values_map.find(id) != values_map.end(): >>> datatype = PyValueTypes[values_map.at(id).GetType()]
>>> if datatype == "Bool": >>> type_bool = value >>> self.manager.SetValue(values_map.at(id), type_bool) >>> elif datatype == "Byte": >>> type_byte = value >>> self.manager.SetValue(values_map.at(id), >>> type_byte) >>> elif datatype == "Decimal": >>> type_float = value >>> self.manager.SetValue(values_map.at(id), type_float) >>> # TODO: this gives me an "ambiguous overloaded method", I >>> don't understand why. >>> elif datatype == "Int": >>> type_int = value >>> self.manager.SetValue(values_map.at(id), type_int) >>> #elif datatype == "Short": >>> # type_short = value >>> # self.manager.SetValue(values_map.at(id), type_short) >>> elif datatype == "String": >>> type_string = string(value) >>> self.manager.SetValue(values_map.at(id), type_string)
> Yes. As I've said in the previous post, I try to update it.
> You've surely seen that it is no longer maintained. It use an very old > release of openzwave which have a poor set of functions and doesn't compile > on recent distribs (precise for example)
>> It's based on these declarations further above in the file:
>> Note that the first parameter that is passed into the method is not a C++ >> reference type but the plain value type. Just a guess, but that might lead >> to a slight difference in the signature matching that prevents an exact >> match. IMHO, it shouldn't.
>> yes but it find the right methods for bint, unit8, float and string. The > problem only appears with int32 and int16
> From cython documentation :
> 1.
> If the header file uses typedef names such as word to refer to > platform-dependent flavours of numeric types, you will need a corresponding > ctypedef<http://docs.cython.org/src/userguide/language_basics.html#ctypedef>statement, but you don’t need to match the type exactly, just use something > of the right general kind (int, float, etc). For example,:
> ctypedef int word
> will work okay whatever the actual size of a word is (provided the > header file defines it correctly). Conversion to and from Python types, if > any, will also be used for this new type
> Sould it be the problem ?
> cython uses the same type to map int16 and "int32" so it couldn't find the > right method after that ?
Ah, right - I missed this on first sight:
"""
ctypedef unsigned int uint32
ctypedef unsigned long uint64
ctypedef int int32
ctypedef int int16
ctypedef unsigned char uint8
"""
Sure, this is wrong. Change the int16 ctypedef from int to short and it
should work.
>> As a work-around, use the github version of their code. > ?
... instead of a release version. But even better, fix the above and send
them a pull request.
> Le jeudi 30 août 2012 21:22:42 UTC+2, Stefan Behnel a écrit :
>> bibi21000, 30.08.2012 20:55: >>> Le jeudi 30 août 2012 13:01:25 UTC+2, Stefan Behnel a écrit : >>>> bibi21000, 29.08.2012 21:38: >>>>> I try to update python-openzwave and I've got some problems. The first >>>>> is an ambiguous overloaded method when trying to compile >>>>> I try to compile it on 0.14 (oneiric) and 0.15 (precise) >>>>> Here is the pyx :
>>>>> if values_map.find(id) != values_map.end(): >>>>> datatype = PyValueTypes[values_map.at(id).GetType()]
>>>>> if datatype == "Bool": >>>>> type_bool = value >>>>> self.manager.SetValue(values_map.at(id), type_bool) >>>>> elif datatype == "Byte": >>>>> type_byte = value >>>>> self.manager.SetValue(values_map.at(id), >>>>> type_byte) >>>>> elif datatype == "Decimal": >>>>> type_float = value >>>>> self.manager.SetValue(values_map.at(id), type_float) >>>>> # TODO: this gives me an "ambiguous overloaded method", I >>>>> don't understand why. >>>>> elif datatype == "Int": >>>>> type_int = value >>>>> self.manager.SetValue(values_map.at(id), type_int) >>>>> #elif datatype == "Short": >>>>> # type_short = value >>>>> # self.manager.SetValue(values_map.at(id), type_short) >>>>> elif datatype == "String": >>>>> type_string = string(value) >>>>> self.manager.SetValue(values_map.at(id), type_string)
>>> Yes. As I've said in the previous post, I try to update it. >>> You've surely seen that it is no longer maintained. It use an very old >>> release of openzwave which have a poor set of functions and doesn't >> compile >>> on recent distribs (precise for example)
>>>> It's based on these declarations further above in the file:
>>>> Note that the first parameter that is passed into the method is not a >> C++ >>>> reference type but the plain value type. Just a guess, but that might >> lead >>>> to a slight difference in the signature matching that prevents an exact >>>> match. IMHO, it shouldn't.
>>>> yes but it find the right methods for bint, unit8, float and string. >> The >>> problem only appears with int32 and int16
>>> From cython documentation :
>>> 1.
>>> If the header file uses typedef names such as word to refer to >>> platform-dependent flavours of numeric types, you will need a >> corresponding >>> ctypedef<
>> http://docs.cython.org/src/userguide/language_basics.html#ctypedef>statement, >> but you don’t need to match the type exactly, just use something >>> of the right general kind (int, float, etc). For example,:
>>> ctypedef int word
>>> will work okay whatever the actual size of a word is (provided the >>> header file defines it correctly). Conversion to and from Python >> types, if >>> any, will also be used for this new type
>>> Sould it be the problem ? >>> cython uses the same type to map int16 and "int32" so it couldn't find >> the >>> right method after that ?
>> Ah, right - I missed this on first sight:
>> """ >> ctypedef unsigned int uint32 >> ctypedef unsigned long uint64 >> ctypedef int int32 >> ctypedef int int16 >> ctypedef unsigned char uint8 >> """
>> Sure, this is wrong. Change the int16 ctypedef from int to short and it >> should work.
> Thanks a lot > That works :)
You're welcome. If you want to do it really right, get rid of the above
declarations all together and use cimports from the libc.stdint module instead.
> bibi21000, 30.08.2012 22:40: > > Le jeudi 30 août 2012 21:22:42 UTC+2, Stefan Behnel a écrit : > >> bibi21000, 30.08.2012 20:55: > >>> Le jeudi 30 août 2012 13:01:25 UTC+2, Stefan Behnel a écrit : > >>>> bibi21000, 29.08.2012 21:38: > >>>>> I try to update python-openzwave and I've got some problems. The > first > >>>>> is an ambiguous overloaded method when trying to compile > >>>>> I try to compile it on 0.14 (oneiric) and 0.15 (precise) > >>>>> Here is the pyx :
> >>> Yes. As I've said in the previous post, I try to update it. > >>> You've surely seen that it is no longer maintained. It use an very old > >>> release of openzwave which have a poor set of functions and doesn't > >> compile > >>> on recent distribs (precise for example)
> >>>> It's based on these declarations further above in the file:
> >>>> Note that the first parameter that is passed into the method is not a > >> C++ > >>>> reference type but the plain value type. Just a guess, but that might > >> lead > >>>> to a slight difference in the signature matching that prevents an > exact > >>>> match. IMHO, it shouldn't.
> >>>> yes but it find the right methods for bint, unit8, float and string. > >> The > >>> problem only appears with int32 and int16
> >> but you don’t need to match the type exactly, just use something > >>> of the right general kind (int, float, etc). For example,:
> >>> ctypedef int word
> >>> will work okay whatever the actual size of a word is (provided the > >>> header file defines it correctly). Conversion to and from Python > >> types, if > >>> any, will also be used for this new type
> >>> Sould it be the problem ? > >>> cython uses the same type to map int16 and "int32" so it couldn't find > >> the > >>> right method after that ?
> >> Ah, right - I missed this on first sight:
> >> """ > >> ctypedef unsigned int uint32 > >> ctypedef unsigned long uint64 > >> ctypedef int int32 > >> ctypedef int int16 > >> ctypedef unsigned char uint8 > >> """
> >> Sure, this is wrong. Change the int16 ctypedef from int to short and it > >> should work.
> > Thanks a lot > > That works :)
> You're welcome. If you want to do it really right, get rid of the above > declarations all together and use cimports from the libc.stdint module > instead.
> Le jeudi 30 août 2012 23:03:52 UTC+2, Stefan Behnel a écrit :
>> bibi21000, 30.08.2012 22:40: >> > Le jeudi 30 août 2012 21:22:42 UTC+2, Stefan Behnel a écrit : >> >> bibi21000, 30.08.2012 20:55: >> >>> Le jeudi 30 août 2012 13:01:25 UTC+2, Stefan Behnel a écrit : >> >>>> bibi21000, 29.08.2012 21:38: >> >>>>> I try to update python-openzwave and I've got some problems. The >> first >> >>>>> is an ambiguous overloaded method when trying to compile >> >>>>> I try to compile it on 0.14 (oneiric) and 0.15 (precise) >> >>>>> Here is the pyx :
>> >>> Yes. As I've said in the previous post, I try to update it. >> >>> You've surely seen that it is no longer maintained. It use an very >> old >> >>> release of openzwave which have a poor set of functions and doesn't >> >> compile >> >>> on recent distribs (precise for example)
>> >>>> It's based on these declarations further above in the file:
>> >>>> Note that the first parameter that is passed into the method is not >> a >> >> C++ >> >>>> reference type but the plain value type. Just a guess, but that >> might >> >> lead >> >>>> to a slight difference in the signature matching that prevents an >> exact >> >>>> match. IMHO, it shouldn't.
>> >>>> yes but it find the right methods for bint, unit8, float and string. >> >> The >> >>> problem only appears with int32 and int16
>> >> but you don’t need to match the type exactly, just use something >> >>> of the right general kind (int, float, etc). For example,:
>> >>> ctypedef int word
>> >>> will work okay whatever the actual size of a word is (provided >> the >> >>> header file defines it correctly). Conversion to and from Python >> >> types, if >> >>> any, will also be used for this new type
>> >>> Sould it be the problem ? >> >>> cython uses the same type to map int16 and "int32" so it couldn't >> find >> >> the >> >>> right method after that ?
>> >> Ah, right - I missed this on first sight:
>> >> """ >> >> ctypedef unsigned int uint32 >> >> ctypedef unsigned long uint64 >> >> ctypedef int int32 >> >> ctypedef int int16 >> >> ctypedef unsigned char uint8 >> >> """
>> >> Sure, this is wrong. Change the int16 ctypedef from int to short and >> it >> >> should work.
>> > Thanks a lot >> > That works :)
>> You're welcome. If you want to do it really right, get rid of the above >> declarations all together and use cimports from the libc.stdint module >> instead.
well, I try to use the standard integer types (exact match size) but doesn't compile with 0.16 one user reports that compilation is ok with 0.15 any idea ?
