wxhaskell-users

[wxhaskell-users] wxHaskell repo restored to code.haskell.org

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

Hi all,

I'm pleased to announce that as of last night UK time, and with the help of
a Google Talk mini-hackathon from Eric (thanks Eric :-), wxHaskell has been
restored to code.haskell.org.

Compared to the released version on cabal, this contains the following
changes:

   - Change to hasked darcs repo, whcih should make complete repo pulls much
   quicker.
   - Patches from Eric to enable wxHaskell to build against Haskell Platform
   2011.2.0.1
   - Removal of quite a few deprecated and removed functions, particularly
   ODBC bindings.
   - Support build with both wxWidgets 2.8.x and 2.9.x (see below)
   - Remove a number of warnings
   - Change Cabal license type from LGPL to 'Other'. This is *not* a license
   change: wxHaskell has always been licensed under the wxWidgets license.
   While this is very similar to LGPL, it differs in one absolutely vital area,
   which is that it explicitly allows for binary distribution of closed source
   programs which simply use wxHaskell, and I wanted our cabal stanzas to
   reflect this..
   - Version bump to 0.13 to reflect support for wxWidgets 2.9
   - Bugfix for assert error in SearchDynamicEventTable which was found in
   debug builds. I believe that this is a proper fix for an issue Eric noted a
   couple of months back.

I would like to make a new wxHaskell release fairly shortly, but there are a
few issues which *may* need changes before I can do so - I'd appreciate
testers to check whether there is a problem.

The main issue is that wxWidgets 2.9 is impossible to build on my Windows
machine in Monolithic mode (runs out of memory). This, of course, led to a
cascade of problems which are related to the fact that the external
wx-config program we use to determine what libraries are used on Windows has
many bugs and doesn't properly support wxWidgets 2.9 (or 2.8 when compiled
non-monolithic). Because of this there are some nasty hacks in the wxcore
Setup.hs to pull in the correct libraries, and these may cause problems with
the pre-compiled wxWidgets provided on non-Windows platforms. Please let me
know if this is the case.

I built wxWidgets (2.8.11 and 2.9.1) as follows:
Ensure that USE_HTML=1 and USE_XRC=1 are set in setup.h
> make -f makefile.gcc USE_OPENGL=1 UNICODE=1 SHARED=1 BUILD=debug

As a reminder, here's how to build wxHaskell from source, assuming that you
have wxWidgets installed with the WXWIN and WXCFG environment variables set
to point to the wxWidgets root directory and configuration respectively:

cd <place where you plan to build>
darcs get http://code.haskell.org/wxhaskell/
cd wxhaskell/wxdirect
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wxcore
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wx
runhaskell Setup.lhs configure
runhaskell Setup.lhs build
runhaskell Setup.lhs install

Windows users will need to run the install stanzas from within a command
windows with administrative priviledge. Note also that on Windows, your PATH
needs to have the wxWidgets DLLs present if you want to actually run
anything.

Just for information, I have (non-tested) patches on my machine for the
following:

   - Wrapper for wxDisplay (requested by Brian Victor)
   - {H|V}Slider which supports swapped order - code graciously provided by
   Henning Thielmann
   - Wrapper OpenGL contexts

These will be added to the repo as soon as I have convinced myself that they
work on more than one machine ;-)

Thanks to all for your patience.

Best regards
Jeremy

Re: [wxhaskell-users] wxHaskell repo restored to code.haskell.org

[Guy <guy...@ya...>]

On 03/06/2011 14:14, Jeremy O'Donoghue wrote:
> The main issue is that wxWidgets 2.9 is impossible to build on my Windows machine in Monolithic mode (runs out of
> memory).

This is reported as a GHC memory leak
http://hackage.haskell.org/trac/ghc/ticket/4800

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell repo restored to code.haskell.org

[<E....@br...>]

On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote:
>    - Bugfix for assert error in SearchDynamicEventTable which was found in
>    debug builds. I believe that this is a proper fix for an issue Eric noted a
>    couple of months back.

It's not just debug builds (of what?), but basically the scenario where
you naively type "cabal install wx" on MacOS after having installed the
Haskell Platform and nothing else.   Macs ship with wxWidgets, albeit
with this crucial bit of missing functionality.

I'm a bit concerned that this may result in silently-does-the-wrong-thing
errors

+  if (evtHandler->GetDynamicEventTable() != NULL)
+    found = evtHandler->SearchDynamicEventTable( event );

As I'd discovered to my dismay, without this trawl through the non-existent
dynamic event table, things like scrolled list boxes stop responding to events.
  http://www.mail-archive.com/wxh...@li.../msg00580.html

If I understand the patch correctly, the result of this is that (A)
users would be able to happily install wxHaskell on Mac without any
prerequisites, but (B) if they were to use such a widget, it would just
silently not-work.

Much better to blow up from the beginning, I'm afraid :-(

Perhaps what we need is to use this opportunity to give a more friendly
error, something like this pseudocode
 
else {
  friendlyError $ "Your wxWidgets is missing a feature needed by wxHaskell."
               ++ "See http://haskell.org/haskell/wxHaskell for instructions"
               ++ "on installing a complete wxWidgets on your computer"
}

The even better solution would be for somebody to go understand how the event
handling code works and propose a solution that works without the missing
dynamic event table

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

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell repo restored to code.haskell.org

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

On 3 June 2011 12:44, <E....@br...> wrote:

> On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote:
> >    - Bugfix for assert error in SearchDynamicEventTable which was found
> in
> >    debug builds. I believe that this is a proper fix for an issue Eric
> noted a
> >    couple of months back.
>
> It's not just debug builds (of what?),


Of wxWidgets itself. I don't see the assertion for retail builds. I *do* see
the assertion on debug builds for Windows, so I don't think it's a Mac
issue.

but basically the scenario where
> you naively type "cabal install wx" on MacOS after having installed the
> Haskell Platform and nothing else.   Macs ship with wxWidgets, albeit
> with this crucial bit of missing functionality.
>
> I'm a bit concerned that this may result in silently-does-the-wrong-thing
> errors
>
> +  if (evtHandler->GetDynamicEventTable() != NULL)
> +    found = evtHandler->SearchDynamicEventTable( event );
>
> As I'd discovered to my dismay, without this trawl through the non-existent
> dynamic event table, things like scrolled list boxes stop responding to
> events.
>
> http://www.mail-archive.com/wxh...@li.../msg00580.html
>

This is a bit more worrying - it's likely to be seen on other platforms as
well. I didn't see the problem on any of the (few) test cases I ran, but it
sounds more like a failure of what might laughably be called my test regime
than a Mac specific issue.


> If I understand the patch correctly, the result of this is that (A)
> users would be able to happily install wxHaskell on Mac without any
> prerequisites, but (B) if they were to use such a widget, it would just
> silently not-work.
>

No - I think it would silently not work everywhere :-(


> The even better solution would be for somebody to go understand how the
> event
> handling code works and propose a solution that works without the missing
> dynamic event table
>

That's probably a better bet. I have the impression that you're not really
supposed to call wxEvent::SearchDynamicEventTable() from outside anyway.
They seem to have gone to some lengths to not document it in wxWidgets.

I will have a go at understanding the event handling code. Wish me luck,
I'll probably need it...

Jeremy