wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

[S D S. <do...@uu...>]

On Mar 7, 2012, at 15:38 , Eric Kow wrote:

> Sorry, just one more follow-up.
> 
> 4. I've published my branch at http://darcsden.com/kowey/wxhaskell-osx64 (in the process I've renamed the two WIP patches and simplified the build to only look for wxWidgets 2.9)

We have spent a couple of hours now, patching, editing, trying to update etc.

1) We updated Alessandro's brew file to install wxmac2.9.3
2) All cabal files for wx say they only work for 2.8
3) We have added the changes needed for 7.4 (array, Eq, Show etc)
4) When trying to configure wxcore we get:

cabal configure --extra-lib-dirs=/usr/local/lib


generated 1461 methods for 114 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs
generated 2326 methods for 123 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClasses.hs
generated 3787 total methods for 237 total classes.
ok.
Configuring wxcore-0.13.1.1...
setup: Missing dependencies on foreign libraries:
* Missing C libraries: wx_baseu-2.9, wx_baseu_net-2.9, wx_baseu_xml-2.9,
wx_osx_cocoau_core-2.9, wx_osx_cocoau_adv-2.9, wx_osx_cocoau_qa-2.9,
wx_osx_cocoau_html-2.9, wx_osx_cocoau_webview-2.9, wx_osx_cocoau_xrc-2.9
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
dyn-81-83:wxcore doaitse$ 

The directory /usr/local/lib contains versions of these files with their names prefixed by "lib".

5) We tried to edit Setup.hs in order to prefix the files with this "lib", leading to a similar error message;

Configuring wxcore-0.13.1.1...
setup: Missing dependencies on foreign libraries:
* Missing C libraries: libwx_baseu-2.9, libwx_baseu_net-2.9,
libwx_baseu_xml-2.9, libwx_osx_cocoau_core-2.9, libwx_osx_cocoau_adv-2.9,
libwx_osx_cocoau_qa-2.9, libwx_osx_cocoau_html-2.9,
libwx_osx_cocoau_webview-2.9, libwx_osx_cocoau_xrc-2.9
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.


How to proceed from here? 

  Doaitse



> 
> Note that this work is very far behind Dave and Jeremy's efforts.  I'm hoping it'll eventually be obsolete in some future when we've merged everything we need to merge.
> 
> Thanks,
> 
> Eric
> 
> On 7 Mar 2012, at 13:31, Eric Kow wrote:
>> 1. I noticed this piece of text from the wxWidgets wiki [wxWidgets]:
>> 
>> If you want 64-bit wxWidgets on OS X you'll need 2.9+ and configure -with-osx_cocoa - see below; but remember that 2.9 is not an official, stable release and wxOSX/Cocoa is not yet complete.
>> 
>> This means that Lion users (and Snow Leopard with 64 bit GHC) will *have* to use the Cocoa build after all, no choice about it.  I'd been using it pretty much for the heck of it, but it turns out to have been a fortunate choice.
>> 
>> 2. Doaitse, I'm sorry, it seems your cry for help last October happened before people started trying to use wxHaskell on Lion.  Did you see this recent thread with hopefully more of a guide?
>> 
>> 3. Otherwise, have not yet had a chance to poke around and see if there is a way to make things work with just one of Jeremy's or Dave's branches.  So will be using the patch bundle I mentioned in this email thread until then.  
> 
> -- 
> Eric Kow <http://erickow.com>
> 

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

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

Sorry, just one more follow-up.

4. I've published my branch at http://darcsden.com/kowey/wxhaskell-osx64 (in the process I've renamed the two WIP patches and simplified the build to only look for wxWidgets 2.9)

Note that this work is very far behind Dave and Jeremy's efforts.  I'm hoping it'll eventually be obsolete in some future when we've merged everything we need to merge.

Thanks,

Eric
 
On 7 Mar 2012, at 13:31, Eric Kow wrote:
> 1. I noticed this piece of text from the wxWidgets wiki [wxWidgets]:
> 
> If you want 64-bit wxWidgets on OS X you'll need 2.9+ and configure -with-osx_cocoa - see below; but remember that 2.9 is not an official, stable release and wxOSX/Cocoa is not yet complete.
> 
> This means that Lion users (and Snow Leopard with 64 bit GHC) will *have* to use the Cocoa build after all, no choice about it.  I'd been using it pretty much for the heck of it, but it turns out to have been a fortunate choice.
> 
> 2. Doaitse, I'm sorry, it seems your cry for help last October happened before people started trying to use wxHaskell on Lion.  Did you see this recent thread with hopefully more of a guide?
> 
> 3. Otherwise, have not yet had a chance to poke around and see if there is a way to make things work with just one of Jeremy's or Dave's branches.  So will be using the patch bundle I mentioned in this email thread until then.  

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

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

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

Hi all,

Just a couple of minor follow-ups on the issue of getting wxHaskell to work on MacOS X Lion

1. I noticed this piece of text from the wxWidgets wiki [wxWidgets]:

If you want 64-bit wxWidgets on OS X you'll need 2.9+ and configure -with-osx_cocoa - see below; but remember that 2.9 is not an official, stable release and wxOSX/Cocoa is not yet complete.

This means that Lion users (and Snow Leopard with 64 bit GHC) will *have* to use the Cocoa build after all, no choice about it.  I'd been using it pretty much for the heck of it, but it turns out to have been a fortunate choice.

2. Doaitse, I'm sorry, it seems your cry for help last October happened before people started trying to use wxHaskell on Lion.  Did you see this recent thread with hopefully more of a guide?

3. Otherwise, have not yet had a chance to poke around and see if there is a way to make things work with just one of Jeremy's or Dave's branches.  So will be using the patch bundle I mentioned in this email thread until then.  

[wxWidgets]: http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard

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

Re: [wxhaskell-users] Creating an new attribute

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

Hi,

On 28 February 2012 03:28, Alexander McPhail <
has...@gm...> wrote:

