Select nxt-python backend via configuration parameters or at beginning of program

[GoogleCodeExporter]

Describe the new feature more precisely.

Currently the Method() backend selection needs to be specified for
find_one_brick().

It should be specified either via configuration parameters or at the beginning 
of the program.

Why do you think it's important?

Easy to modify / change backend without touching other code.

Any ideas on how to implement it?

Configure file, command line parameter, configuration method at begnning of 
program.

Please provide any additional information below.

Original issue reported on code.google.com by tcwa...@gmail.com on 3 Jun 2011 at 9:52

[GoogleCodeExporter]

I believe that the best way to do this would be with a configuration file, so 
that all scripts could simply call find_one_brick() with no options and the 
options from the file would be used. This means that all scripts will work out 
of the box, and we will keep the current default settings so as to be 
backwards-compatible.

I'm not sure about the exact contents of the file, but it should be able to 
specify the host and name of the brick and which methods to try. We should also 
add a bit to find_one_brick to handle the case of a server brick being 
specified in the file. The question would be where to put this on Windows (on 
Linux and Mac it would be at ~/.nxtpythonrc). Perhaps application data? I will 
have to find a Windows machine to test this on.

I hope to include this functionality with version 2.2.0.

Possible future enhancements:
Allow mutltiple bricks to be specified in the file. These could be tried in 
turn or used concurrently, preferably the latter.

Original comment by marcus@wanners.net on 4 Jun 2011 at 9:49

• Changed state: Accepted
• Added labels: Component-Logic, Component-Persistence, Component-UI, OpSys-All, Series-2.x

[GoogleCodeExporter]

At this point, reading configuration files works and is ready for testing. I'm 
still getting a config file generator working.

Original comment by marcus@wanners.net on 29 Jun 2011 at 1:58

• Changed state: Started

[GoogleCodeExporter]

The configuration file generator is finished and works. Please test it and 
report on its usefulness. Thanks!

Original comment by marcus@wanners.net on 30 Jun 2011 at 12:25

• Changed state: Fixed

[GoogleCodeExporter]

Tested with SVN Revision 353.

The feature is looking good, though there are some hiccups.

1. I tried setting name = None, and host = None, it breaks find_one_brick. I 
needed to leave it blank instead. Perhaps some comments in the config file 
header would be good.

2. find_bricks() does not understand the config mechanism yet (it complains 
about no backends found).

3. There is no quick way to run the configuration file generator. Perhaps a new 
helper script is needed? (otherwise, running locator.py directly may allow for 
triggering the config file generation process?)

4. When creating a config file, the code should check for presence of an 
existing config file and either backup the old config or else prompt the user 
to overwrite.

Original comment by tcwa...@gmail.com on 30 Jun 2011 at 12:49

[GoogleCodeExporter]

1. That's right, the standard lib config parser interprets everything as 
strings, including None, which would need to be an actual NoneType for it to 
recognize it as disabled. I believe I did add a note saying that if a parameter 
was not passed to find_one_brick in normal operation, the line in the config 
should be commented out or removed.

2. I'm not sure what's up with this. Are you setting the backend you want to 
use (usb or bluetooth) to True in the method line? Remember that that option 
should contain the exact string you would pass to Method() when calling 
find_one_brick(). If you are not passing a Method() object to find_one_brick(), 
you should remove the method line from the config.

3. I thought opening a python console and running "import nxt.locator; 
nxt.locator.make_config()" was pretty quick. Do we really need a script with 
only two lines of code? I don't think making locator.py runnable would be an 
appropriate solution at all.

4. Yeah, you're right. I'll have it prompt for overwrite.

Original comment by marcus@wanners.net on 30 Jun 2011 at 11:17

[GoogleCodeExporter]

Re Comment #5, Issue #2. 

find_one_brick() works with the configuration file definition of the methods to 
use (in my case, fantomusb).

method = usb=False, bluetooth=False, fantomusb=True

The problem is with find_bricks(), not find_one_brick().

$ arch -i386 /usr/bin/python2.6 
~/gitrepo/nxt-python-svn-fantom/scripts/nxt_test 
USB module unavailable, not searching there
Bluetooth module unavailable, not searching there
Traceback (most recent call last):
  File "/Users/tcmac/gitrepo/nxt-python-svn-fantom/scripts/nxt_test", line 17, in <module>
    for sock in socks:
  File "/Users/tcmac/svnrepo/nxt-python/nxt/locator.py", line 80, in find_bricks
    raise NoBackendError("No selected backends are available! Did you install the comm modules?")
nxt.locator.NoBackendError: No selected backends are available! Did you install 
the comm modules?

Original comment by tcwa...@gmail.com on 30 Jun 2011 at 11:42

[GoogleCodeExporter]

If you could pass debug=True to find_one_brick() and post the output, it would 
help with this. It appears that there is a problem in the logic somewhere in 
Method() or find_bricks() which is causing method.fantom to be False when it 
should be True.

Original comment by marcus@wanners.net on 1 Jul 2011 at 2:17

[GoogleCodeExporter]

find_one_brick() calls find_bricks() internally.
The issue is that find_one_brick() understands the config file, while 
find_bricks() can only accept explicitly stated method arguments.

In nxt_test, the code calls find_bricks() directly instead of find_one_brick().
The fix is to change nxt_test to call find_one_brick() instead, and mark 
find_bricks() as an internal routine which should not be called from user 
programs.

Original comment by tcwa...@gmail.com on 6 Jul 2011 at 2:21

[GoogleCodeExporter]

find_bricks is already marked as advanced users only. I have updated nxt_test 
to use find_one_brick().

Original comment by marcus@wanners.net on 6 Jul 2011 at 4:11

[GoogleCodeExporter]

I have a wee bit to add here. I'm trying to use the setup with Mountain Lion 
(10.8.1- I haven't tried it on my one 10.8.2 machine but I've noticed that 
there are a -lot- of USB issues fixed with the 10.8.2 prereleases fwiw)

When I look at boot time, the Fantom driver isn't getting loaded e.g.-

9/11/12 12:13:49.505 PM com.apple.kextcache[432]: Fantom.kext - no dependency 
found for com.apple.kernel.iokit.

I was just able to connect using the NXT 2.0 software, update the bot's 
firmware via USB, and just bound it via plain-ol-bluetooth too. When I send 
debug=True to the find_one_brick() I am greeted with what I suppose is correct:

Warning: Config file (should be at /Users/flip/.nxt-python) was not read. Use 
nxt.locator.make_config() to create a config file.
Host: None Name: None Strict: True
USB: True BT: True Fantom: False FUSB: False FBT: False
USB module unavailable, not searching there
Bluetooth module unavailable, not searching there

Just realized this is a 'virgin' nxt-python machine so I haven't made the 
config yet... But this is at least something diagnostic for y'all. 

Original comment by flip.phi...@gmail.com on 11 Sep 2012 at 4:29

[GoogleCodeExporter]

Re: Comment #10
I don't have a Mountain Lion setup to test with, but it seems strange that 
IOKit is not accessible on Mountain Lion?

Fantom drivers work fine with Lion 10.7.4 running a 64-bit kernel. From my 
limited understanding, the Fantom kext seems to not do anything but just 
indicate to the USB driver that the device is a known device (Hence Fantom 
could work on Lion without having an explicit 64-bit driver, unlike Windows). 
The real work is actually done by the Apple USB drivers.

Original comment by tcwa...@gmail.com on 12 Sep 2012 at 1:00