Wiley.Mobile.Python.Rapid.prototyping.of.applications.on.the.mobile.platform.Dec.2007 (779889), страница 55
Текст из файла (страница 55)
In this case, the activeserial port can be found in the file /dev/rfcomm0.B.2 Using Bluetooth ConsoleIn this section, we assume that the RFCOMM serial port is set upcorrectly. You should also see the serial port service from the phone usingExample 55, as described above. After this is done, there are only fewreasons for the Bluetooth console not to work.Bluetooth console is used in a terminal emulator application.
Windowscomes with one called HyperTerminal and several others are availablefor free. Linux and Mac OS X users have plenty of choices as well, but aprogram called screen is most often installed by default.You can type any Python expression on the Bluetooth console. Whenthe console seems to be active, you can try to type the following twolines on your PC and see what happens on the phone:import appuifwappuifw.note(u"Woohoo!", "info")B.2.1 WindowsHyperTerminal can be found at Programs, Accessories, Communications,HyperTerminal.
HyperTerminal is used as follows:1.Open the program. First, it asks for a connection name, you canuse for example ‘btconsole’. Press OK and select the correct COMport. The port is the one you set up in the Local Services tab in theBluetooth configuration panel. Select the fastest connection speed.2.On your phone, open PyS60 interpreter and on the options menu,choose ‘Bluetooth console’.USING BLUETOOTH CONSOLE2933. Your computer’s name should show up in the list – choose it.4. If the script executing on the phone prints ‘OK’, the console shouldbe up and running. Hit enter on HyperTerminal to see the commandprompt of the PyS60 interpreter.If the above did not work, note that in some cases Nokia PC Suite mayconflict with other users of the serial port.
If you have PC Suite active,you might want to disable it for testing.B.2.2Mac OS XAfter successful Bluetooth configuration, a serial port file should existat /dev/tty.pybook. You can execute the following command ona terminal:screen /dev/tty.pybookNote that nothing is visible on screen until the console is running.Now you can run the Bluetooth console on your phone, as described inWindows steps 2 and 3. You should hit enter on the screen when theconsole is active on the phone side.When you are finished with the console session, you can terminatethe connection with Ctrl-D.B.2.3LinuxYou should have an rfcomm process running on one terminal, saying‘Waiting for connection on channel 3’.
Now you should open anotherterminal for the Bluetooth console and login as root to make sure thatyou can read and write/dev/rfcomm0. Then follow these steps:1. Open the Bluetooth console on your phone, as described in Windowssteps 2 and 3. If the connection was established successfully, rfcommprints out a line such as ‘Connection from 00:12:D2:DA:14:F4to/dev/rfcomm0’.2. Execute screen/dev/rfcomm0 on the other terminal.3. Hit enter to see the PyS60 command prompt on screen.When you are finished with the console session, you can terminatethe connection with Ctrl-D.Appendix CDebuggingSometimes your Python program does not behave as you would expect.This happens in virtually every project at some point during the development process. It is a good idea to track down the cause as soon as younotice that something goes awry.
This ensures that you always know thatyour program behaves as intended and it is built on a solid basis.This appendix goes through the most typical ways of debugging aPython program. Since bugs are seldom really mysterious in Python, incontrast to many low-level languages such as C++, you can survive without heavy-duty debugging tools. Often a few well-placed print statementsare enough to detect where the execution goes off track.The ease of debugging in Python is based on rapid debug–evaluateiterations. Instead of assuming or trusting the documentation on how aPyS60 API function or a Python language construct behaves, you can tryit in practice.
Thus, the first step in successful debugging is to make surethat you can update your code on your phone with a minimal number ofsteps, as described in Chapter 2 and Section 10.3.Be prepared to make lots of small changes to your code quickly. Ifmodifying the code is a frustrating and time-consuming activity for you,check if you can streamline your development process. You should beable to update the program on your phone with two or three clicks fromyour PC.Once you are fluent in updating the code, you should become accustomed to developing your code in short update–test cycles. If you makeonly a few small changes at a time and test and fix them immediately, youcan be sure that your program works correctly as a whole.
If it does not,at least you have a better understanding of how your program behavesand you can start applying methods from the debugging arsenal.C.1 Interpreting TracebacksIf execution of a Python program leads to an expression that is notunderstood by the interpreter, an exception is generated. Chapter 6296DEBUGGINGdescribes exceptions in detail. If the exception is not handled by yourprogram, it is eventually shown on the Python console and the programexecution is terminated.Seeing an exception is useful in two respects: it tells you what andwhere something exceptional happened. Look at Example 127.Example 127: See the error?def hello():appuifw.query(u"Hello World", "txet")hello()You can probably spot the error. When the code is executed, thefollowing output is printed on the console:Traceback (most recent call last):?File "C:\python\ex_error.py", line 4, in ?File "C:\python\ex_error.py", line 2, in hellodef hello():ValueError: unknown query typeWe omitted some of the output between the first line and the lastfour lines.
This output is called a traceback. It tells how the programexecution proceeded just before the exception happened. The mostrecently executed lines are shown last. Almost always the last few linespinpoint the actual location of the problem, but often it is useful toknow how the program ended up on those lines, as shown by the fulltraceback. If you execute the program in the Python shell, the first lines ofthe traceback show how the program was started by the shell internallywhich is not really interesting to us.In the example above, you can see that the exception occurred inline 2, in function hello().
The erroneous function was called by line4 which does not belong to any function, thus it says ‘in ?’. The filesmentioned above these (which are not shown above) are not written byus, in contrast to ex error.py, so we are not interested in them. Whendebugging programs of your own, you can follow the same principle:in the traceback, look for the lines which contain filenames familiar toyou, starting from the bottom. This helps you to understand the contextin which the exception occurred.The last line of the traceback shows the actual exception, namelyValueError in the example above.
The name of the exception maysuggest the nature of the problem, but usually it is the error messagewhich reveals the actual cause. Based on the traceback, we knowthat the error occurred on line 2, which contains a call to the function appuifw.query() which in turn generated the error messageC.1 INTERPRETING TRACEBACKS297‘unknown query type’. Summing up this information, we notice that atyping error, "txet" instead of "text", in the second parameter for thefunction call is the culprit.Sometimes exceptions may be a bit misleading.
Try out the code inExample 128.Example 128: Syntax errordef hello():appuifw.query(u"Hello World", "text"hello()Once you run the code, you will get a traceback like this:Traceback (most recent call last):?File "C:\python\ex_error.py", line 4hello()SyntaxError: Invalid syntaxThis suggests that the culprit is on line 4, but the function callhello() seems to be correct.
In this case, the name of the exception,SyntaxError, reveals the actual cause.The problem does not occur during execution of the program, butwhen PyS60 tries to read and interpret the code, which reveals any errorsin the code text, that is, syntax errors. Since the exception is reportedon line 4, which seems to be correct, we start to find the real culprit onthe lines which were read before that.
The true cause is a missing rightparenthesis on line 2 which made the interpreter think that the functioncall continues all the way to line 4. The lesson here is that if you cannotspot the error on the reported line, start looking at previously interpretedor executed lines.The most frustrating bugs are usually those which do not cause anyexception but make the program behave in an unexpected manner.Typically, this happens when your program gets erroneous input whichseems normal to the function but which makes it behave in a wrong way.To get rid of bugs like this, you need some other methods which areintroduced in Section C.2.In some cases, bugs may be hiding in innocent assumptions which justhappen to be correct when you first run the program.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