> Hi,
>
> Using GTK, the following works
>
> <code>
>
> -- | create a new 'Figure' plot
> --     click on the window to save
> plotNew :: FigureHandle -> IO DrawingArea
> plotNew f = do
>    canvas <- drawingAreaNew
>
>    set canvas [maybeFigure := (Just f)]
>
>    return canvas
>
>
> -----------------------------------------------------------------------------
>
> -- | the figure attribute
> figure :: Attr DrawingArea FigureState
> figure = newAttr getFigure setFigure
>    where getFigure o = do
>                        Just f <- get o maybeFigure
>                        readMVar f
>          setFigure o f = set o [maybeFigure :~> (\(Just h) -> do
>                                                               modifyMVar_
> h (\_ -> return f)
>                                                               return $
> Just h)]
>
>
> -----------------------------------------------------------------------------
>
> maybeFigure :: Attr DrawingArea (Maybe FigureHandle)
> maybeFigure = unsafePerformIO $ objectCreateAttribute
> {-# NOINLINE maybeFigure #-}
>
>
> -----------------------------------------------------------------------------
>
> </code>
>
> I am attempting to port this code to WxHaskell but can not see how to
> create a new attribute for the `FigureHandle`.
>
> This is the code I have so far
>
> type FigureHandle = MVar FigureState
>
>
> -----------------------------------------------------------------------------
> -- | create a new 'Figure' plot
> --     click on the window to save
> plot ::  Frame () -> FigureHandle -> IO (Panel ())
> plot fr f = do
>   p <- panel fr [figure := f]
>   set p [on paint := paintFigure p]
>   return p
>
> paintFigure :: Panel () -> DC a -> Rect -> IO ()
>
> -- | the figure attribute
> figure :: Attr (Panel a) FigureHandle
> figure = newAttr "figure" getFigure setFigure
>    where getFigure o = do
>            readMVar figureHandle
>          setFigure o f = do
>            modifyMVar_ figureHandle (\_ -> return f)
>

You may find this entry from my blog helpful:
http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/

I think you cannot create an attribute for FigureHandle. Attributes in
wxHaskell are typed on the control to which they apply, for example (taken
from the blog) if you have a DiffViewer control, then to create a diffFiles
attribute which sets the files to be compared has the type signature below

> diffFiles :: Attr (DiffViewer a) (FilePath, FilePath)
> diffFiles = newAttr "diffFiles" dvGetFiles dvSetFiles
>     where
>     dvGetFiles win = {- Code follows... -}
>     dvSetFiles win (txt1, txt2) = {- Code follows -}

You can just as easily create a new attribute for an existing control. In
this case, I think that what you need is much closer to the code you have
for GTK than what you have shown for wxHaskell.

Hope this helps - I don't have a Gtk2Hs install to let me check they types
of your working code, I'm afraid, so there is a bit of guesswork on my side.

Best regards
Jeremy

[wxhaskell-users] Creating an new attribute

[Alexander M. <has...@gm...>]

Hi,

Using GTK, the following works

<code>

-- | create a new 'Figure' plot
--     click on the window to save
plotNew :: FigureHandle -> IO DrawingArea
plotNew f = do
   canvas <- drawingAreaNew

   set canvas [maybeFigure := (Just f)]

   return canvas

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

-- | the figure attribute
figure :: Attr DrawingArea FigureState
figure = newAttr getFigure setFigure
   where getFigure o = do
                       Just f <- get o maybeFigure
                       readMVar f
         setFigure o f = set o [maybeFigure :~> (\(Just h) -> do
                                                              modifyMVar_ h
(\_ -> return f)
                                                              return $ Just
h)]

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

maybeFigure :: Attr DrawingArea (Maybe FigureHandle)
maybeFigure = unsafePerformIO $ objectCreateAttribute
{-# NOINLINE maybeFigure #-}

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

</code>

I am attempting to port this code to WxHaskell but can not see how to
create a new attribute for the `FigureHandle`.

This is the code I have so far

type FigureHandle = MVar FigureState

-----------------------------------------------------------------------------
-- | create a new 'Figure' plot
--     click on the window to save
plot ::  Frame () -> FigureHandle -> IO (Panel ())
plot fr f = do
  p <- panel fr [figure := f]
  set p [on paint := paintFigure p]
  return p

paintFigure :: Panel () -> DC a -> Rect -> IO ()

-- | the figure attribute
figure :: Attr (Panel a) FigureHandle
figure = newAttr "figure" getFigure setFigure
   where getFigure o = do
           readMVar figureHandle
         setFigure o f = do
           modifyMVar_ figureHandle (\_ -> return f)

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

I looked in the CustomControl.hs example, which uses a pre-existing
attribute and does not create a new one in the way that the call to
`objectCreateAttribute` does with GTK.

Thanks,

Vivian


DISCLAIMER

This transmission contains information that may be confidential. It is
intended for the named addressee only. Unless you are the named addressee
you may not copy or use it or disclose it to anyone else.

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

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

On Mon, 27 Feb 2012, Eric Kow wrote:

> On 27 Feb 2012, at 15:38, Eric Kow wrote:
>
>> darcs get --lazy http://code.haskell.org/wxhaskell the-patch-you-downloaded.dpatch
>> cd wxhaskell
>> darcs apply -i ~/foo/the-patch-you-downloaded.dpatch
>
> Oops, that's darcs get --lazy <REPO> --context <PATCH>
>
> The idea is that darcs will then grab <REPO> and then unapply patches until it's wound its way back to the context that the patch was expecting.  This way you avoid thinking about merging or conflicts.

Btw. I hope you do not have problems with latest GHC-7.4.1. I did some 
patches to wxcore-0.12.1.7 in order to let wxhaskell work with GHC-7.4.1. 
Where shall I send them, since wxhaskell moved to wxWidgets-3.0?

I have attached a diff.

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

[Sarah B. <sbr...@gm...>]

Hi,

On Mon, Feb 27, 2012 at 4:42 PM, Eric Kow <eri...@gm...> wrote:
>
>> darcs get --lazy http://code.haskell.org/wxhaskell the-patch-you-downloaded.dpatch
>> cd wxhaskell
>> darcs apply -i ~/foo/the-patch-you-downloaded.dpatch
>

Thank you very much, with this process it appears to work, although
there are some slight issues with usage. I'll be testing it out a bit
before writing an updated guide on the wiki.

Thanks again.

-- Sarah

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

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

On 27 Feb 2012, at 15:38, Eric Kow wrote:

> darcs get --lazy http://code.haskell.org/wxhaskell the-patch-you-downloaded.dpatch
> cd wxhaskell
> darcs apply -i ~/foo/the-patch-you-downloaded.dpatch
> 

Oops, that's darcs get --lazy <REPO> --context <PATCH>

The idea is that darcs will then grab <REPO> and then unapply patches until it's wound its way back to the context that the patch was expecting.  This way you avoid thinking about merging or conflicts.


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

Re: [wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

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

Sarah,

The good news is that it *can* be done.  I know because I'm on Lion, and I'm using wxHaskell.

On 25 Feb 2012, at 14:58, Sarah Brofeldt wrote:
> I've been trying frantically to get a working setup of wxHaskell and
> wxWidgets on my Mac recently, but to no avail. I was wondering if
> anyone knows how exactly to go about it. I've tried just about every
> combination of old and new versions of wxWidgets from homebrew as well
> as older wxcore releases. How do you do it?


The bad news is that it may still involve manually applying some patches (I'm not up to speed about the latest state of wxHaskell) and also installing wxWidgets by hand.

Your two challenges are to install the right wxWidgets version with the right set of flags (you want Unicode, for starters), and then to get a version of wxhaskell that works with it.  I'm using wxWidgets 2.9, for what it's worth

If you use Homebrew, I have a formula for a wxmac2.9 by Alessandro Vermeulen (attached)

[wxhaskell-users] Working guide for wxWidgets and wxHaskell on Mac OS X Lion 64 bit

[Sarah B. <sbr...@gm...>]

Hello everyone,

I've been trying frantically to get a working setup of wxHaskell and
wxWidgets on my Mac recently, but to no avail. I was wondering if
anyone knows how exactly to go about it. I've tried just about every
combination of old and new versions of wxWidgets from homebrew as well
as older wxcore releases. How do you do it?

-- Sarah

Re: [wxhaskell-users] [wxhaskell-devel] The future of wxC

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

On 25 January 2012 15:19, Dave Tapley <duk...@gm...> wrote:

> On 16 January 2012 00:46, Eric Kow <eri...@gm...> wrote:
>
>>
>> I was going to post on your blog, but you beat me to mentioning it. So
>> better hear it from me, you should totally use GitHub for wxC. Plus it
>> would be a chance to work with darcs-bridge maybe.
>>
>>
>>    1. Eric will probably kill me for saying this, but I think GitHub is
>>       probably the right place, possibly keeping Sourceforge as the project
>>       website and distribution point (I personally don't much like git, but it
>>       has mindshare, and probably makes more sense than Darcs for a non-Haskell
>>       project - plus my experience with patch-tag and darcsden has been that
>>       'getting going' on a Windows machine is far from trivial). I could be
>>       persuaded to change my mind on this one, but probably only if one of the
>>       Darcs hosts can get the experience 'right' on Windows clients.
>>       2. Keep the Cabal-based build system to start with, until there is
>>       clear evidence of non-Haskell contributions.
>>    1. If wxC turns out to have legs, the main areas to attack should be:
>>       1. Move to bakefile based build.
>>       2. Automated generation of the binding.
>>
>>
>>
> If I may weight in..
>
> I like the idea of moving wxC to a separate project, to at least open it
> up to other communities, and I'd be happy to have it on GitHub, if that's
> the consensus.
> What ever decision we make, do we want to hold off the move on to
> code.haskell.org until we've made a decision?
> Actually, it might be easier to get moved across in our current state, and
> then move out wxC afterwards?
>

I tend to favour moving to code.haskell.org first so that it remains easy
for Haskellers to work on wxHaskell using only Cabal.

I have been thinking along the lines of the cabal version of wxC becoming a
stub which contains pre-compiled wxC libraries and headers and installs
them for you. I think it's important that 'cabal install wx' continues to
work for Haskell users.

For that reasson, I'd rather move everything to c.h.o ASAP.


> R.e. Point 1.2. In the list above, I've been keeping half an eye on this
> -cafe thread, which seems to be getting more attention than I had
> anticipated:
> http://www.mail-archive.com/has...@ha.../msg96678.html
> I may be getting ahead of myself..
>

Me too :-)

However, I also  generated Doxygen XML output for wxWidgets (which the
wxWidgets people seem to favour), and it looks quite nice. Here's a sample
- it's the XML generated for the start of class wxPropertyGrid and the
method virtual void wxPropertyGrid::DoShowPropertyError(wxPGProperty
*property, const wxString &amp;msg);

  <compounddef id="classwx_property_grid" kind="class" prot="public">
    <compoundname>wxPropertyGrid</compoundname>
    <basecompoundref refid="classwx_control" prot="public"
virt="non-virtual">wxControl</basecompoundref>
    <basecompoundref refid="classwx_property_grid_interface" prot="public"
virt="non-virtual">wxPropertyGridInterface</basecompoundref>
    <includes local="no">wx/propgrid/propgrid.h</includes>
      <sectiondef kind="user-defined">
      <header>wxPropertyGrid customization</header>
      <description><para>Reimplement these member functions in derived
class for better control over <ref refid="classwx_property_grid"
kindref="compound">wxPropertyGrid</ref> behaviour. </para></description>
      <memberdef kind="function"
id="classwx_property_grid_1a6eff1187beba43109be7a12194b0bf2b" prot="public"
static="no" const="no" explicit="no" inline="no" virt="virtual">
        <type>void</type>
        <definition>virtual void
wxPropertyGrid::DoShowPropertyError</definition>
        <argsstring>(wxPGProperty *property, const wxString
&amp;msg)</argsstring>
        <name>DoShowPropertyError</name>
        <param>
          <type><ref refid="classwx_p_g_property"
kindref="compound">wxPGProperty</ref> *</type>
          <declname>property</declname>
        </param>
        <param>
          <type>const <ref refid="classwx_string"
kindref="compound">wxString</ref> &amp;</type>
          <declname>msg</declname>
        </param>
        <briefdescription>
<para>Override in derived class to display error messages in custom manner
(these message usually only result from validation failure). </para>
</briefdescription>
        <detaileddescription>
<para><simplesect kind="remark"><para>If you implement this, then you also
need to implement <ref
refid="classwx_property_grid_1af170d02811ab8eed906963de693b79aa"
kindref="member">DoHidePropertyError()</ref> - possibly to do nothing, if
error does not need hiding (e.g. it was logged or shown in a message
box).</para></simplesect>
<simplesect kind="see"><para><ref
refid="classwx_property_grid_1af170d02811ab8eed906963de693b79aa"
kindref="member">DoHidePropertyError()</ref> </para></simplesect>
</para>        </detaileddescription>
        <inbodydescription>
        </inbodydescription>
        <location
file="D:/Builds/wxWidgets-2.9.3/interface/wx/propgrid/propgrid.h"
line="1108"/>
      </memberdef>
Notice that all of the documentation is retained (which would be very nice
for documenting wxcore), and that function signature is quite easy to
extract.

Jeremy

Re: [wxhaskell-users] [wxhaskell-devel] The future of wxC

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

On 16 January 2012 00:46, Eric Kow <eri...@gm...> wrote:

>
> I was going to post on your blog, but you beat me to mentioning it. So
> better hear it from me, you should totally use GitHub for wxC. Plus it
> would be a chance to work with darcs-bridge maybe.
>
>
>    1. Eric will probably kill me for saying this, but I think GitHub is
>       probably the right place, possibly keeping Sourceforge as the project
>       website and distribution point (I personally don't much like git, but it
>       has mindshare, and probably makes more sense than Darcs for a non-Haskell
>       project - plus my experience with patch-tag and darcsden has been that
>       'getting going' on a Windows machine is far from trivial). I could be
>       persuaded to change my mind on this one, but probably only if one of the
>       Darcs hosts can get the experience 'right' on Windows clients.
>       2. Keep the Cabal-based build system to start with, until there is
>       clear evidence of non-Haskell contributions.
>    1. If wxC turns out to have legs, the main areas to attack should be:
>       1. Move to bakefile based build.
>       2. Automated generation of the binding.
>
>
>
If I may weight in..

I like the idea of moving wxC to a separate project, to at least open it up
to other communities, and I'd be happy to have it on GitHub, if that's the
consensus.
What ever decision we make, do we want to hold off the move on to
code.haskell.org until we've made a decision?
Actually, it might be easier to get moved across in our current state, and
then move out wxC afterwards?


R.e. Point 1.2. In the list above, I've been keeping half an eye on this
-cafe thread, which seems to be getting more attention than I had
anticipated:
http://www.mail-archive.com/has...@ha.../msg96678.html
I may be getting ahead of myself..



>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

Re: [wxhaskell-users] ANN: wxHaskell 0.13.2

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

On 13 January 2012 17:33, Peter Simons <si...@cr...> wrote:
> Hi Jeremy,
>
>  > To solve the particular issue you have, you need '--enable-mediactrl'
>  > in your configure script for wxWidgets.
>
> you were right, that did the trick. I also had to add 'gstreamer' as a
> build input. Without that package the build wxGTK failed to produce the
> media sublibrary -- but it failed silently and kept on building
> regardless. Duh!
>
> Anyway, NixOS now has the latest version of wxHaskell. Thank you for
> your efforts.
>
> I noticed, by the way, that wxHaskell doesn't compile with GHC 7.2.2:
>
>  | Building wx-0.13.2...
>  | Preprocessing library wx-0.13.2...
>  | [ 1 of 16] Compiling Graphics.UI.WX.Types ( src/Graphics/UI/WX/Types.hs, dist/build/Graphics/UI/WX/Types.o )
>  | [ 2 of 16] Compiling Graphics.UI.WX.Attributes ( src/Graphics/UI/WX/Attributes.hs, dist/build/Graphics/UI/WX/Attributes.o )
>  | [ 3 of 16] Compiling Graphics.UI.WX.Layout ( src/Graphics/UI/WX/Layout.hs, dist/build/Graphics/UI/WX/Layout.o )
>  | [ 4 of 16] Compiling Graphics.UI.WX.Classes ( src/Graphics/UI/WX/Classes.hs, dist/build/Graphics/UI/WX/Classes.o )
>  | [ 5 of 16] Compiling Graphics.UI.WX.Media ( src/Graphics/UI/WX/Media.hs, dist/build/Graphics/UI/WX/Media.o )
>  |
>  | src/Graphics/UI/WX/Media.hs:48:10:
>  |     Illegal instance declaration for `Sized (Bitmap a)'
>  |       (All instance types must be of the form (T a1 ... an)
>  |        where a1 ... an are *distinct type variables*,
>  |        and each type variable appears at most once in the instance head.
>  |        Use -XFlexibleInstances if you want to disable this.)
>  |     In the instance declaration for `Sized (Bitmap a)'
>  |
>  | src/Graphics/UI/WX/Media.hs:69:10:
>  |     Illegal instance declaration for `Sized (Image a)'
>  |       (All instance types must be of the form (T a1 ... an)
>  |        where a1 ... an are *distinct type variables*,
>  |        and each type variable appears at most once in the instance head.
>  |        Use -XFlexibleInstances if you want to disable this.)
>  |     In the instance declaration for `Sized (Image a)'
>  |
>  | src/Graphics/UI/WX/Media.hs:93:10:
>  |     Illegal instance declaration for `Media (Sound a)'
>  |       (All instance types must be of the form (T a1 ... an)
>  |        where a1 ... an are *distinct type variables*,
>  |        and each type variable appears at most once in the instance head.
>  |        Use -XFlexibleInstances if you want to disable this.)
>  |     In the instance declaration for `Media (Sound a)'
>  | builder for `/nix/store/r486ymv1ci2zdlfh282a7x4fk4cnffb7-haskell-wx-ghc7.2.2-0.13.2.drv' failed with exit code 1

Could this be as simple as using FlexibleInstances?
Perhaps someone else has a better grasp of the implications of
FlexibleInstances?

>
> Take care,
> Peter
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell layout tips/tricks

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

Eric Kow wrote:
> It's been a while since I've written a wxHaskell GUI from scratch, so
> I got a good opportunity to (re)experience the sort of struggle from
> years back :-)
> 
> I can't claim to be an expert, but here are some (potentially
> incorrect!) notes from last night's fighting with wxHaskell
> 
> http://www.haskell.org/haskellwiki/WxHaskell/Layout
> 
> Along with the code sample and screenshot to go with it.

(You may want to link to the code from the wiki page?)

> Now maybe I'll have a chance to see if reactive banana will make life
> any easier hooking it up to actual moving parts.

I'd like to encourage you to bring up any banana-related trouble with me 
or StackOverflow.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: [wxhaskell-users] [wxhaskell-devel] The future of wxC

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

I was going to post on your blog, but you beat me to mentioning it. So better hear it from me, you should totally use GitHub for wxC. Plus it would be a chance to work with darcs-bridge maybe.
> Eric will probably kill me for saying this, but I think GitHub is probably the right place, possibly keeping Sourceforge as the project website and distribution point (I personally don't much like git, but it has mindshare, and probably makes more sense than Darcs for a non-Haskell project - plus my experience with patch-tag and darcsden has been that 'getting going' on a Windows machine is far from trivial). I could be persuaded to change my mind on this one, but probably only if one of the Darcs hosts can get the experience 'right' on Windows clients.
> Keep the Cabal-based build system to start with, until there is clear evidence of non-Haskell contributions.
> If wxC turns out to have legs, the main areas to attack should be:
> Move to bakefile based build.
> Automated generation of the binding.

[wxhaskell-users] The future of wxC

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

Hi lists,

There have been a number of discussions over the past week or so on the
future of wxC. I'm not as good as Dave at cross-referencing everything, but
at the very least we have:

http://www.mail-archive.com/wxh...@li.../msg01050.html
http://www.mail-archive.com/wxh...@li.../msg00735.html
http://www.mail-archive.com/wxh...@li.../msg00736.html
http://wewantarock.wordpress.com/2012/01/12/who-is-my-community/
http://www.reddit.com/r/programming/comments/oek2t/any_interest_in_a_c_binding_to_wxwidgets_from/

What I have tried to do is to raise the option of making wxC a separate
project to other groups (Dave and Eric have reached out to a couple of
other comunities as well), and see whether there is much interest out there.

The most concrete interest has come from the D community, which lacks a
good GUI binding, and which (it seems to me, based entirely on blog noise)
is growing pretty rapidly, with some more vague interest coming from the
wxWidgets community more generally (and granted that I have not done much
to reach out in that direction).

I must say that I am at least somewhat convinced that there is demand for
wxC 'out there', and it is therefore worth making an initial effort to make
wxC a viable option for other language communities.

With this in mind, I would like to suggest a staged approach - comments and
opinions are very welcome.


   1. The first stage is to simply get wxHaskell with 2.9.x support out of
   the door. I don't think we should change anything at this stage, other than
   that it definitely makes more sense to use wx-config-win on Windows
   platforms if we are going to work with others.
   2. The second stage is to spin wxC off as a separate project.
      1. Eric will probably kill me for saying this, but I think GitHub is
      probably the right place, possibly keeping Sourceforge as the project
      website and distribution point (I personally don't much like git, but it
      has mindshare, and probably makes more sense than Darcs for a non-Haskell
      project - plus my experience with patch-tag and darcsden has been that
      'getting going' on a Windows machine is far from trivial). I could be
      persuaded to change my mind on this one, but probably only if one of the
      Darcs hosts can get the experience 'right' on Windows clients.
      2. Keep the Cabal-based build system to start with, until there is
      clear evidence of non-Haskell contributions.
   3. If wxC turns out to have legs, the main areas to attack should be:
      1. Move to bakefile based build.
      2. Automated generation of the binding.

I must say that comments to the blog posting in particular were really
quite encouraging, but I don't waht to put the cart before the horse. In
particular, Gour (an ex-Haskeller) and Andrej seem keen to try out what we
have already with D, which would make an excellent proof of concept.

Once we've had some discussion (say around the middle of the week), I'd
like to blog on what we propose to do, and start to reach out a bit further
to other groups.

Regards
Jeremy

Re: [wxhaskell-users] wxHaskell layout tips/tricks

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

On 15 Jan 2012, at 14:12, Eric Kow wrote:
> 
> http://www.haskell.org/haskellwiki/WxHaskell/Layout

(the first section is work by Brett Giles (thanks for creating a page about this), the rest is stuff I've tacked on)

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

[wxhaskell-users] wxHaskell layout tips/tricks

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

Hi all,

It's been a while since I've written a wxHaskell GUI from scratch, so I got a good opportunity to (re)experience the sort of struggle from years back :-)

I can't claim to be an expert, but here are some (potentially incorrect!) notes from last night's fighting with wxHaskell

http://www.haskell.org/haskellwiki/WxHaskell/Layout

Along with the code sample and screenshot to go with it.

Now maybe I'll have a chance to see if reactive banana will make life any easier hooking it up to actual moving parts.

Re: [wxhaskell-users] ANN: wxHaskell 0.13.2

[Peter S. <si...@cr...>]

Hi Jeremy,

 > To solve the particular issue you have, you need '--enable-mediactrl'
 > in your configure script for wxWidgets.

you were right, that did the trick. I also had to add 'gstreamer' as a
build input. Without that package the build wxGTK failed to produce the
media sublibrary -- but it failed silently and kept on building
regardless. Duh!

Anyway, NixOS now has the latest version of wxHaskell. Thank you for
your efforts.

I noticed, by the way, that wxHaskell doesn't compile with GHC 7.2.2:

 | Building wx-0.13.2...
 | Preprocessing library wx-0.13.2...
 | [ 1 of 16] Compiling Graphics.UI.WX.Types ( src/Graphics/UI/WX/Types.hs, dist/build/Graphics/UI/WX/Types.o )
 | [ 2 of 16] Compiling Graphics.UI.WX.Attributes ( src/Graphics/UI/WX/Attributes.hs, dist/build/Graphics/UI/WX/Attributes.o )
 | [ 3 of 16] Compiling Graphics.UI.WX.Layout ( src/Graphics/UI/WX/Layout.hs, dist/build/Graphics/UI/WX/Layout.o )
 | [ 4 of 16] Compiling Graphics.UI.WX.Classes ( src/Graphics/UI/WX/Classes.hs, dist/build/Graphics/UI/WX/Classes.o )
 | [ 5 of 16] Compiling Graphics.UI.WX.Media ( src/Graphics/UI/WX/Media.hs, dist/build/Graphics/UI/WX/Media.o )
 |
 | src/Graphics/UI/WX/Media.hs:48:10:
 |     Illegal instance declaration for `Sized (Bitmap a)'
 |       (All instance types must be of the form (T a1 ... an)
 |        where a1 ... an are *distinct type variables*,
 |        and each type variable appears at most once in the instance head.
 |        Use -XFlexibleInstances if you want to disable this.)
 |     In the instance declaration for `Sized (Bitmap a)'
 |
 | src/Graphics/UI/WX/Media.hs:69:10:
 |     Illegal instance declaration for `Sized (Image a)'
 |       (All instance types must be of the form (T a1 ... an)
 |        where a1 ... an are *distinct type variables*,
 |        and each type variable appears at most once in the instance head.
 |        Use -XFlexibleInstances if you want to disable this.)
 |     In the instance declaration for `Sized (Image a)'
 |
 | src/Graphics/UI/WX/Media.hs:93:10:
 |     Illegal instance declaration for `Media (Sound a)'
 |       (All instance types must be of the form (T a1 ... an)
 |        where a1 ... an are *distinct type variables*,
 |        and each type variable appears at most once in the instance head.
 |        Use -XFlexibleInstances if you want to disable this.)
 |     In the instance declaration for `Media (Sound a)'
 | builder for `/nix/store/r486ymv1ci2zdlfh282a7x4fk4cnffb7-haskell-wx-ghc7.2.2-0.13.2.drv' failed with exit code 1

Take care,
Peter

Re: [wxhaskell-users] [wxhaskell-devel] ANN: wxHaskell 0.13.2

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

On 9 January 2012 22:19, Jeremy O'Donoghue <jer...@gm...>wrote:

> On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote:
>
>> On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote:
>>
>>> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:
>>>
>>>> 2012/1/6 shelarcy <she...@gm...>
>>>>
>>>
>>> Needless to say, I have immediately hit the wx-config roadblock, since I
>>> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
>>> knows about debug builds.
>>>
>>
>> Welcome to the party :)
>> Just for the sake of clarity, I feel obliged to question your use of the
>> words "release" and "debug"; are you aware of the "Debug Build Changes in
>> wx3"?
>> Here's the news:
>> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
>> (seeing the date of the post made me realise just how far behind we are,
>> and also how slow the wxWidgets release cycles are!)
>>
>>
> I wasn't aware of the blog posting, but I did realise that there were
> changes in this area - some of this is covered in the install instructions.
> Strictly I built with:
>
> BUILD=release
> DEBUG_INFO=default
> DEBUG_FLAG=1
>

Yikes, these flags are very (imho) counter-intuitive.

Referencing a thread I have going:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/JYd4ydh6v-IJ
Vadim states that: "DEBUG_FLAG is correctly set to 1 indicating that debug
code is not disabled (which is the default)".
So I'm substituting  "not disable" with "enabled" and reading it as: a
release build with debugging enabled, or as you put it:

This means I keep the asserts, which seemed like an appropriate
> configuration for wxHaskell development.
>

What I'm not sure about here is whether the "BUILD" flag is superfluous
under any GCC build, or just non-Windows GCC builds. A question which I'm
asking about here:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/nfUuz_cg-HUJ

If the answer to my question there is "under Windows using MSVC", and if we
accept that wxHaskell isn't going to support an MSVC build of wxWidgets
(which I get the impression is the case); then I suppose that wxC can be
completely agnostic to all the (non-libs) wxWidgets build type information
(namely: release/debug, debugging flag on/off).

Thoughts?


>
>>
>> That has manifested itself in this known issue with wx-config-win:
>> http://code.google.com/p/wx-config-win/issues/detail?id=21
>>
>> Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
>> I dutifully downloaded the free version of Visual C++ 2010 express,
>> loaded the wxWidgets 2.9.3 project, built, and ran some sample code.
>> However when I tried to use wx-config-win I realised that it required a
>> "build.cfg" file, which isn't generated when you build with VC++ (I suppose
>> because VC++ manages all the build settings itself, and so doesn't need to
>> export anything). Without this one is unable to install wxHaskell.
>>
>
> I built with gcc. I have played with VC++ in the past, because the build
> 'just works' but it was really too painful to sort out the configuration.
>

Hazaa, I'm going to say it again:
*wxHaskell doesn't support an MSVC build of wxWidgets*

Is that the sort of message we can put out?


>
>> I turned to the wiki and discovered this:
>> http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)
>>
>> Using it as a guide (note that one can't use wxPack because there are no
>> wxPack releases for the development (2.9.x) releases of wxWidgets) I was
>> (almost) able to cabal install wxHaskell from my darcsden branch (it failed
>> because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
>> of time).
>>
>>
>>> I am leaning towards doing something with Eric's wx-config. There are a
>>> couple of reasons for this:
>>>
>>>    - It keeps us in control of our own destiny;
>>>    - Haskell is a *much* more pleasant implementation language for a
>>>    utility which mainly does text processing than C++.
>>>
>>> Does the group have an opinion on this? My feeling is that since the
>>> last commit to wx-config-win was in 2006, it may be a while before fixes
>>> come along, and even then, we will probably need to write the patches.
>>>
>> Ah, well, yes..
>> Firstly the pro-(wx-config-win) items:
>> * I contacted the owner of wx-config-win and he made me an owner of the
>> Google code project, so we're 'in charge' now.
>> * I got a small discussion going on its existence in #wxwidgets on
>> freenode. The consensus is that, because /most/ people use Visual Studio
>> (in some flavour) to develop with wxWidgets in Windows, there simply wasn't
>> the need to maintain wx-config-win. As a result it was never stable enough
>> to merit merging in to the wxWidgets code base. By comparison the wx-config
>> we know and love on Linux systems (and, I presume, OS X?) is essential and
>> so well maintained:
>>
>> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
>> (I didn't realise until recently that it is just a shell script, copied
>> in to your install dir and symlinked into your PATH).
>>
>
> I did know that wx-config is just a shell script. I'm not so surprised
> that most wxWidgets developers on Windows use VS. It's a really nce
> development environment. I actually think they advertise support for too
> many build options when in reality only a few of them get any serious use.
>
> I was actually planning on looking carefully at wx-config while updating
> Eric's Haskell wx-config :-)
>

