wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] preview: wx-config in Haskell

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

Hi everybody,

I'm trying to simplify the process of installing wxHaskell on Windows.

My wxhaskell branch at

   http://darcsden.com/kowey/wxhaskell

contains a Haskell implementation of wx-config.

It seems to work for me as a drop-in replacement for wx-config on Windows,
at least as far as wxHaskell is concerned.  Note that it offers none of
the features of the real wx-config.

Good news
---------
- no need to set WXCFG
- setting WXWIN is optional if you put wxWidgets in a path
  this wx-config will think to look at (eg. C:\wxWidgets-2.8)
- can be used as a Haskell library
- can be depended on as a Cabal dependency

Bad news
--------
- has not been tested with wxWidgets 2.9
- broken with HEAD wxHaskell (seems to work for the latest released one)
- no maintainer: I don't think I have the resources to actually maintain it
  or extend it with new features. I'm mainly hoping to break inertia by
  starting with something that sort of works while hoping that somebody
  else can take over.
- none of the features/safety of the real wx-config. In fact, it's little
  more than a glorified putStrLn of the "wx-config --cppflags --libs"
  output.  Crucially, this may break other wxFoo bindings that use
  wx-config (this is easy for us to work around, eg. only use it as a
  library, and don't install a wx-config executable)

What do you think?

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

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

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

On Mon, Jul 18, 2011 at 11:30:39 +0100, Andrew Butterfield wrote:
> How does it work with GHCi ?

I'm having that complaint about stdc++ which I believe has
been discussed in another thread on this list.

> (Which version of Haskell were you building against ?)

Argh, I thought I made a point of listing versions for everything :-)
It's Haskell Platform 2011.2.0.1

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

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

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

On Sun, Jul 17, 2011 at 06:28:39 -0400, carlos gomez wrote:
> > This makes me think that maybe my self-built wxWidgets might have worked
> > (although I think I *was* working from the MSYS shell then) if I had
> > done the same.  After all, the wxPack version was built with the same.

> So, does that work?

Does what work?  My original self-built wxWidgets?

I think so! I tested by first moving the wxPack location away,
confirming that my application *stops* working; and moving my
TDM self-build in its place and having it work again.

Thanks,

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

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

[Andrew B. <and...@cs...>]

How does it work with GHCi ?

(Which version of Haskell were you building against ?)


On 17 Jul 2011, at 11:28, carlos gomez wrote:

> So, does that work?
> 
> 
> On 17 July 2011 06:16, Eric Y. Kow <eri...@gm...> wrote:
> On Sun, Jul 17, 2011 at 10:57:55 +0100, Eric Y. Kow wrote:
> > On Sun, Jul 17, 2011 at 10:18:53 +0100, Eric Y. Kow wrote:
> > > 3. wxHaskell builds fine, but when running any GUI app:
> > >    The procedure entry point __gxx_personality_v0 could not be
> > >    located in the dynamic link library libstdc++-6.dll
> >
> > Oh, that's odd.  I just noticed that I can run my program fine
> > from the MSYS shell, but if I run it from the DOS prompt or by
> > double-clicking I get error message above.
> 
> OK, sorry for being noisy.  What worked for me is to uninstall
> the TDM GCC I had installed earlier and to make sure that
> MinGW/bin was in my PATH.
> 
> I think the active ingredient in these steps is making sure we're using
> the mingw libstdc++ and not the tdm one.
> 
> This makes me think that maybe my self-built wxWidgets might have worked
> (although I think I *was* working from the MSYS shell then) if I had
> done the same.  After all, the wxPack version was built with the same.
> 
> --
> Eric Kow <http://erickow.com>
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev_______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero@TCD, Head of Foundations & Methods Research Group
Director of Teaching and Learning - Undergraduate,
School of Computer Science and Statistics,
Room F.13, O'Reilly Institute, Trinity College, University of Dublin
                          http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

[carlos g. <car...@gm...>]

So, does that work?


