wxHaskell

Mike Gunter wrote:
> For me, running examples/contrib/GLCanvas.hs yields an entirely white
> rectangle window.  Is this the intended behavior?  

It does not seem the right behaviour to me when looking at the code.
However, I do not have openGL running on my computer (couldn't get
HOpenGL compiled on my XP box), so I can not test anything. Maybe
you should contact shelarcy or Sean Seefried directly? (they
contributed the original openGL samples).

I hope this helps,
All the best,
  Daan Leijen.

 > If so, does anyone
> have a more interesting piece of code using HOpenGL from wxHaskell?
> (Actually, I'd be interested in such code in any case.)  If not, do
> others get different behavior using the provided code?
> 
> All the other wxHaskell examples produce for me what seems to be the
> intended behavior as does the HOpenGL Cube example.  I'm running
> Debian (mostly) sarge on an i386 box with unstable/alioth GHC,
> wxHaskell, HOpenGL.
> 
> Advice?
> 
> 	thanks,
> 	mike
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> wxhaskell-users mailing list
> wxhaskell-users@...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
>

Keith Wansbrough wrote:
 > AFAICS, a straightforward solution is for the configure script to
 > determine the absolute paths of both ghc and ghc-pkg, and for the rest
 > of the build system to use those absolute paths, rather than relying
 > on the executable search path to find them.  This still breaks if
 > "ghc-pkg" does not correspond to "ghc" even with the same path; but
 > this is a much less likely scenario (and the --hc=foo, --hcpkg=foo,
 > switches are still there to address it).
 >

Hi Keith,

Thanks for the detailed bug report -- I'll try to fix this in the
configure script (and maybe I'll even ask you to try it out before
releasing wxHaskell 0.9 :-)

 > Thanks for a great piece of software; I'm enjoying using it!

Ha, that is good to hear after all the countless hours of
wxWidgets debugging ;-)

  -- Daan.

> Hi... recently I attempted to install wxHaskell on a system with
> multiple versions of GHC installed.  I did
> 
> ./configure --prefix=/usr/local/foo --with-opengl
> make
> su
> make install
> 
> The "make" phase used the default "ghc" in my path.
> 
> The "make install" phase used the default "ghc-pkg" in my path.
> 
> However, my paths as ordinary user and as root are _different_, and so
> these were different: /usr/local/bin/ghc ->
> /usr/local/bin/ghc-6.3.20041124 versus /usr/bin/ghc-pkg ->
> /usr/bin/ghc-pkg-6.2.2.
> 
> This had the obvious consequence of registering a wxHaskell built for 
> one ghc, ghc-6.3.20041124, with the wrong ghc, ghc-6.2.2.
> 
> AFAICS, a straightforward solution is for the configure script to
> determine the absolute paths of both ghc and ghc-pkg, and for the rest
> of the build system to use those absolute paths, rather than relying
> on the executable search path to find them.  This still breaks if
> "ghc-pkg" does not correspond to "ghc" even with the same path; but
> this is a much less likely scenario (and the --hc=foo, --hcpkg=foo,
> switches are still there to address it).
> 
> Thanks for a great piece of software; I'm enjoying using it!
> 
> --KW 8-)
>

herington, dean wrote:
> I'm using wxhaskell-0.8 on Windows XP.  When starting it up, I get a 
> error dialog with:
>  
> Ghc Error
> Can't load bitmap 'wxBITMAP_STD_COLOURS' from resources! Check .rc file.
>  
> What's it mean?  What is the .rc file?  (I thought that was an X thing.)

It is a windows resource file that is normally compiled into your .exe.
Do you use a debug version of wxHaskell? In principle, you should not
get this message with a release version (even though it is harmless, 
right?).

I think you get when using certain message dialogs right? I believe
it is fixed in wxWidgets 2.5.x but I will look into it and see if
it can be fixed manually by me for the next release of wxHaskell.
(is it a critical thing for you?)

All the best,
  Daan.

