wxhaskell-devel — wxhaskell developers

[wxhaskell-devel] Fwd: Building wxcore on Ubuntu 10.04

[Dave T. <duk...@gm...>]

Hi all,

I am having trouble compiling wxcore on Ubuntu 10.04.
The source I am using I pulled with a "darcs get" from hackage, I then
descended into the wxcore directory and did a "cabal configure".

It gives me a "* Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8,
wx_baseu_xml-2.8..." error,
I have the .so files for "libwx_baseu-2.8.so" in my /usr/lib, but I don't
have any headers in /usr/include, could this be a problem?
If so then does anyone know where I can obtain these headers? I have already
installed the libwxbase2.8-dev and libwxgtk2.8-dev packages.

Running "cabal configure -v3" I can see the first problem is this:
"/usr/bin/ld: cannot find -lwxmsw28ud_media"
Is it safe to assume that "msw" refers to MS Windows? If so should I be
trying to link against this when building in Linux?

I have pasted the full output from "cabal configure -v3" here:
http://hpaste.org/49326

Thanks,
Dave

[wxhaskell-devel] Building wxcore on Ubuntu 10.04

[Dave T. <dav...@gm...>]

Hi all,

I am having trouble compiling wxcore on Ubuntu 10.04.
The source I am using I pulled with a "darcs get" from hackage, I then
descended into the wxcore directory and did a "cabal configure".

It gives me a "* Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8,
wx_baseu_xml-2.8..." error,
I have the .so files for "libwx_baseu-2.8.so" in my /usr/lib, but I don't
have any headers in /usr/include, could this be a problem?
If so then does anyone know where I can obtain these headers? I have already
installed the libwxbase2.8-dev and libwxgtk2.8-dev packages.

Running "cabal configure -v3" I can see the first problem is this:
"/usr/bin/ld: cannot find -lwxmsw28ud_media"
Is it safe to assume that "msw" refers to MS Windows? If so should I be
trying to link against this when building in Linux?

I have pasted the full output from "cabal configure -v3" here:
http://hpaste.org/49326

Thanks,
Dave

[wxhaskell-devel] Conflicting exports in wxcore

[<mac...@gm...>]

I get the following during "cabal install" in wxcore (darcs tip):

--------------------------------------
src\haskell\Graphics\UI\WXCore.hs:25:11:
    Conflicting exports for `wxEVT_FIRST':
      `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcClasses at
src\haskell\Graphics\UI\WXCore.hs:47:1-36

                            (defined at
src\haskell\Graphics\UI\WXCore\WxcClassesMZ.hs:17133:1)
      `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcDefs at
src\haskell\Graphics\UI\WXCore.hs:46:1-33

                      (defined at src\haskell\Gra
phics\UI\WXCore\WxcDefs.hs:2969:1)

src\haskell\Graphics\UI\WXCore.hs:25:11:
    Conflicting exports for `wxEVT_NULL':
      `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcClasses at
src\haskell\Graphics\UI\WXCore.hs:47:1-36

                           (defined at src\haskel
l\Graphics\UI\WXCore\WxcClassesMZ.hs:17700:1)
      `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcDefs at
src\haskell\Graphics\UI\WXCore.hs:46:1-33

                     (defined at
src\haskell\Graphics\UI\WXCore\WxcDefs.hs:2966:1)
--------------------------------------

Is it a known issue?

Regards,
Maciek

