Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

[Claus R. <cla...@ta...>]

>I keep using 2.4.2 on windows since it
>
>1) seems to have just the same set of features as 2.6
>2) is very stable
>3) is the only version that works well with ghci

1) - there seem to be a few new features, but I don't have any urgent
    need for them yet
    - more interesting is that the change logs show a number of bug-fixes
    and minor improvements

2) hmm. you mean "insufficiently tested"?-)

3) now, this is the worrying bit: if I take your and shelarcy's comments,
    it seems that the further one moves from 2.4.2 towards the current
    stable version, the more features stop cooperating with the Haskell
    side tools. unless that can be fixed, wxHaskell will be cut off from
    bug fixes, improvements, and new features developed in wxWidgets.
    (and don't tell me its only on windows, please - if it isn't portable,
    with roughly the same feature-/bug-set, it isn't of any use!-). even
    using different versions on different platforms is not quite the
    kind of portability I would be hoping for..

>About the last point: all the newer versions of wxWidgets rely on static
>initializers: these are initialized when the dynamic link library is loaded
>(like static C++ constructors) -- when ghci loads. When I run a program from
>ghci, everything is fine. However, ghci keeps the dll loaded and does not
>reinitialize the library. When running the program again from the command line,
>the library is in a random state and (usually) crashes. The fix is not easy:
>either the wxWidgets library needs a thorough cleanup to be more stateless, or
>the ghci interpreter needs special code to reload dynamic link libraries. I like
>the last solution but it is a tricky business :-)

you can already defer the -package wx option until after you've started 
your ghci session, indeed 6.5 will infer the package from the module and
load when running main for the first time. so loading dlls is not tied to 
loading ghci but to when ghci loads the package. and if I keep loading 
different modules that need different packages, then ghci should really 
provide a way to get rid of packages and their dlls (which it doesn't).

I don't remember enough of my C++, but aren't static initialisers
meant to initialise persistent state? so you're saying that you can
still use ghci for an interactive session with several commands, but 
there is no way to tell ghci that the current session is ended, and that
the dll should be reloaded for a new session (short of exiting ghci..)? 

It is unlikely that wxWindows will change its ways for us, so I guess 
you're right - one needs a way to reset ghci. but if dynamic loading 
already works, unloading shouldn't be difficult any more (unless 
dynamic loading is handwritten instead of using the native support 
libraries?). and once the dll is unloaded, setting the package again 
should work. have you asked the ghci gurus? 

from a quick browse through ghci/{Linker,ObjLink}.lhs and 
rts/Linker.c, it seems that (amongst lots of stuff I won't even try to 
understand) there are special cases explicitly to avoid unloading 
and re-loading an already loaded lib - perhaps some of those can 
simply be dropped, or at least, a forced unload/reload be provided? 
it might not be all that tricky - but the gurus will know!-)

cheers,
claus