I did actually miss another 'pro' here:
I think it's fair to say that wx-config-win is more 'complete' than Eric's
Haskell implementation, insomuch as all that's required to fix the
"wx-config roadblock" is (I think) changing this line as per Vadim's
suggestion :
http://code.google.com/p/wx-config-win/source/browse/trunk/wx-config-win.cpp#952


>
>
>>
>> And now the cons:
>> * It is woefully out of date. There are 18 open issues (
>> http://code.google.com/p/wx-config-win/issues/list) and who knows how
>> many undiscovered bugs.
>> * As mentioned, the wxWidgets community doesn't seem desperately fussed
>> about its existence, so long as Visual Studio is around
>> * It's implementation is in need of an overhaul, as identified by the
>> previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6
>> )
>>
>
> I tend to think that you've hit on the problem with this approach. The
> wxWidgets community doesn't really care. Therefore we would be left
> maintaining a piece of C++ to support what is basically our own need.
>
>>
>> So, in summary, I'm not sure.
>> My optimist, open-source heart says we should resurrect the wx-win-config
>> project.
>> My do-it-the-right-way heart says we ditch the existing C++ source and
>> replicate the shell script (Windows PowerShell anyone?)
>> My everything-is-wonderful-with-Haskell heart says let's just roll our
>> own, no one uses wx-config-win anyway, and all it does it find a few
>> headers and libs.
>>
>>
>
> I think a port of wx-config (shell) to Haskell is probably easier than
> doing a port into PowerShell (which I've never touched...), but I take your
> point about the 'right way'.
>
> I'll nail my colours to the mast and leave things open for debate after
> that.
>
>    - My day job is C++. Thus I tend to tolerate doing it for my 'fun'
>    projects where it is needed (e.g. wrapping a C++ library), but I kind-of
>    prefer to spend my spare time writing Haskell rather than C++ ;-)
>    - While the 'community' aspect of having a wxC is superficially
>    attractive, I think history is against the idea that it is something the
>    world really needs:
>       - wxC has been moribund for years. I don't think it's been touched
>       for over 5 years. This suggests that there is not so much demand out there.
>       - wxHaskell has struggled for contributons for as long as I
>       remember. I basically became involved because I didn't want to see it
>       bit-rot.
>
>
> What I *do* believe is that there is a real demand in the Haskell
> community for a GUI with native look and feel, commercial-friendly
> licensing and ease of installation. My preference, therefore, is to move
> wxHaskell in that direction as far as possible, and to make the bar for
> becoming a developer as low as possible for Haskell developers. Basically,
> I want to enable the Haskell ecosystem, and that's why I'm a big fan of
> cabal install, despite its limitations as a generalised build system.
>
> Having said my piece, I fully understand why others may have a different
> view, and I think if there was I strong indication that other language
> communities had a serious interest in using and helping to maintain wxC, I
> would be easily persuaded in that direction. What I don't really believe is
> in 'if you build it, they will come'.
>
> I'll leave things for a couple of days to let others have their say, and
> then follow the community preference.
>

