wxhaskell-users

[wxhaskell-users] Deleteing Controls / Derivation Viewer

[Brandon M. M. <br...@it...>]

I'm writing a program that would like to display derivation trees for
simple proofs. I'm representing derivations as a tree structure where the
nodes are labeled with the result and the rule used.

I have a function produces a tree from a derivation and a parent,
returning a panel with the conclusion, a horizonal line (of the right
width, using bestSize on the staticTest), and a row of panels containing
the subderivations. How expensive are panels? Should I avoid deeply nested
containers?

So far so good, but I would like to be able to change the proof being
displayed. I assume I could construct a new panel from the new proof,
and set the layout of my main window to a new layout that doesn't mention
the old panel, but I'm worried that this leaks widgets. Does it? Do I need
to make an explicit call to a "destroy this widget" function, or a "remove
this child" function?

On the subject of leaks, wxHaskell wasn't build with ghci libraries, or
with profiling libraries. Are there any deep reasons for this? Did I just
miss the right configure options?

This looks like a great library, I'm just clueless. Thanks for building
this.

Brandon

RE: [wxhaskell-users] Deleteing Controls / Derivation Viewer

[Daan L. <daa...@xs...>]

Hi Brandon,

> I'm writing a program that would like to display derivation 
> trees for simple proofs. I'm representing derivations as a 
> tree structure where the nodes are labeled with the result 
> and the rule used.

Thanks for trying wxHaskell!

> I have a function produces a tree from a derivation and a 
> parent, returning a panel with the conclusion, a horizonal 
> line (of the right width, using bestSize on the staticTest), 
> and a row of panels containing the subderivations. How 
> expensive are panels? Should I avoid deeply nested containers?

Hmm, in general, using layout is not very expensive and you
can surely use deeply nested containers. However, a "panel" is
not like a Java panel. A wxWindows panel is in essence only used
to manage keyboard navigation among controls in a dialog. As such,
you don't need to use a panel to manage your subtrees but you can
use layout directly. 

Regarding your application, I would say that you are probably better
off by drawing your derivation tree explicitly using an "on paint"
event handler on a scrollable window. You will see that it is not
so hard to write an algorithm that assigns locations to the nodes
of your tree. After that, it is easy to draw them nicely on the DC.

Using the same tree, that is attributed with locations, you can
install an "on rightClick" event handler that checks which node
is clicked and pop up a context menu with options for the user.

