From: Daan L. <da...@cs...> - 2005-05-11 07:49:55
|
Claus Reinke wrote: >>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. Yes, these are vallid concerns. Of course, in the long run, I hope that ghci gets fixed and is able to reload the dynamic link libraries. If you think about it, it should do so anyway for *all* dynamically linked code -- it is a miracle that other libraries work correctly :-) If this is not going to happen, someone will have to bite the bullet and write a "re-initializer" for wxWidgets, but this is potentially a lot of work and will need maintenance all the time -- something I try to avoid. > (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.. Well, even if you use the same library version the portability will *not* be perfect. This can be considered *the* feature of wxWidgets: since it uses native widgets it gives a native look-and-feel, but also small differences between platforms. My main goal for the "wx" layer is to create programs that run directly on each platform -- but it might be that a final program needs some tuning for each particular platform. "WXCore.Defines" can be used to write platform specific code. >>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..)? Here is an example in C: > static Handle window = NULL; > > void runWxWidgets( void ) { > if (window == NULL) { window = osCreateWindowHandle(); } > osShowModalWindow( window ); > } When I create a haskell wrapper for "runWxWidgets", the first invokation from ghci works fine. However, the next invokation crashes ghci as it still uses the "old" window handle that is no longer valid for the OS. In reality, it is a bit more complicated since a static C++ object does not just get a value assigned, but also runs the code of the constructor. There is generally no documented way to run the destructor except for "unloading" the dll. > 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!-) The GHC guru's know about this particular problem. However, *someone* will have to do it -- even though it is maybe not too hard to implement it, it surely requires knowledge of ghc and intricate linker issues. It would be very cool to have this working though :-) Cheers, Daan. |