On 17 July 2011 06:16, Eric Y. Kow <eri...@gm...> wrote:

> On Sun, Jul 17, 2011 at 10:57:55 +0100, Eric Y. Kow wrote:
> > On Sun, Jul 17, 2011 at 10:18:53 +0100, Eric Y. Kow wrote:
> > > 3. wxHaskell builds fine, but when running any GUI app:
> > >    The procedure entry point __gxx_personality_v0 could not be
> > >    located in the dynamic link library libstdc++-6.dll
> >
> > Oh, that's odd.  I just noticed that I can run my program fine
> > from the MSYS shell, but if I run it from the DOS prompt or by
> > double-clicking I get error message above.
>
> OK, sorry for being noisy.  What worked for me is to uninstall
> the TDM GCC I had installed earlier and to make sure that
> MinGW/bin was in my PATH.
>
> I think the active ingredient in these steps is making sure we're using
> the mingw libstdc++ and not the tdm one.
>
> This makes me think that maybe my self-built wxWidgets might have worked
> (although I think I *was* working from the MSYS shell then) if I had
> done the same.  After all, the wxPack version was built with the same.
>
> --
> Eric Kow <http://erickow.com>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

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

On Sun, Jul 17, 2011 at 10:57:55 +0100, Eric Y. Kow wrote:
> On Sun, Jul 17, 2011 at 10:18:53 +0100, Eric Y. Kow wrote:
> > 3. wxHaskell builds fine, but when running any GUI app:
> >    The procedure entry point __gxx_personality_v0 could not be
> >    located in the dynamic link library libstdc++-6.dll
> 
> Oh, that's odd.  I just noticed that I can run my program fine
> from the MSYS shell, but if I run it from the DOS prompt or by
> double-clicking I get error message above.

OK, sorry for being noisy.  What worked for me is to uninstall
the TDM GCC I had installed earlier and to make sure that
MinGW/bin was in my PATH.

I think the active ingredient in these steps is making sure we're using
the mingw libstdc++ and not the tdm one.

This makes me think that maybe my self-built wxWidgets might have worked
(although I think I *was* working from the MSYS shell then) if I had
done the same.  After all, the wxPack version was built with the same.

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