Re: [wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically

[Heinrich A. <apf...@qu...>]

Heinrich Apfelmus wrote:
> Dmitriy Nikitinskiy wrote:
>> Heinrich Apfelmus wrote:
>>> Seems to be the same as this bug:
>>>
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863
>>>
>>> Any workaround?
>>>
>> On my side this example works ok.
>> I have tested on openSuSe 11.4 and WinXp with ghc-7.0.2 and wxWidgets-2.8.11.
> 
> Ah, I should have mentioned that I am on Mac OS X, version 10.6.8 .

Apparently, I'm not very good at reporting bugs. I had  wxWidgets-2.8.8 
  which came bundled with the OS. Installing a newer version (2.8.12) 
via MacPorts fixes the problem.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: [wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically

[Heinrich A. <apf...@qu...>]

Dmitriy Nikitinskiy wrote:
> Heinrich Apfelmus wrote:
>>
>> I want to set the text of a text entry while the program is running, but
>> wxWidgets/wxHaskell crashes with the following assertion failure:
>>
>> ../src/common/strinc.pp(410): assert "nStart<= length()" failed in erase()
>>
>> Here a minimal program that crashes when you click the button:
>>
>>       import Graphics.UI.WX
>>
>>       main = start $ do
>>           f<- frame    [ text := "Test" ]
>>           e<- entry f  [ text := "A" ]
>>           b<- button f [ text := "Button"
>>                         , on command := set e [ text := "B" ] ]
>>           set f [ layout := row 5 [ widget b, widget e]]
>>
>> Seems to be the same as this bug:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863
>>
>> Any workaround?
>>
> 
> On my side this example works ok.
> I have tested on openSuSe 11.4 and WinXp with ghc-7.0.2 and wxWidgets-2.8.11.

Ah, I should have mentioned that I am on Mac OS X, version 10.6.8 .


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: [wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically

[Dmitriy N. <ni...@be...>]

12.07.2011 17:39, Heinrich Apfelmus wrote:
> Hello,
>
> I want to set the text of a text entry while the program is running, but
> wxWidgets/wxHaskell crashes with the following assertion failure:
>
> ../src/common/strinc.pp(410): assert "nStart<= length()" failed in erase()
>
> Here a minimal program that crashes when you click the button:
>
>       import Graphics.UI.WX
>
>       main = start $ do
>           f<- frame    [ text := "Test" ]
>           e<- entry f  [ text := "A" ]
>           b<- button f [ text := "Button"
>                         , on command := set e [ text := "B" ] ]
>           set f [ layout := row 5 [ widget b, widget e]]
>
> Seems to be the same as this bug:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863
>
> Any workaround?
>

On my side this example works ok.
I have tested on openSuSe 11.4 and WinXp with ghc-7.0.2 and wxWidgets-2.8.11.

Best regards,
Dmitriy.

[wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically

[Heinrich A. <apf...@qu...>]

Hello,

I want to set the text of a text entry while the program is running, but 
wxWidgets/wxHaskell crashes with the following assertion failure:

../src/common/strinc.pp(410): assert "nStart <= length()" failed in erase()

Here a minimal program that crashes when you click the button:

     import Graphics.UI.WX

     main = start $ do
         f <- frame    [ text := "Test" ]
         e <- entry f  [ text := "A" ]
         b <- button f [ text := "Button"
                       , on command := set e [ text := "B" ] ]
         set f [ layout := row 5 [ widget b, widget e]]

Seems to be the same as this bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863

Any workaround?


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: [wxhaskell-devel] [wxhaskell-users] Haskell Platform roadmap?

[Henning T. <le...@he...>]

On Thu, 16 Jun 2011, Heinrich Apfelmus wrote:

> I'm currently working on the FRP part [1]. It turns out that FRP is
> completely orthogonal to wxHaskell; there is no need to add special
> support for FRP in the GUI library. A handful of convenience wrappers
> [2] are enough to transform wxHaskell into a fully featured FRP-GUI
> library.

+1

> In other words, you can simply focus on the mid-level GUI
> bindings and get that into the platform.

May I advertise my enumset library that allows to handle flag sets as the 
ones in Graphics.UI.WXCore.WxcDefs in a safe and efficient way:
    http://hackage.haskell.org/package/enumset

Re: [wxhaskell-devel] Building wxcore on Windows: problem with wx-config

[Maciek M. <ma...@mm...>]

This is darcs tip, hackage version built fine for me a couple of weeks ago.

Do we want the ability to build given version of wxHaskell against different
versions of wxWidgets? If so, wouldn't patching wx-config-win be the
simplest solution?

Maciek

On 20 Jun 2011 00:28, "Jeremy O&apos;Donoghue" <jer...@gm...>
wrote:

On 19 June 2011 22:03, <mac...@gm...> wrote:
>
> wx-config-win (from https://sites.goog...
Haven't seen this - I'll look into it (there are other problems with
wx-config, but this is a new one on me).

Assume you're trying to build either darcs tip or current hackage version
with latest Haskell Platform. Please let me know if it isn't one of these.

Jeremy

Re: [wxhaskell-devel] Building wxcore on Windows: problem with wx-config

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

On 19 June 2011 22:03, <mac...@gm...> wrote:

> wx-config-win (from https://sites.google.com/site/wxconfig/) does not
> support --version flag used by latest wxcore/Setup.hs. How should I go
> about building on Windows?
>

Haven't seen this - I'll look into it (there are other problems with
wx-config, but this is a new one on me).

Assume you're trying to build either darcs tip or current hackage version
with latest Haskell Platform. Please let me know if it isn't one of these.

Jeremy

[wxhaskell-devel] Building wxcore on Windows: problem with wx-config

[<mac...@gm...>]

wx-config-win (from https://sites.google.com/site/wxconfig/) does not
support --version flag used by latest wxcore/Setup.hs. How should I go
about building on Windows?

Regards,
Maciek

Re: [wxhaskell-devel] Haskell Platform roadmap?

[Heinrich A. <apf...@qu...>]

Jeremy O'Donoghue wrote:
> - Extend Graphics.UI.WX so that more of the core functionality has 
> high-level wrappers, e.g. for Grid, List boxes etc. I would love to
> see an FRP wrapper around parts of wxHaskell, and think we could 
> reinstate one or more of the FRP libraries, for example. Making GUI
> programming less like C programming would do a lot to promote Haskell
> GUI development, but it requires much better Haskell-fu than I have
> to offer.

I'm currently working on the FRP part [1]. It turns out that FRP is 
completely orthogonal to wxHaskell; there is no need to add special 
support for FRP in the GUI library. A handful of convenience wrappers 
[2] are enough to transform wxHaskell into a fully featured FRP-GUI 
library. In other words, you can simply focus on the mid-level GUI 
bindings and get that into the platform.


If anything, it would be very useful to fix the GHCi issue. Developing 
an FRP library is still a very experimental activity and having GHCi 
support makes prototyping a lot faster. (Conal Elliott would agree with 
that.)


   [1]: http://hackage.haskell.org/package/reactive-banana
   [2]: http://hackage.haskell.org/package/reactive-banana-wx

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: [wxhaskell-devel] [wxhaskell-users] Haskell Platform roadmap?

[Maciek M. <ma...@mm...>]

Getting wxHaskell into HP would be great and I'd be happy to commit a
couple of hours each week for a year to help make it happen. That
said, I'm relatively new to Haskell and have very little experience
with linking with native libraries (my day job is Java programming) so
I might need quite a lot of guidance, at least initially.

Regards,
Maciek

On Tue, Jun 14, 2011 at 11:36 PM, Jeremy O'Donoghue
<jer...@gm...> wrote:
> Hi all,
>
> This is a call for help. There's been some discussion both on this list and
> on the cafe about getting a GUI into Haskell Platform.
>
> The formal requirement is that inclusion needs to be supported by at least
> one library maintainer, and from a practical perspective it should be
> something which builds and works well on all supported platforms, i.e.
> Linux, Windows and Mac, and should have a team of maintainers who are able
> to maintain the code over a long term basis.
>
> While there have been some fantastic contributions to wxHaskell over the
> past years from any people, the reality is that most of the work gets done
> by me, and some may have noticed that I don't have a lot of time - certainly
> nothing like enough to commit to inclusion in Haskell Platform.
>
> The call for help is this: can we get together a team which would be able to
> field enough effort to make a submission for Haskell Platform realistic? I
> believe that such a team would look something like the following:
>
> Project lead, release co-ordinator and mentor to others. That will be me
> then.
> Target leads for Linux, Mac and Windows. Responsible for building tip code
> for their platforms and providing fixes when it breaks. In the case of Mac
> and Linux, extra points if you can make things work using the platform
> built-in wxWidgets.
> A number of specific functional areas to be addressed:
>
> Fix the long-standing bug preventing GHCi use of wxHaskell. In my opinion,
> this is best addressed by factoring the C wrapper for wxHaskell (we call it
> wxC) into a separate library which is built as a dynamically loadable
> library. I know, in principle, how to do this for Windows and Linux, but
> would need help for Mac. Anyone who wants to help should know that this
> involves lots of revolting work with linkers, and is especially suitable for
> masochists. That's probably me as well.
> Make it easier to wrap some of the optional wxWidgets libraries. This
> requires work on wxDirect. This is probably the easiest area to work on as
> wxDirect is a self-contained executable, and is small and fairly simple to
> understand.
> Using the above, wrap some of the optional libraries. STC should be
> reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
> there are many others. OpenGL canvas, AUI and the media framework look
> particularly interesting.
> Consider a pure Haskell replacement for wx-config, at least on Windows, but
> potentially on all targets. We currently bundle a 3rd party wx-config
> replacement for Windows, but it doesn't work very well on wxWidgets 2.9.
> Extend Graphics.UI.WX so that more of the core functionality has high-level
> wrappers, e.g. for Grid, List boxes etc. I would love to see an FRP wrapper
> around parts of wxHaskell, and think we could reinstate one or more of the
> FRP libraries, for example. Making GUI programming less like C programming
> would do a lot to promote Haskell GUI development, but it requires much
> better Haskell-fu than I have to offer.
>
> Go back through the list of bugs and feature requests and fix as many as
> possible. This is an easy starting point for a new wxHaskell contributor.
> Improve documentation. While wxHaskell is pretty good, it could definitely
> be improved. In particular, I think we should consider finding a way to
> generate better documentation for the wxC wrapper functions, which currently
> only include type information.
>
> There's probably a lot more to do, and I welcome comments and suggestions. I
> welcome offers of help even more, and estimate that getting into HP requires
> a core team of 6-8 people who can commit to a few hours per week for at
> least a year. This is a huge ask, but the outcome would be that wxHaskell
> could become part of the Haskell Platform, and would likely be much more
> widely used.
>
> What do you think?
>
> Best regards
> Jeremy
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-devel] Haskell Platform roadmap?

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

On Tue, Jun 14, 2011 at 23:36:37 +0100, Jeremy O'Donoghue wrote:
>    - Target leads for Linux, Mac and Windows. Responsible for building tip
>    code for their platforms and providing fixes when it breaks. In the case of
>    Mac and Linux, extra points if you can make things work using the platform
>    built-in wxWidgets.

So it sounds like what could be handy is to partially automate our way
out of this with something like buildbot.  We would need somebody to
manage the master, and also volunteers to provide always-on Mac, Linux
and Windows machines to do the builds for us.

You can get an idea of what buildbot would buy us at
  http://buildbot.darcs.net/waterfall

I'm a big fan of replacing scarce humans with robots wherever possible.
... but we do need somebody to help with said robots!

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

[wxhaskell-devel] Haskell Platform roadmap?

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

Hi all,

This is a call for help. There's been some discussion both on this list and
on the cafe about getting a GUI into Haskell Platform.

The formal requirement is that inclusion needs to be supported by at least
one library maintainer, and from a practical perspective it should be
something which builds and works well on all supported platforms, i.e.
Linux, Windows and Mac, and should have a team of maintainers who are able
to maintain the code over a long term basis.

While there have been some fantastic contributions to wxHaskell over the
past years from any people, the reality is that most of the work gets done
by me, and some may have noticed that I don't have a lot of time - certainly
nothing like enough to commit to inclusion in Haskell Platform.

The call for help is this: can we get together a team which would be able to
field enough effort to make a submission for Haskell Platform realistic? I
believe that such a team would look something like the following:


   - Project lead, release co-ordinator and mentor to others. That will be
   me then.
   - Target leads for Linux, Mac and Windows. Responsible for building tip
   code for their platforms and providing fixes when it breaks. In the case of
   Mac and Linux, extra points if you can make things work using the platform
   built-in wxWidgets.
   - A number of specific functional areas to be addressed:
      - Fix the long-standing bug preventing GHCi use of wxHaskell. In my
      opinion, this is best addressed by factoring the C wrapper for
wxHaskell (we
      call it wxC) into a separate library which is built as a dynamically
      loadable library. I know, in principle, how to do this for Windows and
      Linux, but would need help for Mac. Anyone who wants to help should know
      that this involves lots of revolting work with linkers, and is especially
      suitable for masochists. That's probably me as well.
      - Make it easier to wrap some of the optional wxWidgets libraries.
      This requires work on wxDirect. This is probably the easiest
area to work on
      as wxDirect is a self-contained executable, and is small and
fairly simple
      to understand.
      - Using the above, wrap some of the optional libraries. STC should be
      reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
      there are many others. OpenGL canvas, AUI and the media framework look
      particularly interesting.
      - Consider a pure Haskell replacement for wx-config, at least on
      Windows, but potentially on all targets. We currently bundle a 3rd party
      wx-config replacement for Windows, but it doesn't work very well on
      wxWidgets 2.9.
      - Extend Graphics.UI.WX so that more of the core functionality has
      high-level wrappers, e.g. for Grid, List boxes etc. I would love
to see an
      FRP wrapper around parts of wxHaskell, and think we could
reinstate one or
      more of the FRP libraries, for example. Making GUI programming
less like C
      programming would do a lot to promote Haskell GUI development, but it
      requires much better Haskell-fu than I have to offer.
   - Go back through the list of bugs and feature requests and fix as many
   as possible. This is an easy starting point for a new wxHaskell contributor.
   - Improve documentation. While wxHaskell is pretty good, it could
   definitely be improved. In particular, I think we should consider finding a
   way to generate better documentation for the wxC wrapper functions, which
   currently only include type information.

There's probably a lot more to do, and I welcome comments and suggestions. I
welcome offers of help even more, and estimate that getting into HP requires
a core team of 6-8 people who can commit to a few hours per week for at
least a year. This is a huge ask, but the outcome would be that wxHaskell
could become part of the Haskell Platform, and would likely be much more
widely used.

What do you think?

Best regards
Jeremy

Re: [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

Re: [wxhaskell-devel] 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-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>

[wxhaskell-devel] 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

[wxhaskell-devel] darcs patch: Update wxdirect for GHC 7. (and 4 more)

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

Hi everybody,

The patches below make wxhaskell build with Haskell Platform
2011.2.0.1.

I would like to upload the updated wxdirect and wxcore to
Hackage as soon as I get a green light from Jeremy.  If I
don't hear back in a couple days, I think I'll go ahead and
just upload as the changes are fairly trivial, just relaxing
some dependencies.

The code.haskell.org repository for wxhaskell has not yet
been restored.  In the meantime, you can use

  darcs get --lazy http://darcsden.com/kowey/wxhaskell

Perhaps wxHaskell should just switch to using darcsden
or patch-tag.

Thanks!

5 patches for repository CONTEXT:

Tue May 17 12:26:22 BST 2011  Eric Kow <eri...@gm...>
  * Update wxdirect for GHC 7.
  With Haskell Platform 2011.2.0.1

Tue May 17 12:27:57 BST 2011  Eric Kow <eri...@gm...>
  * Bump version to 0.12.1.3 for wxdirect.

Tue May 17 12:29:46 BST 2011  Eric Kow <eri...@gm...>
  * Allow wxcore to use containers 0.4.

Tue May 17 12:56:45 BST 2011  Eric Kow <eri...@gm...>
  * Bump wxcore version to 0.12.1.7

Tue May 17 12:57:48 BST 2011  Eric Kow <eri...@gm...>
  tagged haskell-platform-2011.2.0.1

Re: [wxhaskell-devel] using wxHaskell with built-in wxWidgets on MacOS X

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

On 12 March 2011 16:47, Eric Y. Kow <eri...@gm...> wrote:
> I notice that if I stupidly delete this chunk of the wxc layer, I can
> run wxHaskell off the wxWidgets 2.8 that ships with MacOS X (Leopard).
> I imagine that this has a negative side effect relating to event
> handlers, but my own program seems to work fine.

I'm afraid this causes the (surprise!) event handlers for some list boxes
to stop working :-(

Still I think there *must* be someway to make wxHaskell work on native
wxWidgets.  Asking people to build from source seems like madness.

-- 
Eric Kow <http://erickow.com>
PGP Key ID: 08AC04F9

[wxhaskell-devel] [ wxhaskell-Feature Requests-3286608 ] vslider with inverse direction

[SourceForge.net <no...@so...>]

Feature Requests item #3286608, was opened at 2011-04-14 14:56
Message generated for change (Tracker Item Submitted) made by amigalemming
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3286608&group_id=73133

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Amiga Lemming (amigalemming)
Assigned to: Nobody/Anonymous (nobody)
Summary: vslider with inverse direction

Initial Comment:
I propose to extend vslider (and hslider) to reverse the value direction, if minimum and maximum value are swapped.

wxSL_INVERSE :: Int
wxSL_INVERSE = 0x1000

vslider ::
   Window a -> Bool -> Int -> Int -> [Prop (Slider ())] -> IO (Slider ())
vslider parentW showLabels top bottom props =
   let (minV, maxV, dirFlags) =
          if top<bottom
            then (top, bottom, 0)
            else (bottom, top, wxSL_INVERSE)
   in  sliderEx parentW minV maxV
          (wxVERTICAL .+. dirFlags
            .+. (if showLabels then wxSL_LABELS else 0))
          props


At least, wxSL_INVERSE should be defined.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3286608&group_id=73133

[wxhaskell-devel] [ wxhaskell-Bugs-3252931 ] Garbled GUI on GHC 7.0.3 OS X

[SourceForge.net <no...@so...>]

Bugs item #3252931, was opened at 2011-03-28 17:16
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536845&aid=3252931&group_id=73133

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Garbled GUI on GHC 7.0.3 OS X 

Initial Comment:
Recompiling my program with GHC 7.0.3 produces an unusable UI in which the text is missing or garbled.
Running HP 2011.2.0.0 32 bit on OS X 10.6.7 (64 bit) and the latest wxHaskell.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536845&aid=3252931&group_id=73133

[wxhaskell-devel] using wxHaskell with built-in wxWidgets on MacOS X

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

Hi Jeremy, hi everyone,

I notice that if I stupidly delete this chunk of the wxc layer, I can
run wxHaskell off the wxWidgets 2.8 that ships with MacOS X (Leopard).
I imagine that this has a negative side effect relating to event
handlers, but my own program seems to work fine.

Without it, I get this warning/error when I launch my program
  assert "m_dynamicEvents" failed in SearchDynamicEventTable():
plus an annoying dialog box that I can seemingly dismiss to no
ill effect.

Do you have any idea what's going on here?  I wonder if there is a way
to divorce this bit of code from wxcore and maybe supply it as extra
functionality in a separate package?

If it turns out to be harmless, that'd be really great because it means
that wxHaskell becomes *painless* to install on Mac.

Thanks!

PS. I'm not sending it as a proper darcs patch because it's really just
for comment... surely there is a "right" way to get the same sort of
result?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:ko...@ja... (Jabber or Google Talk only)

Re: [wxhaskell-devel] Source code?

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

It is the correct location...

Unfortunately, code.haskell.org was attacked recently, and the server needed
rebuilding. I need to upload wxHaskell again, and I haven't gotten around to
it (to be honest, I hadn't thought about this as a consequence of the
attack).

Will be fixed in the next day or so.

Regards
Jeremy

On 7 March 2011 22:14, <mac...@gm...> wrote:

> Where is the official source code repository for wxHaskell? The
> details in http://www.haskell.org/haskellwiki/WxHaskell/Development
> are incorrect.
>
> Thanks,
> Maciek
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>