(In general you should use the "on context" handler but unfortunately
I made a little mistake in the type signature and forgot to pass the
mouse position too, so you need to work around it using "on right
click") 
 
> So far so good, but I would like to be able to change the 
> proof being displayed. I assume I could construct a new panel 
> from the new proof, and set the layout of my main window to a 
> new layout that doesn't mention the old panel, but I'm 
> worried that this leaks widgets. Does it? 

Does it leak widgets? In general, I have noticed that wxWindows seldom
leaks. However, you never know if you can't check it :-) If you work
on windows, and if you can use Visual C++ 6.0, you can build a debug
version of the wxc library that will tell you if the program leaks
or not. Let me know if you work on windows, maybe I'll put a debug
version on the web. 

Hope this helps,
 All the best,
  Daan.

> Do I need to make 
> an explicit call to a "destroy this widget" function, or a 
> "remove this child" function?


> 
> On the subject of leaks, wxHaskell wasn't build with ghci 
> libraries, or with profiling libraries. Are there any deep 
> reasons for this? Did I just miss the right configure options?
> 
> This looks like a great library, I'm just clueless. Thanks 
> for building this.
> 
> Brandon
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
> including Data Reports, E-commerce, Portals, and Forums are 
> available now. Download today and enter to win an XBOX or 
> Visual Studio .NET. 
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
_072303_01/01
_______________________________________________
wxhaskell-users mailing list wxh...@li...
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

RE: [wxhaskell-users] Deleteing Controls / Derivation Viewer

[Brandon M. M. <br...@it...>]

On Sun, 17 Aug 2003, Daan Leijen wrote:

> Hi Brandon,
>
> > I'm writing a program that would like to display derivation
> > trees for simple proofs. I'm representing derivations as a
> > tree structure where the nodes are labeled with the result
> > and the rule used.
>
> Thanks for trying wxHaskell!
>
> > I have a function produces a tree from a derivation and a
> > parent, returning a panel with the conclusion, a horizonal
> > line (of the right width, using bestSize on the staticTest),
> > and a row of panels containing the subderivations. How
> > expensive are panels? Should I avoid deeply nested containers?
>
> Hmm, in general, using layout is not very expensive and you
> can surely use deeply nested containers. However, a "panel" is
> not like a Java panel. A wxWindows panel is in essence only used
> to manage keyboard navigation among controls in a dialog. As such,
> you don't need to use a panel to manage your subtrees but you can
> use layout directly.

Okay. I knew I could use layout to build the structure, but I didn't see a
clean way of recursively building the tree. I suppose I could return just
the Layout, if I don't need the widgets. Maybe I should try a
zygomorphism.
>
> Regarding your application, I would say that you are probably better
> off by drawing your derivation tree explicitly using an "on paint"
> event handler on a scrollable window. You will see that it is not
> so hard to write an algorithm that assigns locations to the nodes
> of your tree. After that, it is easy to draw them nicely on the DC.
>
> Using the same tree, that is attributed with locations, you can
> install an "on rightClick" event handler that checks which node
> is clicked and pop up a context menu with options for the user.
>
> (In general you should use the "on context" handler but unfortunately
> I made a little mistake in the type signature and forgot to pass the
> mouse position too, so you need to work around it using "on right
> click")

This is more than I need right now. I'm working with a model of type class
constraint solving. The goal is the solver rather than the individual
derivations, so I don't need to be able to change the derivation except by
changing the goal, or changing the solver. A richer interface might be
useful on bigger problems, but it's probably not worth the effort. Well,
maybe it would be worth it for learning more about wxHaskell.

About the particular implementation you suggested, is there any reason not
to use layout inside a scrolled panel? Stacking a row of subderivations
above the conclusion works well with minimal effort. I suppose I could use
a more compact layout, but again I'm working with tiny proofs. Is there
any reason other than better control for drawing my tree manually?

> > So far so good, but I would like to be able to change the
> > proof being displayed. I assume I could construct a new panel
> > from the new proof, and set the layout of my main window to a
> > new layout that doesn't mention the old panel, but I'm
> > worried that this leaks widgets. Does it?
>
> Does it leak widgets? In general, I have noticed that wxWindows seldom
> leaks. However, you never know if you can't check it :-) If you work
> on windows, and if you can use Visual C++ 6.0, you can build a debug
> version of the wxc library that will tell you if the program leaks
> or not. Let me know if you work on windows, maybe I'll put a debug
> version on the web.

I've tested a program that repeatedly opens a window and calls close on
it. It chews through memory as it runs. A program that repeatedly adds a
widget to a frame, sets a layout with it, and sets the empty layout also
chews through memory. I'm just watching the free system memory tend
downwards so I can't suggest anything about where the memory goes.

I'm working on Linux. I guess there's no configure option to build
profiling libraries? I'll try to build them myself then.

I am mostly worried that ommiting a widget from a layout and losing all
my references isn't enough to free it. Maybe the parent tracks all it's
children and I needed to call some magic method to break the reference.
Maybe widgets don't have finalizers in this 0.1 release, etc. What should
I be doing to avoid collecting lots of memory like this?

Thanks
Brandon

> Hope this helps,
>  All the best,
>   Daan.
>
> > Do I need to make
> > an explicit call to a "destroy this widget" function, or a
> > "remove this child" function?
>
>
> >
> > On the subject of leaks, wxHaskell wasn't build with ghci
> > libraries, or with profiling libraries. Are there any deep
> > reasons for this? Did I just miss the right configure options?
> >
> > This looks like a great library, I'm just clueless. Thanks
> > for building this.
> >
> > Brandon
> >
>
>

RE: [wxhaskell-users] Deleteing Controls / Derivation Viewer

[Daan L. <daa...@xs...>]

Hi Brandon,

> About the particular implementation you suggested, is there 
> any reason not to use layout inside a scrolled panel? Stacking a row
of 
> subderivations above the conclusion works well with minimal effort. I 
> suppose I could use a more compact layout, but again I'm working with
tiny 
> proofs. Is there any reason other than better control for drawing my
tree manually?

No :-) I only suggest it since it gives more control, the layout
combinators are just not very good with dynamically changing
things but if they work for you, they are ok.

> I've tested a program that repeatedly opens a window and 
> calls close on it. It chews through memory as it runs. A program that 
> repeatedly adds a widget to a frame, sets a layout with it, and sets
the empty 
> layout also chews through memory. I'm just watching the free system
memory tend
> downwards so I can't suggest anything about where the memory goes.

There is no way to tell whether wxWindows uses that memory, or if
Haskell hangs on to certain things. Even that may not be the case as
GHC tends to allocate first for a while before starting to do major
collections. You just can't conclude the right things from this
experiment.

> I'm working on Linux. I guess there's no configure option to build
> profiling libraries? I'll try to build them myself then.

On windows, I use the built-in memory manager of visual C++ to check
for leaks on the wxWindows side. wxWindows also has itself a system to
check for leaks that mainly works for Unix (and would be perfect for
you).
If you can find out how it works, you can configure wxWindows to build
with the checks enabled. Than, you need to adapt "main.cpp" in the
"wxc"
project to do the check after wxEntry. You can look at the windows entry

point for an example.

(If you succeed, I am highly interested to include your changes btw :-)

 
> I am mostly worried that ommiting a widget from a layout and 
> losing all my references isn't enough to free it. Maybe the parent 
> tracks all it's  children and I needed to call some magic method to
break the 
> reference. Maybe widgets don't have finalizers in this 0.1 release,
etc. 
> What should I be doing to avoid collecting lots of memory like this?

In general, a widget frees all it children itself. If you change the
layout
with new widgets, and leaving out older widgets, the parent will hold on
to the 
(no longer visible) children. It is unsafe to delete them yourself as
the 
parent can still refer to them. I guess that there is some method in
wxWindows 
to dynamically detach controls from a window?? Look in the wxWindows
docs for 
some hints. (hmm, yet another reason to use a DC :-)

Normally, you never need to worry about freeing widgets. Just resources
like fonts
and bitmaps need to be managed sometimes.

Hope this helps,
 Daan.

> 
> Thanks
> Brandon
> 
> > Hope this helps,
> >  All the best,
> >   Daan.
> >
> > > Do I need to make
> > > an explicit call to a "destroy this widget" function, or a
> > > "remove this child" function?
> >
> >
> > >
> > > On the subject of leaks, wxHaskell wasn't build with ghci
> > > libraries, or with profiling libraries. Are there any deep
> > > reasons for this? Did I just miss the right configure options?
> > >
> > > This looks like a great library, I'm just clueless. Thanks
> > > for building this.
> > >
> > > Brandon
> > >
> >
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
> _072303_01/01
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
>