Re: [wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

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

On Sun, Jul 17, 2011 at 10:18:53 +0100, Eric Y. Kow wrote:
> 3. wxHaskell builds fine, but when running any GUI app:
>    The procedure entry point __gxx_personality_v0 could not be
>    located in the dynamic link library libstdc++-6.dll

Oh, that's odd.  I just noticed that I can run my program fine
from the MSYS shell, but if I run it from the DOS prompt or by
double-clicking I get error message above.

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

[wxhaskell-users] wxHaskell on Windows (or wxPack rocks!)

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

Hi everybody,

I've had some difficulty installing wxHaskell on Windows 7, but I
eventually got there, so I thought I should report (and edit the wiki).

In a nutshell: the secret is to use wxPack (precompiled wxWidgets
including MinGW Unicode version) [1] and avoid trying to build wxWidgets
yourself.

Credit goes to SkyTreeBird23 for suggesting wxPack in his guide
[2].  (Say hello if you're reading this mailing list!)

This is not a complete how-to.  I'll edit the wiki when I have a spare
moment.  But I hope this list of pitfalls helps somebody in the
meantime.

My setup
--------------------------------------------------
- VM running in Parallels 6 allocated 1 GiB of RAM
- Windows 7 Professional
- WxPack 2.8.12.01
- wxcore 0.12.1.7  
- wx-config.exe

Things I have tried
- Mingw (32 bit) installer version 20110530
  (have also tried 20110316)
- TDM GCC 4.5.2

Documentation
--------------------------------------------------
1. wxHaskell on Haskell wiki (Building)
   http://haskell.org/haskellwiki/WxHaskell/Building

2. wxWidgets MingW page
   http://wiki.wxwidgets.org/Installing_WxWin_MinGW

Issues I've run into
----------------------------------------------------------------------
1. ld.exe: out of memory allocating N bytes
  
   Solution: use the TDM version of GCC, not the MinGW.  See wxWidgets
   wiki page above; it might be some sort of MinGW bug.

2. ld returned 5 exit status

   Solution: clean your source tree (after hitting #1).  Just typing
   mingw32-make -f makefile.gcc clean was apparently not enough, so
   I ended up unzipping a fresh one

3. wxHaskell builds fine, but when running any GUI app:
   The procedure entry point __gxx_personality_v0 could not be
   located in the dynamic link library libstdc++-6.dll

   Solution: (stumped - I think this has may have something to do with
   building Haskell stuff with the HP-built-in GCC and wxWidgets with
   the TDM GCC, but I don't really understand enough about libraries
   to say)
   
   At this point, I stumbled on SkyTreeBird's guide who informed me
   of the existence of

4. wxWidgets hasn't been found installed at 'C:\wxWidgets-2.8.12'

   The wxPack installer unfortunately does not include a dash
   by default in the path it offers you.  I think it wants to
   put wxWidgets in something like 'C:\Source Code\wxWidgets2.8'
   I got rid of the 'Source Code', but did not notice the missing
   hyphen.

5. (Hello world) The program can't start because wxmsw28u_gcc.dll
   is missing from your computer

   Solution: make sure C:\wxWidgets-2.8.12\lib\gcc_dll (substitute
   your wxWidgets path accordingly) is in your PATH
   
[1] http://wxpack.sourceforge.net/ 
[2] http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup

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

Re: [wxhaskell-users] where is document of "wxcBeginBusyCursor"

[carlos g. <car...@gm...>]

Personally, when I use wxHaskell, I am used to see wxWidgets' documentation
(http://docs.wxwidgets.org/stable/).
What I do is, find the class/object in wxcore (eg. ScrolledWindow) and then
 search his documentation in wxWidgets.
In that way I know what functions are in wxHaskell, and what aren't, and of
course what they do.

Regards, Carlos Gomez

On 13 July 2011 06:47, 诺铁 <no...@gm...> wrote:

> Hello,all,
>     I am trying to use treeControl, and I find that the sample
> "FileBrowse.hs" maybe the only useful documentation of this control.
>  BTW,the sample is quite good for me to learn to use treeControl.
>     doc for some function can't be
> found,eg,wxcBeginBusyCursor, wxcEndBusyCursor , I guess the name should
> describe its function,but I wish to read it's documentation to comfirm it,
> and to see whether I can find other useful things.
>     so, can anybody pls give me a link to it's documentation?
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

[wxhaskell-users] where is document of "wxcBeginBusyCursor"

[诺铁 <no...@gm...>]

Hello,all,
    I am trying to use treeControl, and I find that the sample
"FileBrowse.hs" maybe the only useful documentation of this control.
 BTW,the sample is quite good for me to learn to use treeControl.
    doc for some function can't be
found,eg,wxcBeginBusyCursor, wxcEndBusyCursor , I guess the name should
describe its function,but I wish to read it's documentation to comfirm it,
and to see whether I can find other useful things.
    so, can anybody pls give me a link to it's documentation?

Re: [wxhaskell-users] can't load .so/.DLL for : stdc++

[Joel S. <jo...@me...>]

On Thu, Jun 23, 2011 at 8:40 AM, Howard B. Golden
<how...@ya...> wrote:
> --- On Thu, 6/23/11, Joel Shellman <jo...@me...> wrote:
>> Yes, I have it installed. And I have the file at:
>> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.4/libstdc++.so
>> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/libstdc++.so
>
> Possibly your .cabal file needs to include that directory or that .so explicitly. HTH.


I added:
  extra-lib-dirs: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/

but still got the same error.

Re: [wxhaskell-users] can't load .so/.DLL for : stdc++

[Howard B. G. <how...@ya...>]

--- On Thu, 6/23/11, Joel Shellman <jo...@me...> wrote:

> Yes, I have it installed. And I have the file at:
> 
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.4/libstdc++.so
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/libstdc++.so
> 
> I found, though, that if I compile with ghc directly, it
> doesn't give
> me the error. But if I use cabal install, then I get the
> error.

Possibly your .cabal file needs to include that directory or that .so explicitly. HTH.

Howard

Re: [wxhaskell-users] can't load .so/.DLL for : stdc++

[Joel S. <jo...@me...>]

On Thu, Jun 23, 2011 at 8:15 AM,  <mac...@gm...> wrote:
> It's been a while since I last installed wxHaskell on Linux, but if
> memory serves me well I needed to install libstdc++-dev to get it to
> build. Do you have this package installed?

Yes, I have it installed. And I have the file at:

/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.4/libstdc++.so
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/libstdc++.so

I found, though, that if I compile with ghc directly, it doesn't give
me the error. But if I use cabal install, then I get the error.

Re: [wxhaskell-users] can't load .so/.DLL for : stdc++

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

It's been a while since I last installed wxHaskell on Linux, but if
memory serves me well I needed to install libstdc++-dev to get it to
build. Do you have this package installed?

Regards,
Maciek

On Thu, Jun 23, 2011 at 4:11 AM, Joel Shellman <jo...@me...> wrote:
> I have seen this mentioned in various places but haven't seen a
> solution for it. I'm on Ubuntu Natty using ghc 7.0.3.20110330 running
> cabal install on my project and I get the below error:
>
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package array-0.3.0.2 ... linking ... done.
> Loading package stm-2.2.0.1 ... linking ... done.
> Loading package bytestring-0.9.1.10 ... linking ... done.
> Loading package containers-0.4.0.0 ... linking ... done.
> Loading package filepath-1.2.0.0 ... linking ... done.
> Loading package old-locale-1.0.0.2 ... linking ... done.
> Loading package old-time-1.0.0.6 ... linking ... done.
> Loading package unix-2.4.2.0 ... linking ... done.
> Loading package directory-1.1.0.0 ... linking ... done.
> Loading package transformers-0.2.2.0 ... linking ... done.
> Loading package mtl-2.0.1.0 ... linking ... done.
> Loading package parsec-3.1.1 ... linking ... done.
> Loading package time-1.2.0.3 ... linking ... done.
> Loading package wxdirect-0.12.1.4 ... linking ... done.
> Loading package wxcore-0.12.1.7 ... <command line>: can't load
> .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No
> such file or directory)
> cabal: Error: some packages failed to install:
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] can't load .so/.DLL for : stdc++

[Joel S. <jo...@me...>]

I have seen this mentioned in various places but haven't seen a
solution for it. I'm on Ubuntu Natty using ghc 7.0.3.20110330 running
cabal install on my project and I get the below error:

Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.2 ... linking ... done.
Loading package stm-2.2.0.1 ... linking ... done.
Loading package bytestring-0.9.1.10 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.2.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package parsec-3.1.1 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package wxdirect-0.12.1.4 ... linking ... done.
Loading package wxcore-0.12.1.7 ... <command line>: can't load
.so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No
such file or directory)
cabal: Error: some packages failed to install:

Re: [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-users] Linking error

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

On 19 June 2011 23:09, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Sat, 18 Jun 2011 22:35:55 +0200, Henk-Jan van Tuyl <hj...@ch...>
> wrote:
>
> >
> > L.S.,
> >
> > Whenever I try to link a program to wxhaskell, I get error messages about
> > "undefined reference to `_imp___ZTV17wxFindReplaceData'" What can I do
> > about this?
> >
>
> I found that file libwxmsw28u.a contains __imp___ZTV19wxFindReplaceDialog,
> is this difference because of different compiler versions?
>

No - they are different things (and not actually functions! - see below).
I'll try to look into the problem if I get some time tomorrow.

The error most likely means that the Haskell FFI is trying to import a
function which is no longer present in the C wrapper, for whatever reason
(very possibly an error on my part). The _ZTVxx part is probably name
mangling for C++ functions (there's a handy utility, c++filt, which lets you
decode C++ function names).

My c++filt suggests that __ZTV17wxFindReplaceData is the vtable for
wxFindReplaceData, so probably a missing/incorrect virtual function
definition, or something related.

Couple of questions to help me debug:

   - Platform (Windows / Linux / Mac)? I can readily look into 32 bit Linux
   or Windows. The error looks like a Windows error, but I just want to be sure
   (__imp___ is usually used by gcc on Windows for DLL import library names, I
   think)
   - Version you are using? Darcs tip?
   - GHC version (I have whatever is in HP 2011.2.0.0 most readily
   available)


Thanks
Jeremy

Re: [wxhaskell-users] Linking error

[Henk-Jan v. T. <hj...@ch...>]

On Sat, 18 Jun 2011 22:35:55 +0200, Henk-Jan van Tuyl <hj...@ch...>
wrote:

>
> L.S.,
>
> Whenever I try to link a program to wxhaskell, I get error messages about
> "undefined reference to `_imp___ZTV17wxFindReplaceData'" What can I do
> about this?
>

I found that file libwxmsw28u.a contains __imp___ZTV19wxFindReplaceDialog,  
is this difference because of different compiler versions?


Regards,
Henk-Jan van Tuyl


-- 
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

[wxhaskell-users] Linking error

[Henk-Jan v. T. <hj...@ch...>]

L.S.,

Whenever I try to link a program to wxhaskell, I get error messages about  
"undefined reference to `_imp___ZTV17wxFindReplaceData'" What can I do  
about this?

The full error messages are:

C:\Program  
Files\Haskell\wxcore-0.12.1.7\ghc-7.0.3/libHSwxcore-0.12.1.7.a(eljfindrepldlg.o):eljfindrepldlg.cpp:(.text+0x1d):  
undefined reference to `_imp___ZTV17wxFindReplaceData'
C:\Program  
Files\Haskell\wxcore-0.12.1.7\ghc-7.0.3/libHSwxcore-0.12.1.7.a(eljfindrepldlg.o):eljfindrepldlg.cpp:(.text+0x95):  
undefined reference to `_imp___ZTV17wxFindReplaceData'
C:\Program  
Files\Haskell\wxcore-0.12.1.7\ghc-7.0.3/libHSwxcore-0.12.1.7.a(eljfindrepldlg.o):eljfindrepldlg.cpp:(.text$_ZN17wxFindReplaceDataD1Ev[wxFindReplaceData::~wxFindReplaceData()]+0xb):  
undefined reference to `_imp___ZTV17wxFindReplaceData'
C:\Program  
Files\Haskell\wxcore-0.12.1.7\ghc-7.0.3/libHSwxcore-0.12.1.7.a(eljfindrepldlg.o):eljfindrepldlg.cpp:(.text$_ZN17wxFindReplaceDataD0Ev[wxFindReplaceData::~wxFindReplaceData()]+0xb):  
undefined reference to `_imp___ZTV17wxFindReplaceData'


Regards,
Henk-Jan van Tuyl


-- 
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

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

[wxhaskell-users] wxHaskell for Haskell Platform 2011.2.0.1

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

Hi all,

With green light from maintainer Jeremy O'Donoghue, I've uploaded a
trivial update to wxHaskell, relaxing the dependencies so that it builds
with the latest Haskell Platform and does not try to install other
versions of packages.

What is wxHaskell?
----------------------------------------------------------------------
wxHaskell is a Haskell library for writing GUIs that work on multiple
platforms.

It provides a reasonable compromise between getting a native user
interface and saving effort.  It uses the wxWidgets library, which in
turn wraps around the native GUI toolkit for the target platform and
tries to follow platform-specific customs and conventions so that you
don't have to worry about them.  Here are the sort of results the minor
details wxWidgets seems to get right on Mac OS X:

 - system preferences are under the Preferences menu for the application
 - file open/save and print dialogues are the actual ones used by Mac
   applications instead of some half-baked Aqua coloured monstrosity

It may not be perfect, but it's not bad considering you don't even
have to think about it.

wxHaskell is available under a relaxed LGPL license, which basically
means you can release both open sourced and closed source with it.

About this release
----------------------------------------------------------------------
This is just a minor release bumping some dependencies.

Installation comes in two basic steps:

1. Install wxWidgets 2.8

   - On MacOS X, Homebrew works well for me (if you update to get patches
     to build wxWidgets with Unicode enabled).
   - On Ubuntu/Debian, I use apt-get wxgtk.
   - I have not personally tried it on Windows, but I've hear reports that
     it's easy to install there as well.

2. cabal install wx

See http://www.haskell.org/haskellwiki/WxHaskell for more information

What's next?
----------------------------------------------------------------------
Jeremy has been doing quite a lot of work on wxHaskell.  Among other
things [1], he's been:

- updating it for what will eventually be wxWidgets 3.0
- trying to resolve issues restarting the UI from GHCi
- improved Event handling (for Mac users, the upshot is that
  wxHaskell would work with the wxWidgets that ships with OS X, meaning
  "cabal install wx" from the HP would "just work")

There are also mutterings about pushing for inclusion in the Haskell
Platform, but there is still a lot of work of to do before we get there
[2]. Help wanted :-)