I don't know either, needs more input I think :(


>
> Best regards
> Jeremy
>

Re: [wxhaskell-users] [wxhaskell-devel] ANN: wxHaskell 0.13.2

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

On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote:

> On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:
>>
>>> 2012/1/6 shelarcy <she...@gm...>
>>>
>>
>> Needless to say, I have immediately hit the wx-config roadblock, since I
>> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
>> knows about debug builds.
>>
>
> Welcome to the party :)
> Just for the sake of clarity, I feel obliged to question your use of the
> words "release" and "debug"; are you aware of the "Debug Build Changes in
> wx3"?
> Here's the news:
> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
> (seeing the date of the post made me realise just how far behind we are,
> and also how slow the wxWidgets release cycles are!)
>
>
I wasn't aware of the blog posting, but I did realise that there were
changes in this area - some of this is covered in the install instructions.
Strictly I built with:

BUILD=release
DEBUG_INFO=default
DEBUG_FLAG=1

This means I keep the asserts, which seemed like an appropriate
configuration for wxHaskell development.


>
> That has manifested itself in this known issue with wx-config-win:
> http://code.google.com/p/wx-config-win/issues/detail?id=21
>
> Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
> I dutifully downloaded the free version of Visual C++ 2010 express, loaded
> the wxWidgets 2.9.3 project, built, and ran some sample code. However when
> I tried to use wx-config-win I realised that it required a "build.cfg"
> file, which isn't generated when you build with VC++ (I suppose because
> VC++ manages all the build settings itself, and so doesn't need to export
> anything). Without this one is unable to install wxHaskell.
>

