Can't run the pancake CNC example

[GoogleCodeExporter]

When I run the CNC example, it finds the brick over bluetooth and connects, but 
the motors never spin. and I get about 2000 lines that look like this.

2011-04-08 15:31:57.844 Python[57997:7307] *** __NSAutoreleaseNoPool(): Object 
0x103c89ac0 of class __NSCFDate autoreleased with no pool in place - just 
leaking

The program stops after 4 seconds like it's supposed to.

What version of nxt-python are you using?
  The latest SVN checkout

On what operating system?
  Mac 10.6.6

Original issue reported on code.google.com by mission2...@gmail.com on 8 Apr 2011 at 10:37

[GoogleCodeExporter]

I didn't notice this before, but the first line is different.

2011-04-08 15:42:56.937 Python[58557:7443] *** __NSAutoreleaseNoPool(): Object 
0x101129450 of class OC_PythonData autoreleased with no pool in place - just 
leaking

Original comment by mission2...@gmail.com on 8 Apr 2011 at 10:45

[GoogleCodeExporter]

This doesn't seem right. After installing the latest from the SVN, bricks still 
have no threadsafe attribute.

>>> import nxt
>>> b = nxt.find_one_brick(name = 'NXT')
USB module unavailable, not searching there
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-p
ackages/lightblue/_bluetoothsockets.py:42: DeprecationWarning: the sets module 
is deprecated
  import sets     # python 2.3
>>> b.threadsafe
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Brick' object has no attribute 'threadsafe'

Is there something more I need to do, to ensure a clean install of the newest 
version?

Original comment by mission2...@gmail.com on 8 Apr 2011 at 11:00

[GoogleCodeExporter]

Apologies for taking a while to reply; I've been busy these past few days.

You can check for threadsafeness by looking at the top of brick.py and checking 
for the "from threading import Lock" line. If it's there, the threadsafe code 
is working. Actually, v2.1 has threadsafe capability, so you shouldn't need the 
latest SVN at this point (it's good to have, though).

As for the actual error messages, I have no idea. It's probably lightblue doing 
something weird... Why don't you try spin.py? It tests the same functionality 
but is quite a bit simpler and will yield less output to pick through. A 
complete log of that at pastebin or attached in a text file might help. Do lots 
of googling for info about those error messages and see if it can tell you 
which file/line is causing them.

Sorry about this difficulty.

Marcus Wanner

Original comment by marcus@wanners.net on 11 Apr 2011 at 6:41

• Changed state: Accepted
• Added labels: Component-Bluetooth, OpSys-OSX, Series-2.x

[GoogleCodeExporter]

Original comment by marcus@wanners.net on 11 Apr 2011 at 6:41

[GoogleCodeExporter]

Googling the error turns up almost solely iPhone issues because the error is 
coming from Objective-C. I figured this might be an OSX specific problem so I 
sidestepped it and just switched to my linux box. Everything runs fine there.

Original comment by mission2...@gmail.com on 11 Apr 2011 at 7:47

[GoogleCodeExporter]

Great. If you want more done on this, please refer to the lightblue people. The 
more I look at those messages, the more I think that the problem is with that 
and not nxt-python. I do know that the messages aren't coming from our code. 
They may even be incidental and caused by whatever the problem really is, 
which, unless it's the python core, isn't in nxt-python.

Original comment by marcus@wanners.net on 12 Apr 2011 at 5:00

• Changed state: Invalid

[GoogleCodeExporter]

I'm also struggling with the threading.
So fare I found this information:
* __NSAutoreleaseNoPool issue can be avoided by starting the thread#s run 
method with >>pool = NSAutoreleasePool.alloc().init()<< and ending it with 
>>del pool<<
* nevertheless it will not work, all calls using the bluetooth connection will 
hang
* the lightblue package ist not threadsafe (cp. lightblue homepage):
>>Current limitations:
Avoid threading on Mac OS X, as the underlying IOBluetooth and IOBluetoothUI 
frameworks are not thread-safe <<

Original comment by anta...@gmx.ch on 24 Apr 2011 at 4:03

[GoogleCodeExporter]

Yeah, there's nothing we can do about this, sorry.

We are not associated with lightblue in any way and as such is the situation 
can't fix their problems. Sorry.

Original comment by marcus@wanners.net on 24 Apr 2011 at 4:59

[GoogleCodeExporter]

You might be able to make it work with multiple processes instead of threads. 
It all depends on if the NXT brick will take commands from multiple bluetooth 
connections at once.

Original comment by mission2...@gmail.com on 24 Apr 2011 at 9:04

[GoogleCodeExporter]

No, the NXT will not allow more than one connection at a time.

Original comment by marcus@wanners.net on 24 Apr 2011 at 9:45