Enjoy!

Eric

[1] http://thread.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/612
[2] http://thread.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/616 

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

Re: [wxhaskell-users] [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-users] ANNOUNCE: Data Binding

[Gideon <ha...@ac...>]

I am pleased to announce the first release of the data binding
framework for Haskell [1]. The binding-core package [2] is a library
for binding mutable data and lists to IO objects. binding-gtk [3] and
binding-wx [4] are convenient wrappers for binding to Gtk2Hs and
WxHaskell respectively.

Feedback is welcome. Cabal install and enjoy!

- Gideon

[1] http://code.accursoft.com/binding
[2] http://hackage.haskell.org/package/binding-core
[3] http://hackage.haskell.org/package/binding-gtk
[4] http://hackage.haskell.org/package/binding-wx

[wxhaskell-users] 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-users] Haskell Platform

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

[x-posting wxhaskell-devel]

On 12 June 2011 18:43, Guy <guy...@ya...> wrote:

> On 12/06/2011 20:07, Eric Y. Kow wrote:
> > On Sun, Jun 12, 2011 at 19:54:13 +0300, Guy wrote:
> >> I'm trying to get a GUI package included in the Haskell Platform. The
> >> platform's inclusion policy requires that (one
> >> of?) the package's official maintainers supports the proposal.
>

The sad reality (and I suspect it may apply equally to Gtk2HS) is that there
isn't a large enough core team maintaining wxHaskell to commit to Haskell
Platform. I am nowhere near being able to give the time needed to support
such an effort.

As a guess, it would require a fairly committed(*) core team of about 6
people, including at least one on each of the major platforms (Windows,
Linux, Mac).

(*) for the avoidance of doubt, "able to commit a few hours per week on a
reasonably long-term basis".


> > We may need to think strategically about this.
>

The main areas where we have problems are:

   - Robust support for GHCi, working on all platforms (currently works on
   none!)
   - Straightforward to install on all platforms (currently probably easiest
   on Windows, and not reliably functioning on 'built-in' versions of
   wxWidgets)
   - Documented mechanism/approach to wrapping new parts of wxWidgets APIs
   (this probably isn't a show-stopper for HP inclusion)

>
> > gtk2hs is much more popular than wxHaskell, and by and large coders
> > seem not to be particularly concerned about getting as close to native
> > UI as possible (and they'll just point out that you can't anyway).
>

True, but the reality is that whatever gets included in HP will become the
de-facto Haskell GUI, and will edge the alternatives out fairly quickly. I'd
love this to be wxHaskell, but I really don't have the bandwidth to make it
happen.