wxhaskell-users

[wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

I submitted this bug report at the sourceforge project.  Is this a known
problem?  Any work-arounds?

Running two 'start'ed actions kills the process under ghc and ghci. Example:
>
> import Graphics.UI.WX
> main = io >> io where io = start (frame [] >> return ())
>
> OS: Windows XP
> Software versions:
> ghc: 6.6
> wxWidgets: 2.6.3
> wxHaskell: 0.10.1
>

Thanks,  - Conal

Re: [wxhaskell-users] process crashes on second 'start'

[Jeremy O'D. <jer...@gm...>]

Hi Conal,

On 07/12/06, Conal Elliott <co...@co...> wrote:
> I submitted this bug report at the sourceforge project.  Is this a known
> problem?  Any work-arounds?
>
> > Running two 'start'ed actions kills the process under ghc and ghci.
> Example:
> >
> > import Graphics.UI.WX
> > main = io >> io where io = start (frame [] >> return ())

I'm not sure whether anyone has tried this before, but I would fully
expect it not to work for several reasons:

* I'm pretty sure that wxHaskell only expects to see a single instance
of a wxWidgets wxApp (which is what start boils down to creating,
among other things).

* In fact, I think the whole point about wxApp is that it encapsulates
a process with an event loop for handling GUI events, so the
limitation is probably with wxWidgets itself (as it happens, I'm
sceptical that what you are trying would work on any common GUI
framework, for much the same reason)

Work-around will depend on what you are trying to do.

You can certainly have multiple top level frames, but they will share
the same event loop. This is, by some margin, the easiest approach.

If you genuinely want two communicating processes, you most likely
need to create two separate executables - let's call them A and B. As
part of start-up of A, it spawns B as a forked process, and A abd B
communicate via pipes, IP sockets or some other appropriate mechanism.

Another wrinkle to watch out for (again, common to most GUIs) is that
only one thread should perform all event handling (in practice, this
usually ends up being simplest by running all GUI activities in a
single thread). Windows is expecially strict about this - X is
slightly more permissive, but you are much better off following the
'one GUI thread' rule.

Assuming that you have a multi-threaded application, typical design is
for GUI to signal other 'worker' threads (which signal back). Again,
details are likely to be very application dependent.

One  final, somewhat unrelated issue: if you are planning to use
wxWidgets with GHCi, it is worth knowing that you can actually only
issue one start command in a given GHCi session. This is an underlying
wxWidgets issue (use of static destructors in C++ code, I believe)
which means that wxWidgets can only be restarted by unloading and
reloading the wxWidgets DLL. Since GHCi isn't capable of doing this,
you basically need to quit and restart a new session.

There *is* a workaround for this: use wxWidgets 2.4.2 or earlier,
which have a different allocation/deallocation strategy. This is why
we continue to support wxWidgets 2.4.2.

Regards
Jeremy

Re: [wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

Hi Jeremy,

Thanks for the detailed pointers about wxWidgets, GUIs, and
multi-threading.  My use is actually very simple.  The only reason I wanted
multiple (sequential, not concurrent) invocations of 'start' is for
convenience of use in ghci.

I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that this
problem was worked around in 2.4.2 for use with ghci.  Is there really no
way to fix the situation with 2.6.3?

Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
including unicode issues?

Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?

  - Conal


On 12/7/06, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> Hi Conal,
>
> On 07/12/06, Conal Elliott <co...@co...> wrote:
> > I submitted this bug report at the sourceforge project.  Is this a known
> > problem?  Any work-arounds?
> >
> > > Running two 'start'ed actions kills the process under ghc and ghci.
> > Example:
> > >
> > > import Graphics.UI.WX
> > > main = io >> io where io = start (frame [] >> return ())
>
> I'm not sure whether anyone has tried this before, but I would fully
> expect it not to work for several reasons:
>
> * I'm pretty sure that wxHaskell only expects to see a single instance
> of a wxWidgets wxApp (which is what start boils down to creating,
> among other things).
>
> * In fact, I think the whole point about wxApp is that it encapsulates
> a process with an event loop for handling GUI events, so the
> limitation is probably with wxWidgets itself (as it happens, I'm
> sceptical that what you are trying would work on any common GUI
> framework, for much the same reason)
>
> Work-around will depend on what you are trying to do.
>
> You can certainly have multiple top level frames, but they will share
> the same event loop. This is, by some margin, the easiest approach.
>
> If you genuinely want two communicating processes, you most likely
> need to create two separate executables - let's call them A and B. As
> part of start-up of A, it spawns B as a forked process, and A abd B
> communicate via pipes, IP sockets or some other appropriate mechanism.
>
> Another wrinkle to watch out for (again, common to most GUIs) is that
> only one thread should perform all event handling (in practice, this
> usually ends up being simplest by running all GUI activities in a
> single thread). Windows is expecially strict about this - X is
> slightly more permissive, but you are much better off following the
> 'one GUI thread' rule.
>
> Assuming that you have a multi-threaded application, typical design is
> for GUI to signal other 'worker' threads (which signal back). Again,
> details are likely to be very application dependent.
>
> One  final, somewhat unrelated issue: if you are planning to use
> wxWidgets with GHCi, it is worth knowing that you can actually only
> issue one start command in a given GHCi session. This is an underlying
> wxWidgets issue (use of static destructors in C++ code, I believe)
> which means that wxWidgets can only be restarted by unloading and
> reloading the wxWidgets DLL. Since GHCi isn't capable of doing this,
> you basically need to quit and restart a new session.
>
> There *is* a workaround for this: use wxWidgets 2.4.2 or earlier,
> which have a different allocation/deallocation strategy. This is why
> we continue to support wxWidgets 2.4.2.
>
> Regards
> Jeremy
>

Re: [wxhaskell-users] process crashes on second 'start'

[Jeremy O'D. <jer...@gm...>]

Hi Conal,

On 07/12/06, Conal Elliott <co...@co...> wrote:
> Hi Jeremy,
>
> Thanks for the detailed pointers about wxWidgets, GUIs, and multi-threading.
>  My use is actually very simple.  The only reason I wanted multiple
> (sequential, not concurrent) invocations of 'start' is for convenience of
> use in ghci.
>
> I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that this
> problem was worked around in 2.4.2 for use with ghci.  Is there really no
> way to fix the situation with 2.6.3?

This is what Daan said (in passing, in the context of another message
about the new wxHaskell maintenance team):

"Finally, I am not convinced that we should always use the latest
wxWidgets version: In particular, the 2.4.2 version is the only one
that lets you start and restart wxhaskell apps under GHCI under
window. The newer versions use static c++ classes and the destructors
are not called once the dll is loaded under GHCI (fixing this requires
fixing wxWidgets or letting GHCI reload DLL's too)."

> Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
> including unicode issues?

I believe so (translation: I managed to get it to work on my PC under
WinXP). I understand that Unicode support in 2.4.2 is not so thorough
as for 2.6.3, although my Unicode requirements are minimal, so I
wouldn't expect to have seen any significant issues. Eric is working
on ways to test Unicode support more thoroughly. He's already
published one darcs patch.

In a couple of days (i.e. when it works...) I will be recompiling my
wx 2.4.2 based installation to test the new NMAKE makefile for wxc
(intention is to avoid the messy editing of Visual Studio project
files and create something easier to maintain). I'll let you know how
that goes.

> Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?

Yes, although it's not my primary platform by a long way.

Jeremy

Re: [wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

I did get wxHaskell-0.10.1 and wxWidgets-2.4.2 working together.  Multiple
'start's (hence ghci-friendly), and no string truncation, so I'm content.
And I prefer the more vertically compact visual style of sliders in 2.4.2over
2.6.3.  I was fooled at first in recompiling wxWidgets with
--enable-unicode.  I had to completely empty out my "mybuild" directory, not
just "make clean" to fix string truncation (unicode glitch).   - Conal

On 12/8/06, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> Hi Conal,
>
> On 07/12/06, Conal Elliott <co...@co...> wrote:
> > Hi Jeremy,
> >
> > Thanks for the detailed pointers about wxWidgets, GUIs, and
> multi-threading.
> >  My use is actually very simple.  The only reason I wanted multiple
> > (sequential, not concurrent) invocations of 'start' is for convenience
> of
> > use in ghci.
> >
> > I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that
> this
> > problem was worked around in 2.4.2 for use with ghci.  Is there really
> no
> > way to fix the situation with 2.6.3?
>
> This is what Daan said (in passing, in the context of another message
> about the new wxHaskell maintenance team):
>
> "Finally, I am not convinced that we should always use the latest
> wxWidgets version: In particular, the 2.4.2 version is the only one
> that lets you start and restart wxhaskell apps under GHCI under
> window. The newer versions use static c++ classes and the destructors
> are not called once the dll is loaded under GHCI (fixing this requires
> fixing wxWidgets or letting GHCI reload DLL's too)."
>
> > Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
> > including unicode issues?
>
> I believe so (translation: I managed to get it to work on my PC under
> WinXP). I understand that Unicode support in 2.4.2 is not so thorough
> as for 2.6.3, although my Unicode requirements are minimal, so I
> wouldn't expect to have seen any significant issues. Eric is working
> on ways to test Unicode support more thoroughly. He's already
> published one darcs patch.
>
> In a couple of days (i.e. when it works...) I will be recompiling my
> wx 2.4.2 based installation to test the new NMAKE makefile for wxc
> (intention is to avoid the messy editing of Visual Studio project
> files and create something easier to maintain). I'll let you know how
> that goes.
>
> > Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?
>
> Yes, although it's not my primary platform by a long way.
>
> Jeremy
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>