I built with gcc. I have played with VC++ in the past, because the build
'just works' but it was really too painful to sort out the configuration.

>
> I turned to the wiki and discovered this:
> http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)
>
> Using it as a guide (note that one can't use wxPack because there are no
> wxPack releases for the development (2.9.x) releases of wxWidgets) I was
> (almost) able to cabal install wxHaskell from my darcsden branch (it failed
> because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
> of time).
>
>
>> I am leaning towards doing something with Eric's wx-config. There are a
>> couple of reasons for this:
>>
>>    - It keeps us in control of our own destiny;
>>    - Haskell is a *much* more pleasant implementation language for a
>>    utility which mainly does text processing than C++.
>>
>> Does the group have an opinion on this? My feeling is that since the last
>> commit to wx-config-win was in 2006, it may be a while before fixes come
>> along, and even then, we will probably need to write the patches.
>>
> Ah, well, yes..
> Firstly the pro-(wx-config-win) items:
> * I contacted the owner of wx-config-win and he made me an owner of the
> Google code project, so we're 'in charge' now.
> * I got a small discussion going on its existence in #wxwidgets on
> freenode. The consensus is that, because /most/ people use Visual Studio
> (in some flavour) to develop with wxWidgets in Windows, there simply wasn't
> the need to maintain wx-config-win. As a result it was never stable enough
> to merit merging in to the wxWidgets code base. By comparison the wx-config
> we know and love on Linux systems (and, I presume, OS X?) is essential and
> so well maintained:
>
> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
> (I didn't realise until recently that it is just a shell script, copied in
> to your install dir and symlinked into your PATH).
>

