"PyCrust Filling" crashes on recursive ingredients

wxPython Users
1

My app immediately crashes when I click the "[+]" next to one of my own
variables in the PyCrust "filling" tree view: "Illegal instruction"

That's for wxPython 2407 which I just built tonight. In 2402 I used to
get a "Segmentation fault" instead. With either version, the behavior
is fairly consistent.

Note that I can see the variable under "Ingredients". And I can click on
it. I just can't expand it.

My PyCrust set up is:

    def makePythonPanel(self, parent):
        from wxPython.lib.PyCrust import shell, version, filling
        splitter = wx.SplitterWindow(parent, -1, size=(640, 480))
        shellWin = shell.Shell(splitter, -1, introText="Welcome to \
          PyCrust %s" % version.VERSION)
        namespace = shellWin.interp.locals
        assert isinstance(namespace, dict)
        namespace['appFrame'] = self # <------ troublemaker
        browserWin = filling.Filling(splitter, -1, size=(640, 480),
          rootObject=namespace, rootIsNamespace=1)
        splitter.splitHorizontally(shellWin, browserWin)
        return splitter

If I comment out the "namespace['appFrame'] = self", the problem goes
away, but so does my ability to inspect what's interesting. The "self"
is a subclass of (wx.Frame, wxColumnSorterMixin).

** LIGHT BULB ***

Is this an infinite recursion problem from adding "self" to a PyCrust
Filling window that is ultimately contained by self?

It appears so. If I just make up a class with some attributes everything
works.

So I guess this needs to be fixed somehow. But also, is there a way I
can get this to work now? I just want to put PyCrust in a page in the
notebook that my application already had. Is no one doing this?

···

--
Chuck
http://ChuckEsterbrook.com

2

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:

My app immediately crashes when I click the "[+]" next to one of my own
variables in the PyCrust "filling" tree view: "Illegal instruction"

That's for wxPython 2407 which I just built tonight. In 2402 I used to
get a "Segmentation fault" instead. With either version, the behavior
is fairly consistent.

Note that I can see the variable under "Ingredients". And I can click on
it. I just can't expand it.

My PyCrust set up is:

    def makePythonPanel(self, parent):
        from wxPython.lib.PyCrust import shell, version, filling
        splitter = wx.SplitterWindow(parent, -1, size=(640, 480))
        shellWin = shell.Shell(splitter, -1, introText="Welcome to \
          PyCrust %s" % version.VERSION)
        namespace = shellWin.interp.locals
        assert isinstance(namespace, dict)
        namespace['appFrame'] = self # <------ troublemaker
        browserWin = filling.Filling(splitter, -1, size=(640, 480),
          rootObject=namespace, rootIsNamespace=1)
        splitter.splitHorizontally(shellWin, browserWin)
        return splitter

If I comment out the "namespace['appFrame'] = self", the problem goes
away, but so does my ability to inspect what's interesting. The "self"
is a subclass of (wx.Frame, wxColumnSorterMixin).

Just looking at your code I don't see anything wrong.

** LIGHT BULB ***

Is this an infinite recursion problem from adding "self" to a PyCrust
Filling window that is ultimately contained by self?

No, that shouldn't be a problem.

It appears so. If I just make up a class with some attributes everything
works.

Your code should work too, from what I can see.

So I guess this needs to be fixed somehow. But also, is there a way I
can get this to work now? I just want to put PyCrust in a page in the
notebook that my application already had. Is no one doing this?

I'd like to help get this fixed. Can you create a simplified, but
complete, example app with the problem so I can take a look at it?

Feel free to email the files to me directly - pobrien@orbtech.com.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

3

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:

My app immediately crashes when I click the "[+]" next to one of my own
variables in the PyCrust "filling" tree view: "Illegal instruction"

It turns out Chuck was the victim of his own renaming utility, which
changes the UpperCamelCase method names to lowerCamelCase names.
Unfortunately, PyFilling had two method names that were already
lowerCamelCase and they were getting blown away by matching
UpperCamelCase names in the same class. I changed the troublesome
names to avoid the problem, but I suspect this won't be the first time
someone gets burned playing with this particular book of matches. :wink:

P.S. I make no guarantees about the other PyCrust modules. There is a
very good chance they have matching lowerCamel/UpperCamel method names
as well, and I may not be as inclined to rename them. Just FYI.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

4

Interestingly, I see code in FixNames that refrains from setting the
lowercase name if it already exists. So I need to do some more
whittling down to really figure this one out.

My FixNames module works with the wxPython demo (sans PyCrust I suppose)
as well code that's been posted to this list. This is the first and
only problem I have had.

···

On Monday 31 March 2003 04:17 pm, Patrick K. O'Brien wrote:

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:
> My app immediately crashes when I click the "[+]" next to one of my
> own variables in the PyCrust "filling" tree view: "Illegal
> instruction"

It turns out Chuck was the victim of his own renaming utility, which
changes the UpperCamelCase method names to lowerCamelCase names.
Unfortunately, PyFilling had two method names that were already
lowerCamelCase and they were getting blown away by matching
UpperCamelCase names in the same class. I changed the troublesome
names to avoid the problem, but I suspect this won't be the first
time someone gets burned playing with this particular book of
matches. :wink:

P.S. I make no guarantees about the other PyCrust modules. There is
a very good chance they have matching lowerCamel/UpperCamel method
names as well, and I may not be as inclined to rename them. Just
FYI.

--
Chuck
http://ChuckEsterbrook.com

5

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:

Interestingly, I see code in FixNames that refrains from setting the
lowercase name if it already exists. So I need to do some more
whittling down to really figure this one out.

My FixNames module works with the wxPython demo (sans PyCrust I suppose)
as well code that's been posted to this list. This is the first and
only problem I have had.

Trouble is my middle name... :wink:

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------