[Bitpim-devel] 2.5 update on Mac feedback

[Peter Dufault]

This release is now bulletproof (OK, for the subset of things that I
do) on the Mac with the LG VX4500.

I've downloaded lots of wallpapers, ringtones, and phonelists, added
new ones, uploaded old ones, deleted, etc. without a single crash.
Haven't done import and export with this version, and I don't use speed
dials or the calendar (yet).

I did notice (this has probably always been this way) that I can't
rename wallpaper images. Right-click offers a "Rename" choice but it
doesn't seem to do anything, nor does double clicking on the name let
you edit it.

Also, now that it is solid and I used it for a while (I used to quit
often just to "checkpoint" things) to test things I miss the common
accelerator keys. Maybe I'm smart enough to figure out how to add
those.

Thanks -

Peter

Peter Dufault
HD Associates, Inc.

[Roger Binns]

Post by Peter Dufault
This release is now bulletproof (OK, for the subset of things that I
do) on the Mac with the LG VX4500.

That is very good to hear. BTW are you using a unicode build?

python -c "import wx; print wx.USE_UNICODE"

Post by Peter Dufault
Haven't done import and export with this version, and I don't use
speed dials or the calendar (yet).

The import code has has pretty scary combinations of widgets.

Post by Peter Dufault
I did notice (this has probably always been this way) that I can't
rename wallpaper images. Right-click offers a "Rename" choice but it
doesn't seem to do anything, nor does double clicking on the name let
you edit it.

Correct. I never implemented it. I am still not happy with the user
interface for the ringtones and wallpapers and am going to write
yet another one.

Post by Peter Dufault
Also, now that it is solid and I used it for a while (I used to quit
often just to "checkpoint" things)

You did notice a lack of save menu? BitPim saves all changes immediately
when they are made. There is no need for a user to have to know
the difference between volatile memory (RAM) and persisten memory
(hard disk) or manage the movement of data between them.

Post by Peter Dufault
to test things I miss the common accelerator keys.

Which ones?

Roger

[Peter Dufault]

On Aug 27, 2004, at 7:08 PM, Roger Binns wrote:

I used to quit out of paranoia, so Roger notes -

Post by Roger Binns
You did notice a lack of save menu? BitPim saves all changes
immediately
when they are made. There is no need for a user to have to know
the difference between volatile memory (RAM) and persisten memory
(hard disk) or manage the movement of data between them.

Yes I know that, but I still felt more comfortable quitting. "The best
laid plans" are suspect when an application is randomly crashing. No
reflection on your code, as the new release confirms.

I'll make a list of missing accelerator keys and contexts.

Peter

Peter Dufault
HD Associates, Inc.

[Roger Binns]

Post by Peter Dufault
Yes I know that, but I still felt more comfortable quitting. "The
best laid plans" are suspect when an application is randomly
crashing. No reflection on your code, as the new release confirms.

I didn't take it as a code issue, just that it was pointless
or a placebo. Unless there was data corruption in the internals
of Python, "checkpointing" did nothing.

Roger

[Peter Dufault]

Post by Roger Binns
I didn't take it as a code issue, just that it was pointless
or a placebo. Unless there was data corruption in the internals
of Python, "checkpointing" did nothing.

Pointless? No.

You're saying that quitting to be sure that an application that
randomly crashed but intended to be stateless and would always be in a
good state is pointless.

How can I dismiss what you imply is so unlikely - "data corruption in
the internals of Python"? (I'm an outsider, remember?) There's an
obvious problem in the internals of Bitpim from an outsider's point of
view, for the previous implementation.

You said it was just wxpythonfoobar, and not "python" or "bitpim", that
was broken. I thought you were right, and I think the new release
bears you out. Until now I always wondered if it might not have been
some minor threading issue in bitpim that would persist beyond the
upgrade.

If you were testing an application (that you knew intended to be
stateless) that had a nasty habit of crashing, and you knew that said
crashing would be cleaned up as soon as the app was moved to the new
release of the broken toolkit, and as such that crashing wasn't one of
the things being tested, then why wouldn't you just quit after doing
anything major to avoid one of those crashes?

I bet you'd have been just as likely as I to quit to ensure everything
was in a good state.

Peter

Peter Dufault
HD Associates, Inc.

[Roger Binns]

Post by Peter Dufault
You said it was just wxpythonfoobar, and not "python" or "bitpim",
that was broken. I thought you were right, and I think the new
release bears you out. Until now I always wondered if it might not
have been some minor threading issue in bitpim that would persist
beyond the upgrade.

All the stack traces always pointed the finger firmly at wxPython.
I certainly understand your wariness and suspicion of threading
issues.

The previous major commercial program I worked on was a seriously
multi-threaded server program in Java. You have to architect and
implement those right, or get badly burnt.

Python has a simpler threading model. In particular there is a
global interpretter lock (GIL) and only one thread at a time will
be running Python code. Various C extensions then have the
ability to release and acquire the GIL. For example my C code
that reads from the USB port looks like this:

int res;
Py_BEGIN_ALLOW_THREADS
res=usb_bulk_read(dev, ep, bytesoutbuffer, *bytesoutbuffersize, timeout);
Py_END_ALLOW_THREADS
return;

So ultimately C extension code can actually execute concurrently
for anything that is between Py_{BEGIN,END}_ALLOW_THREADS.
However Python code does not execute concurrently. If
you started two threads doing this:

while True: pass

Then the Python interpretter would keep switching between them. No
matter how many CPUs you had, Python would use at most one with
each thread getting half the CPU time.

The thread switching boundary is a bytecode instruction.
That means that all operations at the bytecode level are
atomic, and the bytecode instructions are very high level.

Contrast that with Java where reading/writing to a long
(64 bit quantity) is not atomic, and you do have actual
multiple concurrent threads, and the thread switching
boundary is whatever the CPU accepts (typically a machine
instruction).

Given all that, I can't actually think of a way of corrupting
information/state in Python if I deliberately wanted to.
In Java it doesn't take much :-)

Additionally the wxPython/wxWidgets library is not thread safe
(by design). All GUI stuff must happen in one thread. If
you do not do so then things will come crashing down VERY
quickly.

Finally the threading is done very carefully. There are
exactly two threads (*). One thread does all the GUI
work and almost all the other work as well. The second
thread does the communication with the phone.

The communication between the threads is done using Python's
Queue.Queue object from one to two, and using wx.PostMessage
(a primitive designed for this in wxPython) from two to one.
Data ownership is transferred with the messages or a copy
is sent. In any event data/state can't be corrupted at
the C level because of the GIL, and if bad things were
being done by the code would result in a Python exception
in the worst case.

(*) There are actually more threads if you use BitFling.

So your thread paranoia would be appropriate for Java based
programs, very appropriate for C programs and really doesn't
apply for Python programs.

About the only threading issue with Python programs that
people have is that pure Python code won't scale to
multiple CPUs. The solution is either to use C extension
libraries with Py_{BEGIN,END}_ALLOW_THREADS or multiple
processes.

Roger

[Peter Dufault]

Post by Roger Binns
That is very good to hear. BTW are you using a unicode build?
python -c "import wx; print wx.USE_UNICODE"

No, I guess not:

[skinny:~/work/bitpim] dufault% pythonw -c "import wx; print
wx.USE_UNICODE"
0

I pulled down the 2.5 binary release for OS X. I should look for a 2.5
binary build with unicode support for the Mac or roll my own, correct?

Peter


Peter Dufault
HD Associates, Inc.

[Roger Binns]

Post by Peter Dufault
[skinny:~/work/bitpim] dufault% pythonw -c "import wx; print
wx.USE_UNICODE"
0

BitPim should work both ways, but I want the distributed versions
to be unicode only.

It would be good to hear about any Mac specific unicode issues
sooner rather than later :-)

Roger

[Steven Palm]

Post by Roger Binns

Post by Peter Dufault
[skinny:~/work/bitpim] dufault% pythonw -c "import wx; print
wx.USE_UNICODE"
0

BitPim should work both ways, but I want the distributed versions
to be unicode only.

Probably not a reality....

$ python setup.py UNICODE=1 build_ext
UNICODE mode not currently supported on this WXPORT: mac

Post by Roger Binns
It would be good to hear about any Mac specific unicode issues
sooner rather than later :-)

There ya go. ;-)

[Roger Binns]

Post by Steven Palm

Post by Roger Binns
BitPim should work both ways, but I want the distributed versions
to be unicode only.

Probably not a reality....
$ python setup.py UNICODE=1 build_ext
UNICODE mode not currently supported on this WXPORT: mac

Post by Roger Binns
It would be good to hear about any Mac specific unicode issues
sooner rather than later :-)

There ya go. ;-)

That is a bit of a bummer. Oh well, we'll have to live with
the Mac stuff being ASCII and the other platforms being better.

Since all my machines are now running Unicode versions of
wxPython, it does place a little extra onus on Mac folks
to do more testing to ensure things don't fall over.

Roger

[Steven Palm]

Post by Roger Binns

Post by Steven Palm

Post by Roger Binns
BitPim should work both ways, but I want the distributed versions
to be unicode only.

Probably not a reality....
$ python setup.py UNICODE=1 build_ext
UNICODE mode not currently supported on this WXPORT: mac

Post by Roger Binns
It would be good to hear about any Mac specific unicode issues
sooner rather than later :-)

There ya go. ;-)

That is a bit of a bummer. Oh well, we'll have to live with
the Mac stuff being ASCII and the other platforms being better.
Support for unicode was recently added to wxMac (Panther only) but I
havn't had time yet to update the wxPython build system to support it
and to do testing. Perhaps with 2.5.3.

So it's on the way sooner or later....