I did know that wx-config is just a shell script. I'm not so surprised that
most wxWidgets developers on Windows use VS. It's a really nce development
environment. I actually think they advertise support for too many build
options when in reality only a few of them get any serious use.

I was actually planning on looking carefully at wx-config while updating
Eric's Haskell wx-config :-)


>
> And now the cons:
> * It is woefully out of date. There are 18 open issues (
> http://code.google.com/p/wx-config-win/issues/list) and who knows how
> many undiscovered bugs.
> * As mentioned, the wxWidgets community doesn't seem desperately fussed
> about its existence, so long as Visual Studio is around
> * It's implementation is in need of an overhaul, as identified by the
> previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6)
>

I tend to think that you've hit on the problem with this approach. The
wxWidgets community doesn't really care. Therefore we would be left
maintaining a piece of C++ to support what is basically our own need.

>
> So, in summary, I'm not sure.
> My optimist, open-source heart says we should resurrect the wx-win-config
> project.
> My do-it-the-right-way heart says we ditch the existing C++ source and
> replicate the shell script (Windows PowerShell anyone?)
> My everything-is-wonderful-with-Haskell heart says let's just roll our
> own, no one uses wx-config-win anyway, and all it does it find a few
> headers and libs.
>
>

I think a port of wx-config (shell) to Haskell is probably easier than
doing a port into PowerShell (which I've never touched...), but I take your
point about the 'right way'.

I'll nail my colours to the mast and leave things open for debate after
that.

   - My day job is C++. Thus I tend to tolerate doing it for my 'fun'
   projects where it is needed (e.g. wrapping a C++ library), but I kind-of
   prefer to spend my spare time writing Haskell rather than C++ ;-)
   - While the 'community' aspect of having a wxC is superficially
   attractive, I think history is against the idea that it is something the
   world really needs:
      - wxC has been moribund for years. I don't think it's been touched
      for over 5 years. This suggests that there is not so much demand