Sebastian Sylvan wrote:
> Is there any way to force the program to process pending events?
> 
> The specific situation is this. I add a bunch of stuff to a listbox
> and after each addition I would like the listbox to update itself so
> that the change is visible immidiatly. As it is now the changes are
> only visible after I've added ALL the items to the listbox.

I think you can say "repaint w" to your widget "w" that needs to be
updated.

-- Daan

Lennart Kolmodin wrote:
> Hi all!
> I'm doing an animation with lines, it's part of my lab:
> http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/lab1.html
> 
> I have set a "on paint" property on a panel to draw all lines on every
> repaint. This solution is not good since I update the lines every 50ms, it
> gets terrible slow.
> Somehow I would like to save the animation frame I have got so far and
> just add some lines on every tick.

Hi Lennart,

I think you can just use "on paintRaw". This event also gets a list
of "dirty" rectangles as its argument so you are able to redraw parts
that were clobbered by other windows. Do not use both "paint" and
"paintRaw" btw.

The other solution you are talking about -- drawing into a bitmap
is also possible but rather involved as you need to use low-level
wxWidgets calls. However, I am doing these things myself to provide
double-buffering by default and you can see the code in the 
"WXCore.Draw" module in the "dcBuffer" family of calls. I think that
I should probably provide a nice abstraction to draw into bitmaps --
I plan to do release 0.9 fairly soon now (beginning of december) and
I'll see if I can add a wrapper like that (or include your version ;-)

I hope this helps,
-- Daan.

> I noticed there is a drawBitmap function but I have not found a way to
> draw lines on a Bitmap. I have also found the Image type but it's the same
> problem there.
> 
> Any ideas?
> 
> Thank you for yor help,
> Lennart Kolmodin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. http://www.intersystems.com/match8
> _______________________________________________
> wxhaskell-users mailing list
> wxhaskell-users@...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> 
>

99b1360@... wrote:

>Hi.
> 
>I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>recent days, so I tested Anti-Alias function to know how much faster.
> 
>http://sourceforge.net/mailarchive/message.php?msg_id=9127088
> 
>I'm not satisfied this performance. This function is too slowly yet.
>I think that bottleneck is read/write Array.
> 
>http://d.hatena.ne.jp/tanakh/20040809#p1
> 
>How about use IOUArray or IOArray?
>  
>
I am currently not in the position to tweak much about this code (as
other things
have priority now, like drag&drop and printing). However, if you feel
that you can
make it faster by using IOUArray or something, please try to do so. If
you can
package it up nicely, I will most certainly add your patches to wxHaskell.

Thanks
-- Daan.

> 
> 
>--
>shelarcy <shelarcy capella.freemail.ne.jp>
>http://page.freett.com/shelarcy/
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>wxhaskell-users mailing list
>wxhaskell-users@...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

I sent e-mail Daan directly, so this is summary.
Result : IOUArray doesn't make faster this program.
Program using Array is much faster.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/haskell/haskell-jp/493


On Tue, 09 Nov 2004 15:37:00 +0100, Daan Leijen <daan@...> wrote:
>> I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>> recent days, so I tested Anti-Alias function to know how much faster.
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=9127088
>>
>> I'm not satisfied this performance. This function is too slowly yet.
>> I think that bottleneck is read/write Array.
>>
>> http://d.hatena.ne.jp/tanakh/20040809#p1
>>
>> How about use IOUArray or IOArray?
>>
>>
> I am currently not in the position to tweak much about this code (as
> other things
> have priority now, like drag&drop and printing). However, if you feel
> that you can
> make it faster by using IOUArray or something, please try to do so. If
> you can
> package it up nicely, I will most certainly add your patches to  
> wxHaskell.

-- 
shelarcy <shelarcy capella.freemail.ne.jp>
http://page.freett.com/shelarcy/

shelarcy wrote:
> I sent e-mail Daan directly, so this is summary.
> Result : IOUArray doesn't make faster this program.
> Program using Array is much faster.

Hmm, that is a shame. I do not see an obvious way to
make this faster in Haskell -- except for making Haskell
strict :-)

All the best,
And thanks for the experiment,
-- Daan.

> 
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/haskell/haskell-jp/493
> 
> 
> On Tue, 09 Nov 2004 15:37:00 +0100, Daan Leijen <daan@...> wrote:
> 
>>> I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>>> recent days, so I tested Anti-Alias function to know how much faster.
>>>
>>> http://sourceforge.net/mailarchive/message.php?msg_id=9127088
>>>
>>> I'm not satisfied this performance. This function is too slowly yet.
>>> I think that bottleneck is read/write Array.
>>>
>>> http://d.hatena.ne.jp/tanakh/20040809#p1
>>>
>>> How about use IOUArray or IOArray?
>>>
>>>
>> I am currently not in the position to tweak much about this code (as
>> other things
>> have priority now, like drag&drop and printing). However, if you feel
>> that you can
>> make it faster by using IOUArray or something, please try to do so. If
>> you can
>> package it up nicely, I will most certainly add your patches to  
>> wxHaskell.
> 
>

Daniel Fischer wrote:

>Hello Daan,
>
>I haven't heard from you. So have you made any progress or could you
>reproduce the problem? Thanks again for you help.
>  
>
Sorry Daniel,

I haven't looked into this yet as I have been so busy lately. I'll try 
to look into
it later this week -- but don't get your hopes up too much: to me, it seems
like a wxWidgets problem.

-- Daan

>Daniel
>
>  
>
>> Daniel Fischer wrote:
>> 
>>    
>>
> >>Hello!
> >>
> >>I have a strange problem when using splitter windows with a spin
> >>control inside. I reduced my problem to the sample code below. When I
> >>running it on Windows I"m unable to resize the top left area by moving
> >>the vertical splitter bar left or right. But the horizontal splitter
> >>bar works fine. It seems to be a problem with the spin control. When
> >>replacing the spin control by a simple text entry (changing the line
> >>"spin <- spinCtrl panelLeft 0 100 []" to "spin <- textEntry panelLeft []")
> >>both splitter bars work fine. Strangly this problem does not occur
> >>when running it on Linux.
> >>
> >>Is it my fault or is there a bug in wxHaskell or in wxWidgets?
> >>I"m using Windows XP prof SP2, ghc 6.2.1 and wxHaskell 0.8.
> >>  
> >>
>  
>
>> It seems a wxWidgets problem. I will try this out on monday on my 
>> windowsXP system.
>> (it also seems that spin controls don"t propagate their events 
>> correctly, so it might be
>> related to that bug)
>> 
>> -- Daan.
>> 
>>    
>>
> >>And just another related question: how can I make the splitter windows
> >>respect the minimum size needed for the controls in the splitter
> >>panes?
> >>
> >>Many thanks in advance for your help
> >>Daniel Fischer
> >>
> >>---8<---------- sample code ----------8<---
> >>
> >>module Main where
> >>
> >>import Graphics.UI.WX
> >>import Graphics.UI.WXCore
> >>
> >>main :: IO ()
> >>main
> >>  = start gui
> >>
> >>gui :: IO ()
> >>gui
> >>  = do  f <- frame [ text := "error?" ]
> >>  
> >>        hSplit <- splitterWindow f [ style := wxSP_3DSASH ]
> >>        vSplit <- splitterWindow hSplit [ style := wxSP_3DSASH ]
> >>        panelLeft <- panel vSplit []
> >>        
> >>        spin <- spinCtrl panelLeft 0 100 []
> >>        entry <- textEntry panelLeft []
> >>        btn1 <- button panelLeft [ text := "Ok" ]
> >>        btn2 <- button panelLeft [ text := "Ok" ]
> >>        list1 <- listCtrl panelLeft [ columns := [("foo",AlignLeft,100)] ]
> >>        list2 <- listCtrl vSplit [ columns := [("bar",AlignLeft,100)] ]
> >>        list3 <- listCtrl hSplit [ columns := [("baz",AlignLeft,100)] ]
> >>        
> >>        subLayoutLeft <- return $ vfill $ column 5
> >>          [ boxed "box 1" $ row 5 [ fill $ widget spin, widget btn1 ]
> >>          , boxed "box 2" $ row 5 [ fill $ widget entry, widget btn2 ]
> >>          ]
> >>
> >>        layoutLeft <- return $ fill $ row 5 [ fill $ widget list1, subLayoutLeft ]
> >>        set panelLeft [ layout := layoutLeft ]
> >>        
> >>        layoutTop <- return $ vsplit vSplit 5 300 (widget panelLeft) (widget list2)
> >>        layoutAll <- return $ hsplit hSplit 5 300 layoutTop (widget list3)
> >>        
> >>        set f [ layout := minsize (sz 640 400) $ fill layoutAll ]
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >>Use IT products in your business? Tell us what you think of them. Give us
> >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >>http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>_______________________________________________
> >>wxhaskell-users mailing list
> >>wxhaskell-users@......
> >>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> >>
> >>
> >>  
> >>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>wxhaskell-users mailing list
>wxhaskell-users@...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

