-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >On Mon, 8 Jun 2015 15:23:20 +0000 >naruto canada <[email protected]> wrote: > > On Mon, Jun 8, 2015 at 2:37 PM, Aleksandar Kuktin <[email protected]> > wrote:
> > Thank God, PyOBEX is short so I can trace it, sort of (I don't speak > > Python). > > > > Does the failure that you fixed happen in the call to > > client.connect()? If so, then we can rule out PyOBEX because it > > treats the value of the channel opaquely and just passes it to the > > lower layer. Unfortunately, I don't know Python, I can't decipher > > its importing, so I don't know what that lower layer is. The > > outgoing call is in PyOBEX/client.py on line 121. If you can tell > > me where that call ends up I could keep tracing it - or you can do > > it yourself, but I'd still like to see where it ends up. > > I have python trace log (does not help me much), and also btmon logs > for good and bad pairing when using bluetoothctl. I worded myself wrong. By "tracing" I meant "visually trace", as in "follow the code execution with my eyes, reading", without programs. > I am guessing, none of the intervening library does anything to > convert the port (or channel) number. My question should be "should > any conversion be done at lower level or not?" Well, presumably, the channel/port is passed to PyOBEX by-meaning (AKA by-value). Since the meaning is independent of the binary representation, *something* should translate the binary representation (or, in this case, *NOT* translate it). PyOBEX is not obviously wrong, so I can only presume that the mistake is in the "socket" class (are they called classes?). But I don't know where this "socket" comes from, so I can't tell. Is it a normal part of Python? Did some other package add it? Did some other package extend a previously existing class? As I said, I don't really speak Python, I just pick up from similarities with other languages. > Maybe this is the correct behavior (or not)? This is the point I am > not sure about. Depends on whether the second argument in "BrowserClient(address, channel)" is supposed to be interpreted as a number value or a string or array. I'm assuming it's supposed to be a number. > Because, one would assume (probably wrongly), that above Python, > everything platform related (or differences in platforms) should have > been taken cared of... Well, yes. Also: the wiring is supposed to be checked, the chips are supposed to be compatible, the standards are supposed to be unambiguous, the code is supposed to be bug-free, the user is supposed to be sane and so on and on. - -- Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. - -- You don't need an AI for a robot uprising. Humans will do just fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJVdbhRAAoJEKa4cgqNx31/LYUQAItK01glppJ1KOeDiDVaZQoG qIA3aoGsAQ2xCJuUfbo9tEOArT/1RUiJ7iH5XAsWEAmd7PCCl3WcVK9fknVaLnhL MkvRfDSW1D7YwlDWscs7iBNo9MoUGH4k/AqRKzxl/yE55qobY229JU0kW3PhsqYG 7R2pxIDJIJtZhjoreA465pW7Fij/HsKOQXVEtsL5j61Fd+dUeGyc4Cify7/rmHFk Rjgw/ixZMrkGsPAFqjuZt7ndfwk0W/5/aoAxnTv7u85MA8heBxApzGKRK55CNWRS qamjrgaCZy6aA8z29AyE7UGbSaa5g+D1yohyw72Pa71WJR/pVNjYCUdOtvOyfnku bmbuHfJ+ns5c1PFI7/bWwhbP9KSmqrh0fAOrxQk9dhJzMowYzwHz1EgLj692lSAe nPfRCjjXO09cM4gGFtULbSRz5KlEgquYHkjK/LzCBT1ZzAEP1c3q8qkFWPixIrNR I4DPfN/ei83f6bM89VHqD0Sq6PyskYK3NuEBZjIHs66HCP/D2tDyPpFKCDLkp0Mg ZjRO4bftrEwTvISnxZnoyW6ox51G9ksH1+wj6ViV9Fa4XFJNqOHy5OgT/s8rQz91 p9rdsL7f7bJJgJCXJpZQkTWkK2Xf2NnhsDxJc0Nf0ezPv5tXDTboCZK6RXFICXiR Qpq4rNbmDOLqNHuTEpOt =sTUL -----END PGP SIGNATURE----- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
