I just moved to a new machine with Fedora Core 2 and I took the opportunity to install wxPython 2.5.3.1. I'm now getting the following:
[pmcnett@localhost daboide]$ python
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> app = wx.PySimpleApp()
>>> dlg = wx.FileDialog(None)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "wx/_windows.py", line 2359, in __init__
wx._core.PyAssertionError: C++ assertion "nLen != (size_t)-1" failed in ../src/common/string.cpp(1060)
>>>
This is GTK2/Unicode. The same sample run on 2.5.2.7 does not cause this assertion error.
I just moved to a new machine with Fedora Core 2 and I took the opportunity to install wxPython 2.5.3.1. I'm now getting the following:
[pmcnett@localhost daboide]$ python
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> app = wx.PySimpleApp()
>>> dlg = wx.FileDialog(None)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "wx/_windows.py", line 2359, in __init__
wx._core.PyAssertionError: C++ assertion "nLen != (size_t)-1" failed in ../src/common/string.cpp(1060)
>>>
This is a known problem. It results from the code in wx.MimeTypesManager that is reading the various config files where mime settings are stored, and the fact that one of them on Fedora has some non ascii characters in it and so the unicode convertion code is failing.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I just moved to a new machine with Fedora Core 2 and I took the opportunity to install wxPython 2.5.3.1. I'm now getting the following:
[pmcnett@localhost daboide]$ python
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> app = wx.PySimpleApp()
>>> dlg = wx.FileDialog(None)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "wx/_windows.py", line 2359, in __init__
wx._core.PyAssertionError: C++ assertion "nLen != (size_t)-1" failed in ../src/common/string.cpp(1060)
>>>
This is a known problem. It results from the code in wx.MimeTypesManager that is reading the various config files where mime settings are stored, and the fact that one of them on Fedora has some non ascii characters in it and so the unicode convertion code is failing.
Okay thanks. Believe it or not, Google appears to be down right now so I can't search on the solution - is it something to be fixed in wx or in Fedora?
This is a known problem. It results from the code in wx.MimeTypesManager that is reading the various config files where mime settings are stored, and the fact that one of them on Fedora has some non ascii characters in it and so the unicode convertion code is failing.
Okay thanks. Believe it or not, Google appears to be down right now so I can't search on the solution - is it something to be fixed in wx or in Fedora?
It's something that wx needs to fix. It shouldn't be assuming that config files are in any particular encoding. I've checked to see if a fix has been checked in yet but I don't see anything, but I may still be looking at the history for the wrong file...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
This is a known problem. It results from the code in wx.MimeTypesManager that is reading the various config files where mime settings are stored, and the fact that one of them on Fedora has some non ascii characters in it and so the unicode convertion code is failing.
Okay thanks. Believe it or not, Google appears to be down right now so I can't search on the solution - is it something to be fixed in wx or in Fedora?
It's something that wx needs to fix. It shouldn't be assuming that config files are in any particular encoding. I've checked to see if a fix has been checked in yet but I don't see anything, but I may still be looking at the history for the wrong file...