out there.
      - wxHaskell has struggled for contributons for as long as I remember.
      I basically became involved because I didn't want to see it bit-rot.


What I *do* believe is that there is a real demand in the Haskell community
for a GUI with native look and feel, commercial-friendly licensing and ease
of installation. My preference, therefore, is to move wxHaskell in that
direction as far as possible, and to make the bar for becoming a developer
as low as possible for Haskell developers. Basically, I want to enable the
Haskell ecosystem, and that's why I'm a big fan of cabal install, despite
its limitations as a generalised build system.

Having said my piece, I fully understand why others may have a different
view, and I think if there was I strong indication that other language
communities had a serious interest in using and helping to maintain wxC, I
would be easily persuaded in that direction. What I don't really believe is
in 'if you build it, they will come'.

I'll leave things for a couple of days to let others have their say, and
then follow the community preference.

Best regards
Jeremy

Re: [wxhaskell-users] [wxhaskell-devel] ANN: wxHaskell 0.13.2

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

On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote:

> Hi Dave, all
> On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:
>
>> 2012/1/6 shelarcy <she...@gm...>
>>
>>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
>>> Windows environment. "cabal install" fail with wx-config-win binary,
>>>
>>
>> Can you remember how this failed, or send some output from the failure,
>> and also let us know what version of wxWidgets you have?
>> I'm hoping you say you have wx-2.9.x, in which case it could be this
>> issue:
>> http://code.google.com/p/wx-config-win/issues/detail?id=21
>>
>>  and "cabal install" success with Eric's one. If wxcore depends on
>>> wx-config package in only Windows environment, I think we should upload
>>> Eric's wx-config package, and modify wxcore to denped on wx-config
>>> package
>>> on  Windows environment for workaround.
>>>
>>> if os(windows)
>>>   Build-Depends: wx-config
>>>
>>> wx-config package isn't uploaded yet. So, I don't upload newer version,
>>> nor attach patch for fixing this problem.
>>>
>>
>> We're still making a decision on whether to continue using
>> wx-config(-win), or to adopt Eric's one.
>> I'm going to see if I can get a conversation going with the wxWidgets
>> people and then I'll send out another mail.
>>
>
> Now that the 0.13 branch looks like it is finished, I have pulled your
> development repo (so as to be up to date), and started to look at Windows
> support.
>

Excellent, I hope it's not too much of a nightmare, I played around a
little with my branch in Windows, but I'm primarily in Ubuntu.


>
> Needless to say, I have immediately hit the wx-config roadblock, since I
> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
> knows about debug builds.
>

Welcome to the party :)
Just for the sake of clarity, I feel obliged to question your use of the
words "release" and "debug"; are you aware of the "Debug Build Changes in
wx3"?
Here's the news:
http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
(seeing the date of the post made me realise just how far behind we are,
and also how slow the wxWidgets release cycles are!)

