Pandora PyQt on OpenPandora: current status


Eric Jardim

Eric Jardim

Member
Joined
Feb 1, 2011
Messages
63
Age
44
Location
Rio de Janeiro - Brazil
Hi all,


I've been tweaking with PyQt since last week and with a "little" help of sebt3, I was able to compile all PyQt modules on top sebt3's qt4.7 build, using Yactfaeu toolchain.


When you load the basic modules (QtCore and QtGui), it seems to work, but testing with some PyQt examples that come with the source code, it crashes (segmentation fault).


I tried using gdb to understand what was crashing the application, but since I compiled a realease version (with -O2s and -DNDEBUGs), the only info I get is that the crash occur inside the sip lib, after passing by QtCore or QtGui.


I tried recompiling sip and PyQt with debug (putting -g and removing -O2 or 3 , -DNDEBUG and other flags), but gdb appears to not catch debug symbols anyway.


I am using:


gdb (inside shell)


file python (inside gdb)


r pyfile.py (inside gdb)


Then I used some tips from


http://code.google.com/p/spyderlib/wiki/HowToDebugQtCrash


to force a "core" file to be created, but even like this, the core is empty.


I guess the crash is caused, or by some tweak that I made, or by some wrong header the configure/Makefile got from my host system (instead of the toolchain). But I really need to debug to understand the cause of the crash.


Can anybody give me some light?
 
For some reason GDB does not load symbols of libraries that are opened at runtime. However, if you attach GDB to the already running process, it will load the symbols of all libraries that were loaded at that time, including the ones loaded at runtime.
 
Make it wait at some point before the crash happens. When it waits, look up the process ID and start GDB like "gdb python $PID", then you should see how it loads the symbols from the other libs as well. Then 'continue' and you should get a more useful backtrace when you crash it.


Alternatively, the addresses that GDB spits out because of the lack of loaded debugging symbols are not totally useless. The whole GCC package should come with the addr2line tool, you can use it to get the position in the code by feeding it the affected lib with debugging symbols and that address.


That came in pretty handy when I was working on a Pidgin plugin ("Where the hell are mah debugging symbols?!")
 
Last edited by a moderator:
Letalis Sonus said:
Make it wait at some point before the crash happens. When it waits, look up the process ID and start GDB like "gdb python $PID", then you should see how it loads the symbols from the other libs as well. Then 'continue' and you should get a more useful backtrace when you crash it.
Click to expand...

I did it. But it provides no extra info.

Letalis Sonus said:
Alternatively, the addresses that GDB spits out because of the lack of loaded debugging symbols are not totally useless. The whole GCC package should come with the addr2line tool, you can use it to get the position in the code by feeding it the affected lib with debugging symbols and that address.
Click to expand...

addr2line gives me no extra info.


I will try to rebuild and see if I missed something, like defining some DEBUG macro or not specifying some compiler/linker option.


EDIT:


Just in time: I took a look at


http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/installation.html


and I will try building with this -u option.
 
Last edited by a moderator:
Eric Jardim said:
I will try to rebuild and see if I missed something, like defining some DEBUG macro or not specifying some compiler/linker option. I will try building with this -u option.
Click to expand...

I just recompiled sip and it worked. I think I know what possibly caused the problem.


Inside QtGui I needed to tweak the API due to some sip confusion. It seems that qreal in OpenPandora is float, but sip confuses and uses double. I wrote an workaround, but I think it is not complete. I will change it, recompile and see if it works.
 
Hurray!


I did it. It was simpler than I thought. I compiled qreal as double and it worked!!! The first test worked too.


Now I have to test everything, update my patches, build everything from scratch without debug symbols and put it here for some gentle soul to pack into a PND :lol:
 
Last edited by a moderator:
The basic idea behind PNDs is that each application includes its dependencies which are not part of the firmware. As such, this would be a developer resource instead of a PND by itself.


If it is not too large and works with the version of QT already installed on the system, then I recommend contacting ED for including this into the next firmware instead.


Regardless, thanks! I'll be sure to use this in the future.
 
Caine said:
The basic idea behind PNDs is that each application includes its dependencies which are not part of the firmware. As such, this would be a developer resource instead of a PND by itself.
Click to expand...

Ok, but PyQt + Qt assemble a Python Runtime Environment, that enables someone to develop full GUI applications for Pandora without compiling a single line of code.


Just imagine: "drop this PND (or whatever) at your SD card and start doing apps for OpenPandora!"


Why I don't the like the idea of repacking PyQt for every app that use it? First, because it depends on sebt3's qt4.7 build and if we only put the runtime libraries (of PyQt and Qt) it still cost 80MB.


You may say: it is few for my SD card. But imagine your app is so simple (like a notepad) and it's code is about 100K real python code. I still have to put 80MB of the runtime.


Imagine we could drop this HUGE "development packs" at some folder (as a PND or something) and write you TINY application, and pack it into a TINY PND file that DEPENDS on this pack. I think that is perfect world for me as a developer for OpenPandora.


Hmm, this is giving me some ideas!!!

Caine said:
If it is not too large and works with the version of QT already installed on the system, then I recommend contacting ED for including this into the next firmware instead.
Click to expand...

