ANN: Namespace Diff Tool (NDT)

Hi All,

I am happy to (finally) announce the birth of the Namespace Diff Tool (NDT); after soooo much effort and grief version 0.1 is available for those of you willing to try it.

Description

···

===========

The Namespace Diff Tool (NDT) is a graphical user interface that can

be used to discover differences between different versions of a library,

or even between different iterations/sub-versions of the same library.

The tool can be used to identify what is missing and still needs to be

implemented, or what is new in a new release, which items do not have

docstrings and so on.

Full description of the original idea by Robin Dunn:

http://svn.wxwidgets.org/viewvc/wx/wxPython/Phoenix/trunk/TODO.txt?view=markup

:warning: As most of the widgets in the GUI are owner drawn or custom,

it is highly probable that the interface itself will look messy on other

platforms (Mac, I am talking to you). Please do try and create a patch to

fix any possible issue in this sense.

:note: Please refer to the TODOs section for a list of things that still need

to be implemented.

Requirements

============

In order to run NDT, these packages need to be installed:

  • Python 2.X (where 5 <= X <= 7);

  • wxPython >= 2.8.10;

  • SQLAlchemy >= 0.6.4.

More detailed instructions on how to use it, TODO items, list of libraries/packages I tested NDT against, screenshots and download links can be found here:

http://xoomer.virgilio.it/infinity77/main/NDT.html

If you stumble upon a bug (which is highly probable), please do let me know. But most importantly, please do try and make an effort to create a patch for the bug.

Enjoy, wxPython rules.

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

import PyQt4.QtGui

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named PyQt4.QtGui

import pygtk

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named pygtk

import wx

Hi All,

     I am happy to (finally) announce the birth of the Namespace Diff
Tool (NDT); after soooo much effort and grief version 0.1 is available
for those of you willing to try it.

Thanks for doing this Andrea. It looks great. Do you have a way to compare classes that may not be in the same module between the 2 libraries? For example wx.Window lives in wx._core in Classic wxPython, but it is in wx.core in Phoenix.

:warning: As most of the widgets in the GUI are owner drawn or custom,
  it is highly probable that the interface itself will look messy on other
  platforms (Mac, I am talking to you). Please do try and create a patch to
  fix any possible issue in this sense.

As predicted, there is an issue on the Mac. It's getting a wx.PyAssertionError at startup due to images of different sizes being loaded into a wx.ImageList.

Traceback (most recent call last):
   File "NDT.py", line 1655, in <module>
     app = NDTApp()
   File "NDT.py", line 1548, in __init__
     wx.App.__init__(self, False)
   File "/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py", line 7981, in __init__
     self._BootstrapApp()
   File "/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py", line 7555, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File "NDT.py", line 1556, in OnInit
     self.frame = NDT()
   File "NDT.py", line 325, in __init__
     self.dbPanelTree = DBPanelTree(self)
   File "/Users/robind/Desktop/NDT/dbtree.py", line 15, in __init__
     self.dbTree = DBTree(self)
   File "/Users/robind/Desktop/NDT/dbtree.py", line 87, in __init__
     self.BuildLeftImageList()
   File "/Users/robind/Desktop/NDT/dbtree.py", line 146, in BuildLeftImageList
     imglist.Add(bmp)
   File "/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_gdi.py", line 6146, in Add
     return _gdi_.ImageList_Add(*args, **kwargs)
PyAssertionError: C++ assertion "(bitmap.GetWidth() >= m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)" failed at /BUILD/wxPython-src-2.8.12.1/src/mac/carbon/imaglist.cpp(80) in Add(): invalid bitmap size in wxImageList:

···

On 11/9/11 1:29 PM, Andrea Gavana wrote:

--
Robin Dunn
Software Craftsman

Hi Robin,

Hi All,

 I am happy to (finally) announce the birth of the Namespace Diff

Tool (NDT); after soooo much effort and grief version 0.1 is available

for those of you willing to try it.

Thanks for doing this Andrea. It looks great. Do you have a way to compare classes that may not be in the same module between the 2 libraries? For example wx.Window lives in wx._core in Classic wxPython, but it is in wx.core in Phoenix.