That has manifested itself in this known issue with wx-config-win:
http://code.google.com/p/wx-config-win/issues/detail?id=21

Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
I dutifully downloaded the free version of Visual C++ 2010 express, loaded
the wxWidgets 2.9.3 project, built, and ran some sample code. However when
I tried to use wx-config-win I realised that it required a "build.cfg"
file, which isn't generated when you build with VC++ (I suppose because
VC++ manages all the build settings itself, and so doesn't need to export
anything). Without this one is unable to install wxHaskell.

I turned to the wiki and discovered this:
http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)

Using it as a guide (note that one can't use wxPack because there are no
wxPack releases for the development (2.9.x) releases of wxWidgets) I was
(almost) able to cabal install wxHaskell from my darcsden branch (it failed
because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
of time).


> I am leaning towards doing something with Eric's wx-config. There are a
> couple of reasons for this:
>
>    - It keeps us in control of our own destiny;
>    - Haskell is a *much* more pleasant implementation language for a
>    utility which mainly does text processing than C++.
>
> Does the group have an opinion on this? My feeling is that since the last
> commit to wx-config-win was in 2006, it may be a while before fixes come
> along, and even then, we will probably need to write the patches.
>
Ah, well, yes..
Firstly the pro-(wx-config-win) items:
* I contacted the owner of wx-config-win and he made me an owner of the
Google code project, so we're 'in charge' now.
* I got a small discussion going on its existence in #wxwidgets on
freenode. The consensus is that, because /most/ people use Visual Studio
(in some flavour) to develop with wxWidgets in Windows, there simply wasn't
the need to maintain wx-config-win. As a result it was never stable enough
to merit merging in to the wxWidgets code base. By comparison the wx-config
we know and love on Linux systems (and, I presume, OS X?) is essential and
so well maintained:

http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
(I didn't realise until recently that it is just a shell script, copied in
to your install dir and symlinked into your PATH).

And now the cons:
* It is woefully out of date. There are 18 open issues (
http://code.google.com/p/wx-config-win/issues/list) and who knows how many
undiscovered bugs.
* As mentioned, the wxWidgets community doesn't seem desperately fussed
about its existence, so long as Visual Studio is around
* It's implementation is in need of an overhaul, as identified by the
previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6)

So, in summary, I'm not sure.
My optimist, open-source heart says we should resurrect the wx-win-config
project.
My do-it-the-right-way heart says we ditch the existing C++ source and
replicate the shell script (Windows PowerShell anyone?)
My everything-is-wonderful-with-Haskell heart says let's just roll our own,
no one uses wx-config-win anyway, and all it does it find a few headers and
libs.



> Regards
> Jeremy
>

Re: [wxhaskell-users] [wxhaskell-devel] ANN: wxHaskell 0.13.2

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

Hi Dave, all
On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:

> 2012/1/6 shelarcy <she...@gm...>
>
>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
>> Windows environment. "cabal install" fail with wx-config-win binary,
>>
>
> Can you remember how this failed, or send some output from the failure,
> and also let us know what version of wxWidgets you have?
> I'm hoping you say you have wx-2.9.x, in which case it could be this issue:
> http://code.google.com/p/wx-config-win/issues/detail?id=21
>
>  and "cabal install" success with Eric's one. If wxcore depends on
>> wx-config package in only Windows environment, I think we should upload
>> Eric's wx-config package, and modify wxcore to denped on wx-config package
>> on  Windows environment for workaround.
>>
>> if os(windows)
>>   Build-Depends: wx-config
>>
>> wx-config package isn't uploaded yet. So, I don't upload newer version,
>> nor attach patch for fixing this problem.
>>
>
> We're still making a decision on whether to continue using
> wx-config(-win), or to adopt Eric's one.
> I'm going to see if I can get a conversation going with the wxWidgets
> people and then I'll send out another mail.
>

Now that the 0.13 branch looks like it is finished, I have pulled your
development repo (so as to be up to date), and started to look at Windows
support.

Needless to say, I have immediately hit the wx-config roadblock, since I
have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
knows about debug builds.

I am leaning towards doing something with Eric's wx-config. There are a
couple of reasons for this:

   - It keeps us in control of our own destiny;
   - Haskell is a *much* more pleasant implementation language for a
   utility which mainly does text processing than C++.

Does the group have an opinion on this? My feeling is that since the last
commit to wx-config-win was in 2006, it may be a while before fixes come
along, and even then, we will probably need to write the patches.
Regards
Jeremy

Re: [wxhaskell-users] ANN: wxHaskell 0.13.2

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

Hi Peter,
On 8 January 2012 11:39, Henning Thielemann
<le...@he...>wrote:

>
> On Sat, 7 Jan 2012, Peter Simons wrote:
>
> > Hi guys,
> >
> > > I am please to announce that wxHaskell 0.13.2 has just been uploaded
> > > to Hackage.
> >
> > when I try to build the latest version on Linux/x86_64 running NixOS, I
> > get the following error at configure time:
> >
> >    Setup: Missing dependency on a foreign library:
> >    * Missing C library: wx_gtk2u_media-2.8
> >
> > I searched my hard disk for that library, and apparently my installed
> > copy of wxGTK-2.8.12 doesn't have it. There are plenty of libwx_gtk2u_*
> > libraries, but none of them is called "media".
>
> Is it the only missing header? Once when I tried to install wxhaskell I
> got a lot of missing header errors although all dev packages were
> installed. They went away when I installed 'g++'. It was a plain Haskell
> development machine before :-
>

I'm not so familiar with NixOS - I did my testing on an Ubuntu 10.4 VMWare
image. However, I have built wxWidgets more often than I care to think
about.

To solve the particular issue you have, you need '--enable-mediactrl' in
your configure script for wxWidgets.

I think you probably want something like the following if you want all of
the wxHaskell features:

./configure --enable-unicode --enable-html --enable-xrc --enable-aui
--enable-stc --enable-mediactrl --enable-richtext --with-gtk=2 --with-opengl

Hope this helps.

Best regards
Jeremy

Re: [wxhaskell-users] ANN: wxHaskell 0.13.2

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

On 5 January 2012 17:44, Jeremy O'Donoghue <jer...@gm...>wrote:
>
>
> The source repository at code.haskell.org has not yet been updated with
> the patches. This will happen in the next day or so.
>
>

The source repository at code.haskell.org has now been updated with
wxHaskell 0.13.2 plus the two patches (add IOExtra to wxdirect and remove
old-time from wxcore) from Shelarcy.

I suggest a period of one more week (i.e. until 15th Jan 2012) for any
further issues or fixes on the 0.13.2 series. After that, Dave, Eric and
others will start to upload the changes needed to support wxWidgets 2.9.x.

These changes will not work against wxWidgets 2.8.x installations, and are
pretty significant in places. Please expect the main repo to unstable for a
while after next Sunday.

Best regards
Jeremy