Hello List,

I just tried the Process example on my debian gnu linux (testing) laptop 
(intel centrino).  Linux kernel version 2.6.7.  

wxgtk-2.4-config --version reports 2.4.2  (debian package)
ghc --version reports 6.2.1

I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
faults most of the time:

  - when trying to use a not existing command (cmd for example)
  - bash works and after bash is started all cmds executed inside bash
    do not cause sigsevs as well
  - ls (without bash) causes sigsev 
  - cat (without bash) works
  - cat Process.hs (without bash) causes sigsev
  - cat fooo (without bash fooo being a non existant file) causes sigsev

What's going on?  On a side note how is one supposed to use the 
inputStreamRead* collection of functions (see Graphics.UI.WXCore.Process)
there does not seem to be a function to get an InputStream given a Process.


Cheers and Thanks for your help,


Bene


-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

Benedikt Grundmann wrote:

>Hello List,
>
>I just tried the Process example on my debian gnu linux (testing) laptop 
>(intel centrino).  Linux kernel version 2.6.7.  
>
>wxgtk-2.4-config --version reports 2.4.2  (debian package)
>ghc --version reports 6.2.1
>
>I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
>faults most of the time:
>  
>
Hi Benedikt,

The asynchronous process seemed to work well on windows, but since we 
use it intensively
with Helium, we noticed that it sometimes crashes too :-(  We still try 
to debug this but it is
a hard one to solve due to the asynchronous nature. We have not tested 
it on debian, but maybe
we should as it seems to occur at least at well-defined moments! 

Bottom line: the process feature has bugs.. and it won't get solved soon 
as I am currently working
on other features (like printing). However, I would like to see it 
debugged as it is a tremendously
useful feature and because we need to run Helium.

>What's going on?  On a side note how is one supposed to use the 
>inputStreamRead* collection of functions (see Graphics.UI.WXCore.Process)
>there does not seem to be a function to get an InputStream given a Process.
>  
>
These are just convenience functions on streams. There are used 
internally to provide the "OnReceive"
functions for processes and you can't use them directly on processes.

I hope this helps,
-- Daan.

>
>Cheers and Thanks for your help,
>
>
>Bene
>
>
>  
>

Hi Daan,

On Wednesday 10 November 2004 16:00, you wrote:
DL> Benedikt Grundmann wrote:
DL> 
DL> >Hello List,
DL> >
DL> >I just tried the Process example on my debian gnu linux (testing) laptop 
DL> >(intel centrino).  Linux kernel version 2.6.7.  
DL> >
DL> >wxgtk-2.4-config --version reports 2.4.2  (debian package)
DL> >ghc --version reports 6.2.1
DL> >
DL> >I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
DL> >faults most of the time:
DL> >  
DL> >
DL> Hi Benedikt,
DL> 
DL> The asynchronous process seemed to work well on windows, but since we 
DL> use it intensively
DL> with Helium, we noticed that it sometimes crashes too :-(  We still try 
DL> to debug this but it is
DL> a hard one to solve due to the asynchronous nature. We have not tested 
DL> it on debian, but maybe
DL> we should as it seems to occur at least at well-defined moments! 
DL> 

I did some more testing today:  I could reproduce the same behaviour on my
desktop machine (a 2.6 ghz pentium 4) running Debian GNU Linux 
(unstable bleeding edge).  On both machines I could "sometimes" see it actually
work roughly once every 20 tries.  

DL> Bottom line: the process feature has bugs.. and it won't get solved soon 
DL> as I am currently working
DL> on other features (like printing). However, I would like to see it 
DL> debugged as it is a tremendously
DL> useful feature and because we need to run Helium.
DL> 

Well it's a *critical* part of an application I'm currently writing together
with a colleque (part of my bachelor thesis in computer science).  Implementation
is still in it's infancy so I could switch to another programming language
even though I *really* want to use haskell :-).  Do you know wether it is a
wxhaskell or a wxWidgets or wxGTK Problem?  I'm willing to give it some more
work / testing but not much as my time constraints to not permit that.


Thanks again for your work,

Cheers,

Bene

-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

Benedikt Grundmann wrote:

>Well it's a *critical* part of an application I'm currently writing together
>with a colleque (part of my bachelor thesis in computer science).  Implementation
>is still in it's infancy so I could switch to another programming language
>even though I *really* want to use haskell :-).  Do you know wether it is a
>wxhaskell or a wxWidgets or wxGTK Problem?  I'm willing to give it some more
>work / testing but not much as my time constraints to not permit that.
>  
>
Ok, first of all try to compile wxHaskell with an experimental 
wxWidgets, like 2.5.2  (I haven't tried 2.5.3 yet).
Secondly, if you have a nice debugger, you could look into the wxHaskell 
process code. I have just
done so, and couldn't find any glaring errors, but maybe you'll find the 
problem with the right mix of
trace statements :-)

