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
> 
>