Hmm, that is not the case. As I said, it is build on top of another Qt version.
 
sebt3 said:
All you've need all along are ears to listen you.
Click to expand...

That's what my wife says all the time (pity for her ears ;) )


sebt3 and skeezix: it is done.


The PyQt "runtime bundle" is about 80MB and 23MB tarbzipped. Where do I upload it? Where should I put the compiling instructions and patches?
 
Stick it all up on EDs repo, perhaps?


http://dl.openhandhelds.org/cgi-bin/pandora.cgi


ie: since the repo and appstore both do not handle non-pnd files, and you may want to just have a tarball or zip with all the goodies (the built environment stuff, any docs, makefiles, whatever.)


As to distribution, we often discussed but never got around to .. a 'long term mount' or 'library mount' system; ie: most pnds are just apps (run and they exit on completion.) A few are 'servers' so you want them to hang around awhile .. those guys usually just fire up a shell, that when you kill it, the pnd then exits.. that can work for you, but is a little clumsy.


Theres stuff like WizStans java installer, which you run to install or uninstall the java stuff into NAND or onto SD (akin to sebt3's midi player installer as well.)


We had intended to have some PXML flags that suggest that when presdent, the pnd will be mounted (say) at start time, or maybe have some dependancy stuff so pnd_run.sh can run a pnd, see that another pnd is needed, and mount that one too (and of course manage complexitieds like 3 different pnds running at same time all needing difference dependancies, so as not to unloaded a needed one etc..)


But its complex on a mobile with multiple SD slots and finite RAM and so on, so we never nailed it down and built it yet ;)


So as such.. you're more stuck with..


o an installer approach (install to NAND or SD .. installing to SD just measns unpacking to a 'well defined' future proof path on SD, and maybe symlink on NAND to refer to it ..)


o a server approach; run the pnd, and it stays available for the session, until you kill tyhe terminal (or some other trigger to let it die.. or maybe never die until reboot)


o a set of files that other devs can include in their pnd; clumsu, but as SDs are enormous and cheap, this works well for (example) other QT apps that want a newer built of QT than the NAND includes


Get this stuff up, a lot of peopel will be grateful (myself included).


If you need help assembling a pnd, bug me or sebt3 or mcobit or someone, but I bet sebt3 is most experienced with installers and such, he did some great stuff there. (Wiz Stan too, but he just got married, so I think he might be busy :)


jeff
 
In my opinion, 80 Megs is way too big to include in every PyQt application.


Perhaps we should start a discussion about the design of library extensions in the PND system?
 
23M compressed is pretty much what it will cost as in a PND. That's not much imho. The mono-runtime is larger than that.


I always though about creating a _simple_ dependency system for the PND to cover these use :


- mono


- java


- kdelibs


- timidity patches


- maybe your python-qt binding


But each time I raised this idea I got many "no way in hell" so it have awlays stayd there. maybe this time is the good one ;)


Else the best approch is probably what wizardStan do in his java.pnd : install in /usr/bin/qtpython a script that make sure the PND is mounted before passing the arguments to the right binary :)
 
Short term: Install to SD, with symlinks pointing to it? That'd work .. or if not, install/uninstall to NAND (like the java one) and then work on the future. Or compressed into each pnd for short term is fine .. 20MB is acceptible cost for short term imho.


For long term, a dependancy system.. well, we've talked about it before, and I'm for it ;)


I'm just not able to work on it at this time, so all for you sebt3 :)


jeff
 
While 23M is bearable, your typical python application will be a few hundred KB of source, a megabyte or so for images and then 23M for the GUI library. It's a bit excessive.


If we do decide on a java.pnd like approach, then it would be best to start a python extension PND which includes this and all other frequently used libraries. We should try to avoid having many of these dependency PNDs if possible (unless we do a completely overhaul of the PND system and package management, which is unlikely).


So far we have, correct me if I miss any:

  • Codec pack
  • Java runtime
  • Python runtime extension (i.e. this one). Should TCL be included as well?
 
You mean the Tcl language? Gods, I really despise that, and it shoudln't be related to python at all. (If another pnd installer, fine, but.. not used as much as others.)


Or you mean something else? I'm not familiar offhand with a python tech called 'tcl'?


jeff
 
Yep, that's the one. Tcl/Tk are used by Python's Tkinter and Tix libraries which are the default for GUI construction using Python. I prefer PyQt myself (or even PyGtk). However, because it is the default, many python software relies on Tcl/Tk.


It's not an important issue for me, especially now that PyQt is available.
 
You must log in or register to reply here.

Similar threads

stratego
Can't get pyQT
Replies
8
Views
8K
stratego
stratego
Eric Jardim
PND for PyQt and/or PySide
Replies
6
Views
5K
skeezix
skeezix
Eric Jardim
PyQt4 missing module
Replies
8
Views
7K
Eric Jardim
Eric Jardim
Eric Jardim
Release: mu-0.1
Replies
3
Views
5K
meandu229
M
atomicthumbs
Hellollo
2
Replies
29
Views
6K
⬡
⬡
Back
Top