How does it work: first, I create a Process object that runs 
asynchronously and redirects input/output.
(See WXCore/Process.hs) The process objects sends events to a parent 
which catches them. The
"OnInput" events are the important ones. To implement non-blocking IO, 
those event handlers
(See WXCore/Events.hs) create "InputSink" objects to deal with that. The 
"inputSink" objects are
implemented by me in C code  (See wxc/src/extra.cpp,  a bit of a mess 
here, but you'll find the relevant section :-)
The InputSink class derives from the wxThread class and starts a 
seperate thread that reads from the
input stream. While the thread is not destroyed, it reads from the 
stream. When something is read, it
creates a "InputEvent" that contains the data and "posts" it to the main 
GUI loop where it can be processed
by the main GUI/Haskell event thread. How does the event know which 
object should get the event? well,
it has a special "id" that identifies it. However, now that I think 
about it, I take the input stream pointer as the
value which seems kind of wrong -- maybe it should be the "id" of the 
parent object for the process, or even
the id from the process object -- try to play with that a bit.

Well, I hope this helps a bit with debugging -- I couldn't reproduce 
your problems (yet), but I'll try later
this week.

-- Daan.

>Thanks again for your work,
>
>Cheers,
>
>Bene
>
>  
>

Hello Daan, Hello List,

I have some free time this weekend which I want to use to track down
this sigsev bug.  Interestingly the bug does not appear that often 
when running the Process.hs in a debugger.  But most of the time it
does crash when I try to execute the unknown cmd `cmd' to times in a
row.  I compiled process using ghc -debug -package wx --make Process.hs
gdb says:

Starting program: /home/dreamer/programming/wxhaskell/wxhaskell-0.8/samples/wx/a.out 
[Thread debugging using libthread_db enabled]
[New Thread 1090297408 (LWP 1826)]
Detaching after fork from child process 1829.
[New Thread 1100573616 (LWP 1830)]
[New Thread 1108962224 (LWP 1831)]
[Thread 1108962224 (zombie) exited]
[Thread 1100573616 (zombie) exited]
Detaching after fork from child process 1832.
[New Thread 1100573616 (LWP 1833)]
[New Thread 1108962224 (LWP 1834)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1108962224 (LWP 1834)]
0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
(gdb) bt
#0  0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#1  0x402219c9 in wxInputSink::Entry () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#2  0x403fc446 in wxThreadInternal::PthreadStart ()
   from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#3  0x405cb9b4 in start_thread () from /lib/tls/libpthread.so.0
#4  0x00000000 in ?? ()
(gdb) 


I don't know wether that is already helpfull to you or not.  How do I compile
wxhaskell with full debugging information?  I noticed that there is something
like wxcd in makefile.lib but there does not seem to be an accompanying 
parameter in the configure script.


Cheers,

Bene


PS:

I originally intented not to write this email to the wxhaskell mailing list, as
I wasn't sure wether this email was interesting to it.  And I had it only cc'ed to 
Daniel Fischer (who happened to post another one of our problems yesterday evening 
and is that colleque of mine I mentioned before).  But I just had to realize that
your spam filter blocked my email.  


-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

Hi Benedikt,

Thanks for your report, I'll have to read it more carefully tosee
if it helps or not, but it is good to know where it goes wrong.
Maybe I'll find it now.

Anyway, you can easily compile with debugging information
by editing the makefile. On line 637 you just add the gcc debug flags to
the given flags in WXC-CXXFLAGS.

Maybe you have to add some HCFLAGS too?   (write HCFLAGS += ...
somewhere after the include's in the makefile.

The "wxcd" thing is just when you are using MS visual studio.

-- Daan.

ps. Let's take this discussion offline, I reconfigured my spam filter
so I guess you can safely send me mail now :-)

Benedikt Grundmann wrote:

>Hello Daan, Hello List,
>
>I have some free time this weekend which I want to use to track down
>this sigsev bug.  Interestingly the bug does not appear that often 
>when running the Process.hs in a debugger.  But most of the time it
>does crash when I try to execute the unknown cmd `cmd' to times in a
>row.  I compiled process using ghc -debug -package wx --make Process.hs
>gdb says:
>
>Starting program: /home/dreamer/programming/wxhaskell/wxhaskell-0.8/samples/wx/a.out 
>[Thread debugging using libthread_db enabled]
>[New Thread 1090297408 (LWP 1826)]
>Detaching after fork from child process 1829.
>[New Thread 1100573616 (LWP 1830)]
>[New Thread 1108962224 (LWP 1831)]
>[Thread 1108962224 (zombie) exited]
>[Thread 1100573616 (zombie) exited]
>Detaching after fork from child process 1832.
>[New Thread 1100573616 (LWP 1833)]
>[New Thread 1108962224 (LWP 1834)]
>
>Program received signal SIGSEGV, Segmentation fault.
>[Switching to Thread 1108962224 (LWP 1834)]
>0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>(gdb) bt
>#0  0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#1  0x402219c9 in wxInputSink::Entry () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#2  0x403fc446 in wxThreadInternal::PthreadStart ()
>   from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#3  0x405cb9b4 in start_thread () from /lib/tls/libpthread.so.0
>#4  0x00000000 in ?? ()
>(gdb) 
>
>
>I don't know wether that is already helpfull to you or not.  How do I compile
>wxhaskell with full debugging information?  I noticed that there is something
>like wxcd in makefile.lib but there does not seem to be an accompanying 
>parameter in the configure script.
>
>
>Cheers,
>
>Bene
>
>
>PS:
>
>I originally intented not to write this email to the wxhaskell mailing list, as
>I wasn't sure wether this email was interesting to it.  And I had it only cc'ed to 
>Daniel Fischer (who happened to post another one of our problems yesterday evening 
>and is that colleque of mine I mentioned before).  But I just had to realize that
>your spam filter blocked my email.  
>
>
>  
>