Home > wxHaskell > Ever expanding TODO lists

Ever expanding TODO lists

There was a short discussion on the wxhaskell-users list yesterday about a fairly long outstanding wxHaskell bug: the fact that you cannot restart a wxHaskell GUI from within GHCi.

This post is not about that bug, but about a comment from Eric Kow:

 people are actually quite understanding about things being done slowly if
 they have a clear idea where they're headed, ie. what's being prioritised,
 what's not; what things are blocked on, etc.

Eric is quite right, of course, so this post is a quick dump of my wxHaskell TODO list. Sadly, at the moment I seem to be the only person doing any wxHaskell core development (though I’d like to namecheck some great help from Brian Lewis on Cabalizing wxHaskell a couple of months back), so it is probably the wxHaskell TODO list. The list is in approximate priority order, although I reserve the right to change it unilaterally if I find I have an urgent need for something!

  1. Update wxHaskell to work with GHC 6.12.1 once the next Haskell Platform is released (I don’t have the time to go putting together a complete platform myself from source, so I’ll wait on the Platform)
  2. Finish the series on wxhNotepad. I see this as extremely important in helping wxHaskell beginners to get going. The next two posts are mostly finished, and you should see them soon.
  3. Solve the problem (a consequence of Cabalization) that, at least on Mac and Windows, it is no longer possible to use wxHaskell at all in GHCi due to a dependency on libstdc++ (which exists only as a static library on Mac and Windows). This is really a GHC/GHCi bug, but we need to deal with the consequences.
  4. Write improved documentation and/or blog articles on specific aspects of wxHaskell. Layout is a strong contender for more work.
  5. Investigate why wxHaskell cannot be reloaded in GHCi. Actually, I have a pretty good idea what the problem is. The wxWidgets library uses C++ static constructors and destructors in a few key places. When wxHaskell returns, what it actually does is to return from wxApp::OnInit(). Unfortunately, on return from this function, some of the internal structures of wxWidgets are corrupted and this can only be resolved by ensuring that the static destructors are executed and that the static constructors are re-run. I believe that the solution will probably involve dynamically unloading the wxWidgets library and reloading it. Since this is something which is almost completely OS-dependent, it will require me immersing myself in arcane details of dynamic linking for Windows, Linux and Mac to get it working.
  6. Get the Styled Text Control back into wxHaskell, but now as a separate (Cabal installable) module. This will act as a demonstration/tutorial for bringing any wxWidgets component which can be compiled as a separate library into wxHaskell
  7. Look at the list of bugs – both in the buglist and those accumulated in wxhaskell-users
  8. Write a guide to make it easier for others to contribute to wxHaskell. I’m well aware that the amount of effort I can contribute to the project is not really enough to keep it thriving, and I’d like to lower the barrier to entry.

I find it slightly sad that the Haskell community doesn’t really seem able to support even one full-featured GUI binding (from what I can see, Gtk2hs development is also very slow at the moment). It’s not very glamorous work, but I believe it is an important part of making Haskell useful to a wider range of people.

About these ads
Categories: wxHaskell
  1. Andrew Butterfield
    February 17, 2010 at 8:56 am | #1

    I find I can work with both xwHaskell 0.11.1.2 and GHCi 6.10.4, provided that, once
    my main has finished, I immediately exit GHCi and re-load the whole program. If I do that, I find it has usually re-built everything before my next program edit is done.
    I then save that, reloadd, and continue working…

    I’d love to be able to help more – I don’t have the system level expertise you need, but when my application gets stable, I hope to take some time to document my more interesting uses of wxHaskell and contribute that way…

  2. February 17, 2010 at 11:09 am | #2

    Thanks for a supportive comment – it really helps!

    The problem with libstdc++ occurs with wxHaskell 0.12 and later. It was at this time that we switched to the new cabalized build system.

    You’re quite correct that if you quit GHCi and restart, then all works well, but some people find the ‘exploratory’ style of development using GHCi to be very efficient for them, which is why I’d like to fix this.

    All forms of help are highly appreciated though, and documenting how to use wxHaskell is very important – GUI programming in Haskell is a neglected area. Even in Real World Haskell, there is only one very short chapter (using Gtk2hs unfortunately)

  3. markus
    May 15, 2010 at 6:30 pm | #3

    Today I played with wxHaskell on MSW using Haskell Platform 2010.1.0.0 (enhanced by mingw c++ files) and wxWidgets-2.8.11 compiled as one monolithic DLL.

    cabal install succeeded for wxcore, wx, and wxhnotepad (got a working wxhnotepad.exe).

    Loading wxcore failed in ghci due to missing library stdc++
    can’t load .so/.DLL for: …

    Removed ++ “-l stdc++” from Setup.hs in wxcore-0.12.1.4.tar.gz cabal package

    cabal install –reinstall succeeded again for wxcore and wx

    Loading wxcore failed in ghci due to missing library wxtiff

    ghc -package wx -o hello HelloWorld.hs failed horribly with messages like:
    “undefined reference to `operator new(unsigned int)’”

    cabal install –reinstall wxhnotepad failed likewise when linking the executable

    Thus:

    “-l stdc++” in Setup.hs seems necessary for ghc to link statically against mingw libstdc++.a

    ghci gets confused by this information looking for a dynamic library

    ghci gets confused by information about other libraries like wxtiff

    Altough wxWidgets is compiled into one DLL wx-config.exe reports a lot of -lwx…
    These are present in the wxWidgets folder as libwx*.a files.

    C:\Temp>wx-config –libs
    -mthreads -LC:\wxWidgets-2.8.11\lib\gcc_dll -lwxmsw28u -lwxtiff -lwxjpeg -lwxpn
    g -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwxregex
    u -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -la
    dvapi32 -lwsock32

    • May 17, 2010 at 10:36 am | #4

      Hi Markus,
      You have the analysis of what is happening correct. The root cause is really a GHCi issue – it should not need to care about whether a library is loaded statically or dynamically (or, alternatively, if it does care, then GHC should also care), but in fact it is unable to cope with statically linked libraries.

      Unfortunately, GHC is distributed with a version of MinGW which doesn’t support a dynamically linked libstdc++, which really means that GHCi is heavily flawed when it comes to linking with C++ code.

      It’s not too clear what is going to be the best way forward out of this impasse – probably more work on the build system, so that libstdc++ can be wrapped inside a DLL.

      If you have any better ideas on the way forward, I’d love to hear about them.

  1. April 28, 2010 at 4:47 pm | #1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: