[aymanshamma]

Hello,

So I made this little app which works fine in the emulator and fine as a .py script on my 6682. Using py2sis, I made a SIS file. When my app goes to record a sound, the whole app quits with no message or error.

I trimmed down my application to a small test which duplicates the problem (once again, only if its run from a SIS file).

import e32
import appuifw
import httplib, urllib
import audio
import time
import string
import sysinfo
import cElementTree as et
import location

e32.ao_yield()

class RecordTest:
    def __init__(self):
        self.lock = e32.Ao_lock()
        self.old_title = appuifw.app.title
        appuifw.app.title = u"RecordTest"
        self.running = True
        appuifw.app.screen = 'normal'
        self.text = appuifw.Text()
        appuifw.app.body = self.text
        appuifw.app.exit_key_handler = self.close
        self.text.add(u'Recording')
        self.record_wav()

    def record_wav(self):
        sf = u'c:\\System\\Temp\\test.wav'
        if os.path.isfile(sf):
            os.unlink(sf)
        s = audio.Sound.open(sf)
        s.record()
        time.sleep(10)
        s.stop()
        return sf

    def close(self):
        appuifw.app.menu = []
        appuifw.app.body = None
        appuifw.app.exit_key_handler = None
        appuifw.app.title = self.old_title


def main():
    app = RecordTest()
    app.close()
                
if __name__ == "__main__":
    main()

Using appuifw.note as debug output, I found the app quits when the call to "s.record()" happens.

Anyone have an idea on what could be happening or if there's a good way to debug what might be going on?

-a.

[otsov]

Originally Posted by aymanshamma

So I made this little app which works fine in the emulator and fine as a .py script on my 6682. Using py2sis, I made a SIS file. When my app goes to record a sound, the whole app quits with no message or error.

[...]

Anyone have an idea on what could be happening or if there's a good way to debug what might be going on?

The problem you might have is that the Python application (aka script shell) you use to run individual .py scripts imports modules which might not be imported in your script and hence the standalone application wrapped is not working. This is both a common problem developers have with standalone applications and a design flaw in PyS60 that should be solved (and documented for earlier releases).

"import os" might help in your script.

[simo.salminen]

For standalone script, I recommend making an entry point default.py that does two things: setup logging, and starts the main app. This will speed up finding these kinds of probs. Note that this will start logging IFF debug\ subdir is present. This has added benefit that when you ship your program, and users run into problem, they can create the debug\ dir and you hopefully get the exception that occured.

default.py

import sys
import os

import logger

debug_path = os.path.join(os.path.dirname(sys.argv[0]), "debug")
if os.path.exists(debug_path):
    my_log = logger.Logger(os.path.join(debug_path, "debug.txt"))
    sys.stderr = sys.stdout = my_log
    print "debug started"

import yourapplication
yourapplication.run()

logger.py

class Logger:
    def __init__(self, log_name):
        self.logfile = log_name
        
    def write(self, obj):
        log_file = open(self.logfile, 'a')
        log_file.write(obj)
        log_file.close()
        
    def writelines(self, obj):
        self.write(''.join(list))
        
    def flush(self):
        pass

[simo.salminen]

There is another possibility. I see that you have cElementTree in import list. Importing that will take a lot of time. Try to add e32.ao_yield() calls before and after that import. Better yet, remove that and import that only when you really need it (inside a function).

Why? Because in S60 UI framework there is application watchdog, that will kill the app does not communicate with UI framework for ~10 secs. If you import takes longer that, it's bye bye.

This will lead to really mysterious problems when you develop with fast phone, and run to these issues with slower phones. So, remember to keep the import delay low.

[aymanshamma]

Lot of good stuff here -- Thanks otsov & simo!

1) import os was the problem -- I assumed it was akin to java.lang.* and os was automatically imported -- i guess there are no such classes.

2) I moved the imports which helps the app's overall load time and makes it feel slick.

3) the new knowledge on e32.ao_yield() frightens me. Should i not call time.sleep and maybe call ao_sleep instead to keep the schedular happy?

Again, good stuff -- thanks!

-a.

[simo.salminen]

About the 3):
Well, I guess it depends on situation. Usually it is best to organize code so that sleeps are not necessary.

The ao_sleep/ao_yield might suprise you. Lets assume that we have following code:

data = [1,2,3]

def menu_callback1():
 global data
 e32.ao_sleep(10)
 # do something with data[2], this will throw an error
 print data[2]

def menu_callback2():
 global data
 del data[2]

Now, lets assume that have two menu options, which are binded to menu_callback1/2. User selects option that causes callback1 to be called. Now, it will sleep 10 seconds. The sleep starts a nested event scheduler. So, if user selects option that runs callback2, it will run inside that ao_sleep call.

The example code will bug because callback1 code wrongly assumes that data cannot be changed.

Note that there is nothing magical about scheduler. It is simply this kind of code:

def eventloop():
  while (keepgoing):
    wait_for_event()
    run_event_handler()

Event can be keyboard press, network activity, or such.