Latest Reinteract under Windows XP SP2 [Re: Mini reinteract user survey]
Richard Thomas
I've been trying things again on my Windows XP setup, this time trying
to use the "Examples" notebook. Unfortunately my attempts to update my
local copy with GIT have had mixed results (see below) as I don't
really know how to use GIT other than to clone full directory, but
tried from the GUI to do "local merge.." for the 3 recent updates.
Master and "unicode" ones worked but "worksheet printing" failed with
conflicts..
On 23/09/2011 04:27, Owen Taylor wrote:
> Oh, this is the source of your about dialog problems ... Reinteract.pyw is a
> wrapper script that works with the directory layout the installer builds on
> windows. To run uninstalled, you can use the uninst.py file in that same directory.
> (Gives a console window because it's .py not .pyw. There was a bug on Windows that
> I just pushed a fix for that was causing it to blow up.)
Running:
python uninst.py
it gets a step further with not having to hack uinst.py to get it to
startup. If I just start up, then immediately quit there are a huge
number of console warnings of the form:
<gtk.TextMark object at 0x191ff08 (GtkTextMark at 0x1ced6c0)>
If I select the "about" dialog now, no popup appears, but the
following console errors are printed:
D:\Sources\Reinteract\reinteract_from_src\lib\reinteract
\about_dialog.py:56: Warning: GError set over the top of a previous
GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is
NULL before it's set.
The overwriting error message was: Couldn't load bitmap
icon =
gtk.gdk.pixbuf_new_from_file_at_size(global_settings.icon_file, 64,
64)
Traceback (most recent call last):
File "D:\Sources\Reinteract\reinteract_from_src\lib\reinteract
\base_window.py", line 287, in on_about
application.show_about_dialog(self.window)
File "D:\Sources\Reinteract\reinteract_from_src\lib\reinteract
\application.py", line 160, in show_about_dialog
self.__about_dialog = AboutDialog()
File "D:\Sources\Reinteract\reinteract_from_src\lib\reinteract
\about_dialog.py", line 56, in __init__
icon =
gtk.gdk.pixbuf_new_from_file_at_size(global_settings.icon_file, 64,
64)
glib.GError: InvalidParameter
PDF print patch
~~~~~~~~~~~~
Don't know how to apply the patch you supplied. My brief attempt in
GIT bash:
General@DVPC /d/Sources/Reinteract/reinteract_from_src (master)
$ git apply 0001-First-draft-of-Export-to-PDF.patch
error: patch failed: lib/reinteract/editor.py:8
error: lib/reinteract/editor.py: patch does not apply
0001-First-draft-of-Export-to-PDF.patch:187: new blank line at EOF.
which is unfortunate as I'd like to try out this.
Running Examples notebook
~~~~~~~~~~~~~~~~~~~~~~
Everything calculates OK and without console errors, except for
pressing "play" button in Examples/play.rws :
Traceback (most recent call last):
File "D:\Sources\Reinteract\reinteract_from_src\lib\replay.py", line
36, in play
self.__data.tofile(f)
ValueError: 44100 requested and 0 written
>> Printing problems
>> ~~~~~~~~~~~~~~
>> If I use "Print", then select "Preferences" (and mark my preferences -
>> specifically to include print preview), it just ignores them.
> Hmm, testing on Windows 7 with the included "Microsoft XPS Document
> Writer" it seems to work correctly for preference handling. Not sure
> what is going on for you.
Not sure - but if I change my default preferences I can work with
this. Using the Example notebook, everything seems to render nicely in
print preview.
Richard
Owen Taylor
> Hi Owen et Al,
>
> I've been trying things again on my Windows XP setup, this time trying
> to use the "Examples" notebook. Unfortunately my attempts to update my
> local copy with GIT have had mixed results (see below) as I don't
> really know how to use GIT other than to clone full directory, but
> tried from the GUI to do "local merge.." for the 3 recent updates.
> Master and "unicode" ones worked but "worksheet printing" failed with
> conflicts..
I don't really know how to use the GUI. :-) From the CLI, normally
right way to update and get new changes:
git pull --rebase
But if you have local changes, that will refuse to run. To see local
changes, use 'git diff'. To discard local changes:
git checkout . (from the toplevel directory)
git pull --rebase
To save your changes and reapply them:
git stash save
git pull --rebase
git stash pop
To discard your changes, and all local history, like past failed
merges or applied patch:
git fetch origin
git reset --hard origin/master
> Running:
> python uninst.py
> it gets a step further with not having to hack uinst.py to get it to
> startup. If I just start up, then immediately quit there are a huge
> number of console warnings of the form:
> <gtk.TextMark object at 0x191ff08 (GtkTextMark at 0x1ced6c0)>
Since uninst.py is mostly for development, it prints out potentially
leaked objects at exit. Not sure why it might be leaking text marks on
Windows; I'll have to look if I see it too. Not a serious problem
though.
> File "D:\Sources\Reinteract\reinteract_from_src\lib\reinteract
> \about_dialog.py", line 56, in __init__
> icon =
> gtk.gdk.pixbuf_new_from_file_at_size(global_settings.icon_file, 64,
> 64)
> glib.GError: InvalidParameter
Can you add a 'print global_settings.icon_file' line before this and
see from the console output if it looks like the right file?
> PDF print patch
> ~~~~~~~~~~~~
> Don't know how to apply the patch you supplied. My brief attempt in
> GIT bash:
>
> General@DVPC /d/Sources/Reinteract/reinteract_from_src (master)
> $ git apply 0001-First-draft-of-Export-to-PDF.patch
Don't use 'git apply' - use 'git am' (apply mailbox) - which applies a
complete "commit" with authorship information.
> Running Examples notebook
> ~~~~~~~~~~~~~~~~~~~~~~
> Everything calculates OK and without console errors, except for
> pressing "play" button in Examples/play.rws :
>
> Traceback (most recent call last):
> File "D:\Sources\Reinteract\reinteract_from_src\lib\replay.py", line
> 36, in play
> self.__data.tofile(f)
> ValueError: 44100 requested and 0 written
Replay never has been made to work on Windows - possibly should
optionally use pygame or something for playing the sound in a more
cross-platform fashion.
> Not sure - but if I change my default preferences I can work with
> this. Using the Example notebook, everything seems to render nicely in
> print preview.
OK. For reference, what type of printer driver are you using? It might
be a driver specific issue. The other possibility is Windows XP vs. a
more recent Windows.
- Owen
Robert Schroll
> On Mon, Sep 26, 2011 at 7:12 AM, Richard Thomas<uk_r...@yahoo.co.uk> wrote:
>> Running:
>> python uninst.py
>> it gets a step further with not having to hack uinst.py to get it to
>> startup. If I just start up, then immediately quit there are a huge
>> number of console warnings of the form:
>> <gtk.TextMark object at 0x191ff08 (GtkTextMark at 0x1ced6c0)>
>
> Since uninst.py is mostly for development, it prints out potentially
> leaked objects at exit. Not sure why it might be leaking text marks on
> Windows; I'll have to look if I see it too. Not a serious problem
> though.
I don't think this is just a Windows issue - I see the same thing on
Ubuntu 10.04 (both 32 and 64 bit). I had thought this was a sign that
the new leak-prevention code was still being worked on, but evidently
it's not a known issue. Perhaps it's a GTK version thing? (I seem to
have 2.21.1.) A notebook containing a single worksheet containing a
single line gives me:
Live GObjects found at shutdown:
<WorksheetFile object at 0x26039b0
(reinteract+notebook+NotebookFile at 0x2165c00)>
<gtk.TextMark object at 0x262a550 (GtkTextMark at 0x26cdf20)>
<gtk.TextMark object at 0x262b550 (GtkTextMark at 0x2739400)>
<_BgPixbufRenderer object at 0x262baa0
(reinteract+file_list+_BgPixbufRenderer at 0x268e2d0)>
<Worksheet object at 0x2628d70 (reinteract+worksheet+Worksheet at
0x26cdce0)>
<Notebook object at 0x2603b90 (reinteract+notebook+Notebook at
0x1f28ca0)>
<ShellView object at 0x262a5f0 (reinteract+shell_view+ShellView at
0x26df0b0)>
<ShellBuffer object at 0x2628d20
(reinteract+shell_buffer+ShellBuffer at 0x22349b0)>
<WorksheetEditor object at 0x2628870 (reinteract+editor+Editor at
0x26b9400)>
<gtk.TextMark object at 0x262b230 (GtkTextMark at 0x2704440)>
<gtk.TextMark object at 0x262b370 (GtkTextMark at 0x27246a0)>
<gtk.TextTag object at 0x262a280 (GtkTextTag at 0x26bee40)>
<gtk.TextTag object at 0x262a370 (GtkTextTag at 0x26bef00)>
<gtk.TextMark object at 0x262a5a0 (GtkTextMark at 0x26cdd20)>
<gtk.TextTag object at 0x262a190 (GtkTextTag at 0x26bed80)>
<gtk.TextTag object at 0x262a230 (GtkTextTag at 0x26bee00)>
<gtk.TextTag object at 0x262a1e0 (GtkTextTag at 0x26bedc0)>
<gtk.TextTag object at 0x262a320 (GtkTextTag at 0x26beec0)>
<gtk.TextTag object at 0x262a2d0 (GtkTextTag at 0x26bee80)>
<gtk.TextTag object at 0x262a140 (GtkTextTag at 0x26bed40)>
<gtk.TextTag object at 0x262a3c0 (GtkTextTag at 0x26bef40)>
<gtk.TextTag object at 0x262a500 (GtkTextTag at 0x26c2480)>
<gtk.TextTag object at 0x262a410 (GtkTextTag at 0x26bef80)>
<gtk.TextTag object at 0x262a460 (GtkTextTag at 0x26c2400)>
<gtk.TextTag object at 0x262a4b0 (GtkTextTag at 0x26c2440)>
<gtk.ScrolledWindow object at 0x262b4b0 (GtkScrolledWindow at
0x1ff3b40)>
<gtk.Label object at 0x262b730 (GtkLabel at 0x26b81d0)>
<gtk.Image object at 0x262b6e0 (GtkImage at 0x26aae30)>
<FileList object at 0x2628960 (reinteract+file_list+FileList at
0x26ca000)>
<gtk.Window object at 0x2628690 (GtkWindow at 0x2235b30)>
<gtk.Notebook object at 0x2628730 (GtkNotebook at 0x26bd040)>
<gtk.VBox object at 0x26286e0 (GtkVBox at 0x268e1b0)>
<gtk.TreeStore object at 0x26289b0 (GtkTreeStore at 0x26b1b30)>
Having larger worksheets means this is filled up with TextTag and
TextMark objects, to the point that I didn't notice any of the others.
But now that I look at this, it looks like it's reporting just about
everything.
Hrmm,
Robert
Owen Taylor
> On 09/26/2011 10:44 AM, Owen Taylor wrote:
>>
>> On Mon, Sep 26, 2011 at 7:12 AM, Richard Thomas<uk_r...@yahoo.co.uk>
>> wrote:
>>>
>>> Running:
>>> python uninst.py
>>> it gets a step further with not having to hack uinst.py to get it to
>>> startup. If I just start up, then immediately quit there are a huge
>>> number of console warnings of the form:
>>> <gtk.TextMark object at 0x191ff08 (GtkTextMark at 0x1ced6c0)>
>>
>> Since uninst.py is mostly for development, it prints out potentially
>> leaked objects at exit. Not sure why it might be leaking text marks on
>> Windows; I'll have to look if I see it too. Not a serious problem
>> though.
>
> I don't think this is just a Windows issue - I see the same thing on Ubuntu
> 10.04 (both 32 and 64 bit). I had thought this was a sign that the new
> leak-prevention code was still being worked on, but evidently it's not a
> known issue. Perhaps it's a GTK version thing? (I seem to have 2.21.1.) A
> notebook containing a single worksheet containing a single line gives me:
Don't have immediate guesses as to what is the culprit. I have seen
some leakage when doing stuff on Mac and Windows, so I should look at
tracking those down.. didn't fully pay attention earlier.
> Live GObjects found at shutdown:
> <WorksheetFile object at 0x26039b0 (reinteract+notebook+NotebookFile at
> 0x2165c00)>
> <gtk.TextMark object at 0x262a550 (GtkTextMark at 0x26cdf20)>
[...]
> <gtk.TreeStore object at 0x26289b0 (GtkTreeStore at 0x26b1b30)>
>
> Having larger worksheets means this is filled up with TextTag and TextMark
> objects, to the point that I didn't notice any of the others. But now that I
> look at this, it looks like it's reporting just about everything.
The tendency is that once anything is leaked, pretty much everything
is leaked, so the debugging output isn't that useful to track down
problems. One thing you can definitely do is try applying
https://bugzilla.gnome.org/show_bug.cgi?id=659653 - it may fix the
leak, if it doesn't it may narrow the scope down usefully. Beyond that
gc.get_referrers() is very useful, but I didn't figure out how to
productize the debug prints I was doing with that. I should probably
try harder.
- Owen
Owen Taylor
> On Mon, Sep 26, 2011 at 4:12 PM, Robert Schroll <rsch...@gmail.com> wrote:
>> On 09/26/2011 10:44 AM, Owen Taylor wrote:
>>>
>>> On Mon, Sep 26, 2011 at 7:12 AM, Richard Thomas<uk_r...@yahoo.co.uk>
>>> wrote:
>>>>
>>>> Running:
>>>> python uninst.py
>>>> it gets a step further with not having to hack uinst.py to get it to
>>>> startup. If I just start up, then immediately quit there are a huge
>>>> number of console warnings of the form:
>>>> <gtk.TextMark object at 0x191ff08 (GtkTextMark at 0x1ced6c0)>
>>>
>>> Since uninst.py is mostly for development, it prints out potentially
>>> leaked objects at exit. Not sure why it might be leaking text marks on
>>> Windows; I'll have to look if I see it too. Not a serious problem
>>> though.
>>
>> I don't think this is just a Windows issue - I see the same thing on Ubuntu
>> 10.04 (both 32 and 64 bit). I had thought this was a sign that the new
>> leak-prevention code was still being worked on, but evidently it's not a
>> known issue. Perhaps it's a GTK version thing? (I seem to have 2.21.1.) A
>> notebook containing a single worksheet containing a single line gives me:
>
> Don't have immediate guesses as to what is the culprit. I have seen
> some leakage when doing stuff on Mac and Windows, so I should look at
> tracking those down.. didn't fully pay attention earlier.
One thing I found is that if an exception is raised then caught by
PyGObject (like a GObject property accessor rasises an exception),
that seems to leak the objects that are involved - fixed one problem:
http://git.fishsoup.net/cgit/reinteract/commit/?id=4c0731d7dedbcf838c5bde36de4300c6f5d21280
That was causing problems that way.
Also found a pygtk bug -
https://bugzilla.gnome.org/show_bug.cgi?id=660216 - that was causing
PangoLayouts to be leaked when printing worksheets.
I've now considerably improved the debugging display of leaked
objects, so if you are still seeing leaked objects, send along the
debugging output and I can hopefully figure it out. If you are seeing
backtraces on exit, that's very relevant information as well.
- Owen
Robert Schroll
> I've now considerably improved the debugging display of leaked
> objects, so if you are still seeing leaked objects, send along the
> debugging output and I can hopefully figure it out. If you are seeing
> backtraces on exit, that's very relevant information as well.
Here's the output from opening and then closing a notebook consisting of
a single blank worksheet:
Live GObjects found at shutdown:
1 <WorksheetFile object at 0xa2b7a04
(reinteract+notebook+NotebookFile at 0xa028730)>
2 dict
3 property.__dict__['_values']
4 <gobject property worksheet (PyObject)>
5 dict['worksheet']
6 <class 'reinteract.notebook.NotebookFile'>
7 reinteract.notebook.__dict__['NotebookFile']
8 (<class 'reinteract.notebook.NotebookFile'>,
<type 'gobject.GObject'>, <type 'object'>)
6 <class 'reinteract.notebook.NotebookFile'>
9 <class 'reinteract.notebook.WorksheetFile'>
7 reinteract.notebook.__dict__['WorksheetFile']
10 (<class
'reinteract.notebook.WorksheetFile'>, <class
'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>, <type
'object'>)
9 <class 'reinteract.notebook.WorksheetFile'>
11
reinteract.notebook_window.__dict__['WorksheetFile']
12
reinteract.base_notebook_window.__dict__['WorksheetFile']
13 reinteract.file_list.__dict__['WorksheetFile']
14 dict
13
reinteract.file_list.__dict__['_file_class_order']
1 <WorksheetFile object at 0xa2b7a04
(reinteract+notebook+NotebookFile at 0xa028730)>
10 (<class 'reinteract.notebook.WorksheetFile'>,
<class 'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>,
<type 'object'>)
15 <class 'reinteract.notebook.LibraryFile'>
7 reinteract.notebook.__dict__['LibraryFile']
16 (<class 'reinteract.notebook.LibraryFile'>,
<class 'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>,
<type 'object'>)
15 <class 'reinteract.notebook.LibraryFile'>
11
reinteract.notebook_window.__dict__['LibraryFile']
12
reinteract.base_notebook_window.__dict__['LibraryFile']
13 reinteract.file_list.__dict__['LibraryFile']
14 dict
16 (<class 'reinteract.notebook.LibraryFile'>,
<class 'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>,
<type 'object'>)
17 <class 'reinteract.notebook.MiscFile'>
7 reinteract.notebook.__dict__['MiscFile']
18 (<class 'reinteract.notebook.MiscFile'>,
<class 'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>,
<type 'object'>)
17 <class 'reinteract.notebook.MiscFile'>
13 reinteract.file_list.__dict__['MiscFile']
14 dict
18 (<class 'reinteract.notebook.MiscFile'>,
<class 'reinteract.notebook.NotebookFile'>, <type 'gobject.GObject'>,
<type 'object'>)
19 (<class 'reinteract.notebook.NotebookFile'>,)
9 <class 'reinteract.notebook.WorksheetFile'>
20 (<class 'reinteract.notebook.NotebookFile'>,)
15 <class 'reinteract.notebook.LibraryFile'>
21 (<class 'reinteract.notebook.NotebookFile'>,)
17 <class 'reinteract.notebook.MiscFile'>
11
reinteract.notebook_window.__dict__['NotebookFile']
12
reinteract.base_notebook_window.__dict__['NotebookFile']
22 <cell at 0xa06747c: GObjectMeta object at
0xa0fa6cc>
23 (<cell at 0xa06747c: GObjectMeta object at
0xa0fa6cc>,)
24 <function obj_get_property at 0xa093064>
5 dict['do_get_property']
25 (<cell at 0xa06747c: GObjectMeta object at
0xa0fa6cc>,)
26 <function obj_set_property at 0xa09325c>
5 dict['do_set_property']
27 reinteract.base_window.__dict__['NotebookFile']
13 reinteract.file_list.__dict__['NotebookFile']
28 reinteract.editor.__dict__['NotebookFile']
29 reinteract.worksheet.__dict__['NotebookFile']
30 reinteract.shell_view.__dict__['NotebookFile']
31 <bound method property._default_getter of <gobject
property worksheet (PyObject)>>
3 property.__dict__['getter']
32 <bound method property._default_setter of <gobject
property worksheet (PyObject)>>
3 property.__dict__['setter']
33 dict
34 property.__dict__['_values']
35 <gobject property modified (gboolean)>
5 dict['modified']
36 <bound method property._default_getter of <gobject
property modified (gboolean)>>
34 property.__dict__['getter']
37 <bound method property._default_setter of <gobject
property modified (gboolean)>>
34 property.__dict__['setter']
38 dict
39 property.__dict__['_values']
40 <gobject property state (gint)>
5 dict['state']
41 <bound method property._default_getter of <gobject
property state (gint)>>
39 property.__dict__['getter']
42 <bound method property._default_setter of <gobject
property state (gint)>>
39 property.__dict__['setter']
43 dict
44 property.__dict__['_values']
45 <gobject property active (gboolean)>
5 dict['active']
46 <bound method property._default_getter of <gobject
property active (gboolean)>>
44 property.__dict__['getter']
47 <bound method property._default_setter of <gobject
property active (gboolean)>>
44 property.__dict__['setter']
48 <_BgPixbufRenderer object at 0xa2d7194
(reinteract+file_list+_BgPixbufRenderer at 0x9f3dcc0)>
49 dict
50 property.__dict__['_values']
51 <gobject property background_gdk (PyObject)>
52 dict['background_gdk']
53 <class 'reinteract.file_list._BgPixbufRenderer'>
54 (<class
'reinteract.file_list._BgPixbufRenderer'>, <type
'gtk.CellRendererPixbuf'>, <type 'gtk.CellRenderer'>, <type
'gtk.Object'>, <type 'gobject.GObject'>, <type 'object'>)
53 <class
'reinteract.file_list._BgPixbufRenderer'>
13 reinteract.file_list.__dict__['_BgPixbufRenderer']
55 <cell at 0xa067524: GObjectMeta object at
0xa10048c>
56 (<cell at 0xa067524: GObjectMeta object at
0xa10048c>,)
57 <function obj_get_property at 0xa1dc8b4>
52 dict['do_get_property']
58 (<cell at 0xa067524: GObjectMeta object at
0xa10048c>,)
59 <function obj_set_property at 0xa1dc924>
52 dict['do_set_property']
48 <_BgPixbufRenderer object at 0xa2d7194
(reinteract+file_list+_BgPixbufRenderer at 0x9f3dcc0)>
60 <bound method property._default_getter of <gobject
property background_gdk (PyObject)>>
50 property.__dict__['getter']
61 <bound method property._default_setter of <gobject
property background_gdk (PyObject)>>
50 property.__dict__['setter']
Hope that means something to you,
Robert
Owen Taylor
> On 09/27/2011 12:58 AM, Owen Taylor wrote:
>>
>> I've now considerably improved the debugging display of leaked
>> objects, so if you are still seeing leaked objects, send along the
>> debugging output and I can hopefully figure it out. If you are seeing
>> backtraces on exit, that's very relevant information as well.
>
> Here's the output from opening and then closing a notebook consisting of a
> single blank worksheet:
> Live GObjects found at shutdown:
> 1 <WorksheetFile object at 0xa2b7a04 (reinteract+notebook+NotebookFile at
> 0xa028730)>
> 2 dict
> 3 property.__dict__['_values']
> 4 <gobject property worksheet (PyObject)>
[...]
> Hope that means something to you,
Yeah - very useful. This is a bug that was fixed in pygobject.
https://bugzilla.gnome.org/show_bug.cgi?id=644039
Can you try the attached and see if it works around the problem successfully?
- Owen
Robert Schroll
> Yeah - very useful. This is a bug that was fixed in pygobject.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=644039
>
> Can you try the attached and see if it works around the problem successfully?
That works for me.
Thanks,
Robert