Ah, this is a bit of a complication… at the moment, every object uniqueness in the NDT tree is guaranteed by its full name - with the “.name” attribute set inside NDT - (i.e., wx.Window is actually wx._core.Window, while AddCheckTool in AuiToolBar is actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from “_core” to “core” will simply tell NDT that the “_core” module is present only in Classic while “core” only in Phoenix, and the two hierarchies will not match…

The only way I see at the moment is to make up a hack for wx only for which the underscored modules are stripped off the underscore (i.e., “_core” will become “core” internally), but this will work smoothly only if you choose Phoenix to be library 1 and Classic to be library 2. It’s rather ugly :frowning:

I am of course open to other suggestions on how to modify the comparison code in the librarydescription.py module in order not to rely on full names.

:warning: As most of the widgets in the GUI are owner drawn or custom,

it is highly probable that the interface itself will look messy on other

platforms (Mac, I am talking to you). Please do try and create a patch to

fix any possible issue in this sense.

As predicted, there is an issue on the Mac. It’s getting a wx.PyAssertionError at startup due to images of different sizes being loaded into a wx.ImageList.

Traceback (most recent call last):

File “NDT.py”, line 1655, in

app = NDTApp()

File “NDT.py”, line 1548, in init

wx.App.__init__(self, False)

File “/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py”, line 7981, in init

self._BootstrapApp()

File “/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py”, line 7555, in _BootstrapApp

return _core_.PyApp__BootstrapApp(*args, **kwargs)

File “NDT.py”, line 1556, in OnInit

self.frame = NDT()

File “NDT.py”, line 325, in init

self.dbPanelTree = DBPanelTree(self)

File “/Users/robind/Desktop/NDT/dbtree.py”, line 15, in init

self.dbTree = DBTree(self)

File “/Users/robind/Desktop/NDT/dbtree.py”, line 87, in init

self.BuildLeftImageList()

File “/Users/robind/Desktop/NDT/dbtree.py”, line 146, in BuildLeftImageList

imglist.Add(bmp)

File “/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_gdi.py”, line 6146, in Add

return _gdi_.ImageList_Add(*args, **kwargs)

PyAssertionError: C++ assertion “(bitmap.GetWidth() >= m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)” failed at /BUILD/wxPython-src-2.8.12.1/src/mac/carbon/imaglist.cpp(80) in Add(): invalid bitmap size in wxImageList:

I knew something like that would happen… I have fixed them in my code here and I’ll upload a new version when I get back home.

Thank you for your comments and suggestions.

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 02:12, Robin Dunn wrote:

On 11/9/11 1:29 PM, Andrea Gavana wrote:

You can introduce 'filters' while loading or comparing.

HTH
Niki

···

On 10.11.2011 11:11, Andrea Gavana wrote:

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

Hi.

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

You can introduce 'filters' while loading or comparing.

I'm sorry, is this supposed to be a helpful suggestion? If it is, I
don't understand it.

Currently the comparison is relatively fast because while traversing
the tree the comparison is made using set() operations on item full
names. The only way to account for partially different names is to run
a heuristic/fuzzy search (possibly with difflib.SequenceMatcher)
discarding "junk" chars (such as underscores) while comparing. That
will probably slow down the entire tree traversing stuff, but I'll
give it a try anyway.

Filters won't help even a little because on those situations in which
I may have two classes like:

wx._core.Window
wx.lib.Window (non existent, but it may exist)

Any filter will break down. And I have seen many class re-definition
(or duplication) as in the example above in many libraries (numpy is
one).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 12:17, niki wrote:

On 10.11.2011 11:11, Andrea Gavana wrote:

Actually I was not thinking things all the way through and in this case wx.Window is wx._core.Window in Phoenix, but for some reason NDT is showing it in wx.core. I'll get you a set of binaries to play with yourself but here are some oddities about what I'm seeing in the NDT scan of Phoenix:

* It's showing the core module in the tree, but not _core. For Phoenix the _core module is the C++ extension module and core is a .py file that does a "from _core import *"

* Only a few of the classes that live in _core are showing up in the tree.

* For those that are there NDT is showing that they only have 1 method, __init__.

* Although most classes are not being shown in the tree, if I type the name of a missing class in the Filter widget then that class' methods are shown.

However, even though in this case wx.Window will end up in a module that matches its location in Classic, that will not be the case for others, and it won't be a simple dropping of the underscore either as I'm planning on some reorganization of the divisions between the extension modules. So it would be nice if there was a way to tell NDT to treat moduleA in library 1 the same as moduleB in library 2. Or maybe having a way to just compare subsets would be good enough, such as comparing wx._windows.Panel in library 1 and wx._core.Panel in library 2. Or finally, maybe it would work to be able to toggle to a mode where it doesn't ignore items that are seen in modules where they are not defined, for example wx.Window, wx.Panel, and wx.DC will exist in both Classic and Phoenix but the actual classes will be defined in different "real" locations.

···

On 11/10/11 1:11 AM, Andrea Gavana wrote:

Hi Robin,

On 10 November 2011 02:12, Robin Dunn wrote:

    On 11/9/11 1:29 PM, Andrea Gavana wrote:

        Hi All,

             I am happy to (finally) announce the birth of the Namespace
        Diff
        Tool (NDT); after soooo much effort and grief version 0.1 is
        available
        for those of you willing to try it.

    Thanks for doing this Andrea. It looks great. Do you have a way to
    compare classes that may not be in the same module between the 2
    libraries? For example wx.Window lives in wx._core in Classic
    wxPython, but it is in wx.core in Phoenix.

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

--
Robin Dunn
Software Craftsman

Hi Robin,

Hi Robin,

   Hi All,

        I am happy to \(finally\) announce the birth of the Namespace
   Diff
   Tool \(NDT\); after soooo much effort and grief version 0\.1 is
   available
   for those of you willing to try it\.

Thanks for doing this Andrea. It looks great. Do you have a way to
compare classes that may not be in the same module between the 2
libraries? For example wx.Window lives in wx._core in Classic
wxPython, but it is in wx.core in Phoenix.

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

Actually I was not thinking things all the way through and in this case
wx.Window is wx._core.Window in Phoenix, but for some reason NDT is showing
it in wx.core. I'll get you a set of binaries to play with yourself but
here are some oddities about what I'm seeing in the NDT scan of Phoenix:
* It's showing the core module in the tree, but not _core. For Phoenix the
_core module is the C++ extension module and core is a .py file that does a
"from _core import *"

* Only a few of the classes that live in _core are showing up in the tree.

* For those that are there NDT is showing that they only have 1 method,
__init__.

I think I know the reason why NDT is doing this, but anyway, if you
can provide the binaries for Phoenix I'll see if the issue is really
where i think it is and I'll fix it.

* Although most classes are not being shown in the tree, if I type the name
of a missing class in the Filter widget then that class' methods are shown.

You may want to check the option "Show 'inherited' items" under the
Options menu and see if it changes anything. If it doesn't, I would
really need to see what's wrong with NDT using the Phoenix binaries.

However, even though in this case wx.Window will end up in a module that
matches its location in Classic, that will not be the case for others, and
it won't be a simple dropping of the underscore either as I'm planning on
some reorganization of the divisions between the extension modules. So it
would be nice if there was a way to tell NDT to treat moduleA in library 1
the same as moduleB in library 2. Or maybe having a way to just compare
subsets would be good enough, such as comparing wx._windows.Panel in library
1 and wx._core.Panel in library 2. Or finally, maybe it would work to be
able to toggle to a mode where it doesn't ignore items that are seen in
modules where they are not defined, for example wx.Window, wx.Panel, and
wx.DC will exist in both Classic and Phoenix but the actual classes will be
defined in different "real" locations.

Yes, the last option is the easiest one, and as it is implemented
right now I believe we are already half way to get what you want:
simply uncheck the "Show 'inherited' items" in the "Options" menu and
then I'll provide another option to not to grey-out "inherited" items
in the tree. At this point, if wxPython and Phoenix both have a
"wx.Window" attribute you will be able to see the differences.
Hopefully I have understood correctly what you meant...

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 20:27, Robin Dunn wrote:

On 11/10/11 1:11 AM, Andrea Gavana wrote:

On 10 November 2011 02:12, Robin Dunn wrote:
On 11/9/11 1:29 PM, Andrea Gavana wrote:

Hi Robin,

Hi Robin,

        Hi All,

             I am happy to (finally) announce the birth of the Namespace
        Diff
        Tool (NDT); after soooo much effort and grief version 0.1 is
        available
        for those of you willing to try it.

    Thanks for doing this Andrea. It looks great. Do you have a way to
    compare classes that may not be in the same module between the 2
    libraries? For example wx.Window lives in wx._core in Classic
    wxPython, but it is in wx.core in Phoenix.

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

Actually I was not thinking things all the way through and in this case
wx.Window is wx._core.Window in Phoenix, but for some reason NDT is showing
it in wx.core. I'll get you a set of binaries to play with yourself but
here are some oddities about what I'm seeing in the NDT scan of Phoenix:
* It's showing the core module in the tree, but not _core. For Phoenix the
_core module is the C++ extension module and core is a .py file that does a
"from _core import *"

* Only a few of the classes that live in _core are showing up in the tree.

* For those that are there NDT is showing that they only have 1 method,
__init__.

I think I know the reason why NDT is doing this, but anyway, if you
can provide the binaries for Phoenix I'll see if the issue is really
where i think it is and I'll fix it.

* Although most classes are not being shown in the tree, if I type the name
of a missing class in the Filter widget then that class' methods are shown.

You may want to check the option "Show 'inherited' items" under the
Options menu and see if it changes anything. If it doesn't, I would
really need to see what's wrong with NDT using the Phoenix binaries.

Ah, I hadn't noticed that option. Yes the missing classes show up if I check that menu item.

However, even though in this case wx.Window will end up in a module that
matches its location in Classic, that will not be the case for others, and
it won't be a simple dropping of the underscore either as I'm planning on
some reorganization of the divisions between the extension modules. So it
would be nice if there was a way to tell NDT to treat moduleA in library 1
the same as moduleB in library 2. Or maybe having a way to just compare
subsets would be good enough, such as comparing wx._windows.Panel in library
1 and wx._core.Panel in library 2. Or finally, maybe it would work to be
able to toggle to a mode where it doesn't ignore items that are seen in
modules where they are not defined, for example wx.Window, wx.Panel, and
wx.DC will exist in both Classic and Phoenix but the actual classes will be
defined in different "real" locations.

Yes, the last option is the easiest one, and as it is implemented
right now I believe we are already half way to get what you want:
simply uncheck the "Show 'inherited' items" in the "Options" menu and
then I'll provide another option to not to grey-out "inherited" items
in the tree. At this point, if wxPython and Phoenix both have a
"wx.Window" attribute you will be able to see the differences.
Hopefully I have understood correctly what you meant...

Yep, I think you do.

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

There was a similar issue discovered recently in the demo, apparently GTK has a problem if there are new windows being created while parents are frozen. (Which unfortunately is one of the things that you normally would want to use Freeze for...) Here is the ticket I created for it:

http://trac.wxwidgets.org/ticket/13543

And here is the workaround I implemented. It basically just ignores Freeze/Thaw on wxGTK for the parent window that has the demo notebook and such within it. Since GTK is composting/buffering anyway this does not cause any noticeable problems.

http://trac.wxwidgets.org/changeset/69426/wxPython/trunk/demo

···

On 11/10/11 12:38 PM, Andrea Gavana wrote:

On 10 November 2011 20:27, Robin Dunn wrote:

On 11/10/11 1:11 AM, Andrea Gavana wrote:

On 10 November 2011 02:12, Robin Dunn wrote:
    On 11/9/11 1:29 PM, Andrea Gavana wrote:

--
Robin Dunn
Software Craftsman

Hi Robin,

Hi Robin,

   Hi All,

        I am happy to \(finally\) announce the birth of the Namespace
   Diff
   Tool \(NDT\); after soooo much effort and grief version 0\.1 is
   available
   for those of you willing to try it\.

Thanks for doing this Andrea. It looks great. Do you have a way to
compare classes that may not be in the same module between the 2
libraries? For example wx.Window lives in wx._core in Classic
wxPython, but it is in wx.core in Phoenix.

Ah, this is a bit of a complication... at the moment, every object
uniqueness in the NDT tree is guaranteed by its full name - with the
".name" attribute set inside NDT - (i.e., wx.Window is
actually wx._core.Window, while AddCheckTool in AuiToolBar is
actually wx.lib.agw.aui.auibar.AuiToolBar.AddCheckTool). Changing from
"_core" to "core" will simply tell NDT that the "_core" module is
present only in Classic while "core" only in Phoenix, and the two
hierarchies will not match...

The only way I see at the moment is to make up a hack for wx only for
which the underscored modules are stripped off the underscore (i.e.,
"_core" will become "core" internally), but this will work smoothly only
if you choose Phoenix to be library 1 and Classic to be library 2. It's
rather ugly :frowning:

Actually I was not thinking things all the way through and in this case
wx.Window is wx._core.Window in Phoenix, but for some reason NDT is
showing
it in wx.core. I'll get you a set of binaries to play with yourself but
here are some oddities about what I'm seeing in the NDT scan of Phoenix:
* It's showing the core module in the tree, but not _core. For Phoenix
the
_core module is the C++ extension module and core is a .py file that does
a
"from _core import *"

* Only a few of the classes that live in _core are showing up in the
tree.

* For those that are there NDT is showing that they only have 1 method,
__init__.

I think I know the reason why NDT is doing this, but anyway, if you
can provide the binaries for Phoenix I'll see if the issue is really
where i think it is and I'll fix it.

* Although most classes are not being shown in the tree, if I type the
name
of a missing class in the Filter widget then that class' methods are
shown.

You may want to check the option "Show 'inherited' items" under the
Options menu and see if it changes anything. If it doesn't, I would
really need to see what's wrong with NDT using the Phoenix binaries.

Ah, I hadn't noticed that option. Yes the missing classes show up if I
check that menu item.

However, even though in this case wx.Window will end up in a module that
matches its location in Classic, that will not be the case for others,
and
it won't be a simple dropping of the underscore either as I'm planning on
some reorganization of the divisions between the extension modules. So
it
would be nice if there was a way to tell NDT to treat moduleA in library
1
the same as moduleB in library 2. Or maybe having a way to just compare
subsets would be good enough, such as comparing wx._windows.Panel in
library
1 and wx._core.Panel in library 2. Or finally, maybe it would work to be
able to toggle to a mode where it doesn't ignore items that are seen in
modules where they are not defined, for example wx.Window, wx.Panel, and
wx.DC will exist in both Classic and Phoenix but the actual classes will
be
defined in different "real" locations.

Yes, the last option is the easiest one, and as it is implemented
right now I believe we are already half way to get what you want:
simply uncheck the "Show 'inherited' items" in the "Options" menu and
then I'll provide another option to not to grey-out "inherited" items
in the tree. At this point, if wxPython and Phoenix both have a
"wx.Window" attribute you will be able to see the differences.
Hopefully I have understood correctly what you meant...

Yep, I think you do.

Here you go then, implemented and uploaded in the new version (see
link below for a screenshot comparing wx.Window in 2.9.2.4 against
2.8.12.1 - both are "inherited" attributes as they normally live in
wx._core but they show up directly below the "wx" tree item).

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

There was a similar issue discovered recently in the demo, apparently GTK
has a problem if there are new windows being created while parents are
frozen. (Which unfortunately is one of the things that you normally would
want to use Freeze for...) Here is the ticket I created for it:

wxTrac has been migrated to GitHub Issues - wxWidgets

And here is the workaround I implemented. It basically just ignores
Freeze/Thaw on wxGTK for the parent window that has the demo notebook and
such within it. Since GTK is composting/buffering anyway this does not
cause any noticeable problems.

wxTrac has been migrated to GitHub Issues - wxWidgets

Thank you for the explanation, I'll give it a go tomorrow and
hopefully I'll be able to fix it...

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 23:21, Robin Dunn wrote:

On 11/10/11 12:38 PM, Andrea Gavana wrote:

On 10 November 2011 20:27, Robin Dunn wrote:

On 11/10/11 1:11 AM, Andrea Gavana wrote:

On 10 November 2011 02:12, Robin Dunn wrote:
On 11/9/11 1:29 PM, Andrea Gavana wrote:

What version of Ubuntu on what architecture and kernel did you use?

cat /etc/lsb-release
uname -r
and/or look it up in:
/sbin/init

Cheers,

Tobi

···

Am 10.11.11 21:38, schrieb Andrea Gavana:

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

Andrea.

Hi,

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

Andrea.

What version of Ubuntu on what architecture and kernel did you use?

cat /etc/lsb-release
uname -r
and/or look it up in:
/sbin/init

Not sure if it is relevant, but up to now I was using Natty 11.04,
with Python 2.7 and wx-2.8.12, both 64 bits. The VM doesn't really
help as it seems VMWare doesn't let me change the RAM available for
the VM :frowning: .

BTW, smart move (!) to put the "Close", "Minimize" and "Maximize"
button for a window to *the left*. It comes very natural...

@Robin: I have tried the Freeze/Thaw hack, but no luck. The GUI
freezes somewhere and I can't find where the problem is at the moment.
It seems stuck somewhere but I am not sure what I can try to find out
where it is stuck.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 11 November 2011 09:18, Tobias Weber wrote:

Am 10.11.11 21:38, schrieb Andrea Gavana:

Hi Andrea,

...

Not sure if it is relevant, but up to now I was using Natty 11.04,
with Python 2.7 and wx-2.8.12, both 64 bits. The VM doesn't really
help as it seems VMWare doesn't let me change the RAM available for
the VM :frowning: .

You might want to give Oracle VM VirtualBox 4.x a try, it gives you control over how much RAM, disk etc the VM can use. I am no expert on VM's but use it for the last few month on Ubuntu 10.04 without any issues.

Werner

···

On 11/11/2011 10:13 PM, Andrea Gavana wrote:

Hi All,

However, even though in this case wx.Window will end up in a module that
matches its location in Classic, that will not be the case for others,
and
it won't be a simple dropping of the underscore either as I'm planning on
some reorganization of the divisions between the extension modules. So
it
would be nice if there was a way to tell NDT to treat moduleA in library
1
the same as moduleB in library 2. Or maybe having a way to just compare
subsets would be good enough, such as comparing wx._windows.Panel in
library
1 and wx._core.Panel in library 2. Or finally, maybe it would work to be
able to toggle to a mode where it doesn't ignore items that are seen in
modules where they are not defined, for example wx.Window, wx.Panel, and
wx.DC will exist in both Classic and Phoenix but the actual classes will
be
defined in different "real" locations.

Yes, the last option is the easiest one, and as it is implemented
right now I believe we are already half way to get what you want:
simply uncheck the "Show 'inherited' items" in the "Options" menu and
then I'll provide another option to not to grey-out "inherited" items
in the tree. At this point, if wxPython and Phoenix both have a
"wx.Window" attribute you will be able to see the differences.
Hopefully I have understood correctly what you meant...

Yep, I think you do.

The new version I just uploaded allows much more flexibility in terms
of what gets displayed during diffs (see the "Options" menu => "Set
ignore list for diffs" item - or Ctrl+I).

There is also the new feature of being able to display inheritance
diagrams on the fly for modules with less than 20 classes defined in
them and for classes themselves (requires GraphViz and the "dot"
command to be executable by NDT).

You will need to re-scan any library you have already saved in the
database, unfortunately.

BTW, I have tried NDT on a Ubuntu VM with Python 2.7.1, wxPython
2.8.11 and, when selecting an item in the tree, the whole GUI freezes
:frowning: . Hopefully some Linux expert will step up and correct my buggy
code.

There was a similar issue discovered recently in the demo, apparently GTK
has a problem if there are new windows being created while parents are
frozen. (Which unfortunately is one of the things that you normally would
want to use Freeze for...) Here is the ticket I created for it:

wxTrac has been migrated to GitHub Issues - wxWidgets

And here is the workaround I implemented. It basically just ignores
Freeze/Thaw on wxGTK for the parent window that has the demo notebook and
such within it. Since GTK is composting/buffering anyway this does not
cause any noticeable problems.

wxTrac has been migrated to GitHub Issues - wxWidgets

I have tried this one but unfortunately it gets stuck anyway :frowning:

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 23:21, Robin Dunn wrote:

On 11/10/11 12:38 PM, Andrea Gavana wrote:

Hi Andrea,

···

On Wed, Nov 9, 2011 at 3:29 PM, Andrea Gavana andrea.gavana@gmail.com wrote:

Hi All,

I am happy to (finally) announce the birth of the Namespace Diff Tool (NDT); after soooo much effort and grief version 0.1 is available for those of you willing to try it.

Description

===========

The Namespace Diff Tool (NDT) is a graphical user interface that can

be used to discover differences between different versions of a library,

or even between different iterations/sub-versions of the same library.

The tool can be used to identify what is missing and still needs to be

implemented, or what is new in a new release, which items do not have

docstrings and so on.

Full description of the original idea by Robin Dunn:

http://svn.wxwidgets.org/viewvc/wx/wxPython/Phoenix/trunk/TODO.txt?view=markup

:warning: As most of the widgets in the GUI are owner drawn or custom,

it is highly probable that the interface itself will look messy on other

platforms (Mac, I am talking to you). Please do try and create a patch to

fix any possible issue in this sense.

:note: Please refer to the TODOs section for a list of things that still need

to be implemented.

Requirements

============

In order to run NDT, these packages need to be installed:

  • Python 2.X (where 5 <= X <= 7);
  • wxPython >= 2.8.10;
  • SQLAlchemy >= 0.6.4.

More detailed instructions on how to use it, TODO items, list of libraries/packages I tested NDT against, screenshots and download links can be found here:

http://xoomer.virgilio.it/infinity77/main/NDT.html

If you stumble upon a bug (which is highly probable), please do let me know. But most importantly, please do try and make an effort to create a patch for the bug.

Enjoy, wxPython rules.

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

import PyQt4.QtGui

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named PyQt4.QtGui

import pygtk

Traceback (most recent call last):

File “”, line 1, in

ImportError: No module named pygtk

import wx

I decided to give this a whirl, but it didn’t like my old school install. I tried it with Python 2.5, wxPython 2.8.10.1 and SqlAlchemy 0.5.0. Yeah, I know the SqlAlchemy is too old, but it died before it even got that far, so I sent you the error report.

Then I ran it using Python 2.7, wxPython 2.9.2 and SqlAlchemy 0.7.3. I ran it from my desktop which allowed the application to load successfully, but when I tried to do a scan, I got this: “c:\python27\python27.exe: can’t open file: C:\Documents’: [error 2] no such file or directory”. I don’t think it appreciated the fact that my run path has spaces in it.

By the way, if it’s okay with you, can I re-post this announcement to my blog?

Mike Driscoll

Blog: http://blog.pythonlibrary.org

Hi Mike,

Hi Andrea,

Hi All,

I am happy to (finally) announce the birth of the Namespace Diff Tool (NDT); after soooo much effort and grief version 0.1 is available for those of you willing to try it.

I decided to give this a whirl, but it didn’t like my old school install. I tried it with Python 2.5, wxPython 2.8.10.1 and SqlAlchemy 0.5.0. Yeah, I know the SqlAlchemy is too old, but it died before it even got that far, so I sent you the error report.

Then I ran it using Python 2.7, wxPython 2.9.2 and SqlAlchemy 0.7.3. I ran it from my desktop which allowed the application to load successfully, but when I tried to do a scan, I got this: “c:\python27\python27.exe: can’t open file: C:\Documents’: [error 2] no such file or directory”. I don’t think it appreciated the fact that my run path has spaces in it.

Thanks for the two bug reports (this and private e-mail one). I have fixed them in my code here and I’ll upload a new version when I get back home.

By the way, if it’s okay with you, can I re-post this announcement to my blog?

No problem, go ahead :wink: . There might be other people interested in NDT (or other libraries’ developers).

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

···

On 10 November 2011 01:44, Mike Driscoll wrote:

On Wed, Nov 9, 2011 at 3:29 PM, Andrea Gavana andrea.gavana@gmail.com wrote:

Hi Andrea,

···

On Thu, Nov 10, 2011 at 3:03 AM, Andrea Gavana andrea.gavana@gmail.com wrote:

Hi Mike,

On 10 November 2011 01:44, Mike Driscoll wrote:

Hi Andrea,

On Wed, Nov 9, 2011 at 3:29 PM, Andrea Gavana andrea.gavana@gmail.com wrote:

Hi All,

I am happy to (finally) announce the birth of the Namespace Diff Tool (NDT); after soooo much effort and grief version 0.1 is available for those of you willing to try it.

I decided to give this a whirl, but it didn’t like my old school install. I tried it with Python 2.5, wxPython 2.8.10.1 and SqlAlchemy 0.5.0. Yeah, I know the SqlAlchemy is too old, but it died before it even got that far, so I sent you the error report.

Then I ran it using Python 2.7, wxPython 2.9.2 and SqlAlchemy 0.7.3. I ran it from my desktop which allowed the application to load successfully, but when I tried to do a scan, I got this: “c:\python27\python27.exe: can’t open file: C:\Documents’: [error 2] no such file or directory”. I don’t think it appreciated the fact that my run path has spaces in it.

Thanks for the two bug reports (this and private e-mail one). I have fixed them in my code here and I’ll upload a new version when I get back home.

By the way, if it’s okay with you, can I re-post this announcement to my blog?

No problem, go ahead :wink: . There might be other people interested in NDT (or other libraries’ developers).

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://xoomer.alice.it/infinity77/

Okay, I have your announcement on my blog now. Thanks for all your hard work! I appreciate it.


Mike Driscoll

Blog: http://blog.pythonlibrary.org

Hi Mike,

···

On 10 November 2011 16:05, Mike Driscoll wrote:

Hi Andrea,

On Thu, Nov 10, 2011 at 3:03 AM, Andrea Gavana <andrea.gavana@gmail.com> > wrote:

Hi Mike,

On 10 November 2011 01:44, Mike Driscoll wrote:

Hi Andrea,

On Wed, Nov 9, 2011 at 3:29 PM, Andrea Gavana <andrea.gavana@gmail.com> >>> wrote:

Hi All,
I am happy to (finally) announce the birth of the Namespace Diff
Tool (NDT); after soooo much effort and grief version 0.1 is available for
those of you willing to try it.

I decided to give this a whirl, but it didn't like my old school install.
I tried it with Python 2.5, wxPython 2.8.10.1 and SqlAlchemy 0.5.0. Yeah, I
know the SqlAlchemy is too old, but it died before it even got that far, so
I sent you the error report.

Then I ran it using Python 2.7, wxPython 2.9.2 and SqlAlchemy 0.7.3. I
ran it from my desktop which allowed the application to load successfully,
but when I tried to do a scan, I got this: "c:\python27\python27.exe: can't
open file: C:\Documents': [error 2] no such file or directory". I don't
think it appreciated the fact that my run path has spaces in it.

Thanks for the two bug reports (this and private e-mail one). I have fixed
them in my code here and I'll upload a new version when I get back home.

By the way, if it's okay with you, can I re-post this announcement to my
blog?

No problem, go ahead :wink: . There might be other people interested in NDT
(or other libraries' developers).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Okay, I have your announcement on my blog now. Thanks for all your hard
work! I appreciate it.

Thanks, I have updated my web page with a new version of NDT
(hopefully fixing all the bugs reported up to now).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/