Re: [wxhaskell-devel] wxHaskell vs GHCi

[Eric K. <eri...@gm...>]

Thanks! I've taken the liberty of filing this at
https://sourceforge.net/p/wxhaskell/bugs/84/

Conal, am just CC'ing you because you've been suffering most from this
GHCi bug, which I think sounds important.  Just letting you know that
we now have a BTS ticket for it, and some technical info on said
ticket.

Sorry for not being more helpful; just hoping this tiny bit of admin
dot-connecting can help move things forward.

As I understand it, the new new wxHaskell crew have been very active —
thanks guys! — but are now focused on getting a new release out from
all their hard work lately.  So this GHCi-related stuff would have to
be after said release

On 8 October 2013 16:16, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> When I last looked at the problem, the issue was that wxWidgets libraries
> use static constructors and destructors in some places.
>
> Problem with static constructors is that they typically run before main() -
> or its equivalent - is called. This means that once you quit an application,
> there is no way to restart without relaunching executable.
>
> Similarly, static destructors only run after app has called exit().
>
> There were a couple of approaches I considered:
> * Implement a wrapper which forces dynamic load and unload of the wxWidgets
> libraries from inside wxc. This would work because when reloading the
> libraries (as you would when restarting app at GHCi), the static
> constructors run (e.g. in Windows they usually run just before DllMain() is
> called). This is easy, but very tedious to do in practice, and would only
> really make sense if the wxWidgets bindings are auto-generated.
>
> * Fake application exit when running in GHCi so that when app starts again
> the same event loop is used, and the static destructors are never called.
> This would be a very neat solution, but state management is very tricky.
>
> Regards
> Jeremy
>
> On 7 October 2013 06:53, Eric Kow <eri...@gm...> wrote:
>>
>> I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
>> Perhaps it'd be worthwhile creating a new ticket for the problems
>> Conal was facing? (they are very old problems, if I remember
>> correctly).
>>
>> Do we even know what the issue is about?
>>
>> On 6 October 2013 20:54, Henk-Jan van Tuyl <hj...@ch...> wrote:
>> > On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow <eri...@gm...> wrote:
>> >
>> >> Just thought I might call your attention to this thread:
>> >>
>> >> http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
>> >>
>> >> GHCi support seems like something that might be worth bubbling up the
>> >> agenda?
>> >
>> >
>> > Shouldn't GHCi support be all right with the next GHC release? Did
>> > someone
>> > try a nightly build of GHC to test this? There are no nightly builds for
>> > Windows, and I can't get GHC compiled, so I cannot test this.
>> >
>> > Regards,
>> > Henk-Jan van Tuyl
>> >
>> >
>> > --
>> > Folding@home
>> > What if you could share your unused computer power to help find a cure?
>> > In
>> > just 5 minutes you can join the world's biggest networked computer and
>> > get
>> > us closer sooner. Watch the video.
>> > http://folding.stanford.edu/
>> >
>> >
>> > http://Van.Tuyl.eu/
>> > http://members.chello.nl/hjgtuyl/tourdemonad.html
>> > Haskell programming
>> > --
>>
>>
>>
>> --
>> Eric Kow <http://erickow.com>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>



-- 
Eric Kow <http://erickow.com>