wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] [Announce] wxHaskell 0.90

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

Hi Haskellers,

I am delighted to announce the release of wxHaskell 0.90. This release
represents a significant milestone for us as it includes support for
wxWidgets 2.9.x.

The release is avalable from Hackage and as a darcs repo from
http://code.haskell.org/wxhaskell. Build and installation instructions have
been updated on the Haskell wiki at
http://www.haskell.org/haskellwiki/Wxhaskell.

Highlights of the new release:

   - Builds and runs cleanly on 64 bit platforms (particularly MacOS X
   Lion).
   - The wxWidgets C wrapper is now built as a DLL on all platforms.
      - This is reported to enable meaningful use of wxHaskell in GHCi, at
      least on OS X and Windows.
      - It also theoretically allows wxc to be used independently of
      wxHaskell as the basis of a wxWidgets wrapper for other programming
      languages. Some D language hackers have expressed an interest in this.
      - New controls:
      - Styled Text Control (actually, this is reinstated as it was 'lost'
      a while back during cabalization)
      - OpenGL support
      - PropertyGrid control
   - Many events added in anticipation of wrapping more controls in the
   near future.

There were many contributors to this release, the most notable being Dave
Tapley (with the generous support of Mentics Inc.). Dave was responsible
for the refactoring of wxc and PropertyGrid support. Eric Kow put in quite
a bit of work with Kenny Frodo, Doaitse Swierstra and Alessandro Vermeulen
on MacOS support. There were a couple of contributions from long-time
wxHaskell contributor shelarcy, and bug reports, fixes and support from a
larger community than I ever realised we had.

Support for wxWidgets 2.8.x will continue in a 'maintenance mode'
continuing from the wxHaskell 0.13 codeline. If you continue to use the old
codeline, please take note of the changes to the procedure to get the
correct version for your needs. This is also documented at
http://www.haskell.org/haskellwiki/Wxhaskell.

Thanks to everyone involved.

Best regards

Jeremy

[wxhaskell-users] missing wx_gtk2u_media-2.8 for wxhaskell-0.13

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

I have now tried to move from wxhaskell-0.12 to 0.13, but this fails due 
to missing libwx_gtk2u_media-2.8.so like reported by Peter Simons. I have 
not built wxWidgets myself but use the version packaged for OpenSuse 10.3. 
That is, it seems that this dependency on media is new in wx-0.13, right?

Interestingly I found 'mmedia' instead of 'media'. That is, on Suse I have 
a file named libwx_gtk2u_mmedia-2.8.so but no libwx_gtk2u_media-2.8.so, 
and on Ubuntu 10.4 I have libwx_gtk2u_media-2.8.so but no 
libwx_gtk2u_mmedia-2.8.so. Are these two files the same?

Re: [wxhaskell-users] Major changes to repo at code.haskell.org

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

On Wed, 4 Apr 2012, Jeremy O'Donoghue wrote:

> I'm not quite comfortable moving to 1.0 - sounds a bit 'finished' to me.

Somehow yes. But wxhaskell is already very good and usable for my taste. 
So 1.0 would be justified even for the current version. Even more we have 
packages like HTTP with version 4000. :-)

> How about a compromise: I'll bump the new version to 0.20.

Sure, this would be a compromise, but psychologically it puts pressure on 
us to not release too often to Hackage, since every release reduces the 
available number of major bumps.

Nonetheless I would feel more comfortable if other wxhaskell users would 
vote in favor of branching to version 1.0 or against it.


Best,
Henning

Re: [wxhaskell-users] Major changes to repo at code.haskell.org

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

On 4 April 2012 08:14, Henning Thielemann <le...@he...>wrote:

>
> on a second thought ...
>
>
> On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote:
>
>   *  The mainline will have the patches needed to update to support
>> wxWidgets 2.9.x, based on the work
>>
>>    by Dave Tapley and others, and sourced from the development
>> repositories on Darcsden, Readers of
>>    the wxhaskell-devel list will be familiar with these.
>>
> ...
>
>>     +  The new codeline starts as version 0.15. Users will find that this
>> is contained in the
>>        directories:
>>
>
> If the new version is such a big change, how about calling it version 1.0?
>
> This would also give us a larger range of versions for the wxWidgets-2.8
> compatibility branch. You know, sometimes even small changes require a
> major version bump, such as adding an instance to Selection, etc.
>

I'm not quite comfortable moving to 1.0 - sounds a bit 'finished' to me.
How about a compromise: I'll bump the new version to 0.20.

Jeremy

Re: [wxhaskell-users] Major changes to repo at code.haskell.org

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

on a second thought ...

On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote:

>  *  The mainline will have the patches needed to update to support wxWidgets 2.9.x, based on the work
>     by Dave Tapley and others, and sourced from the development repositories on Darcsden, Readers of
>     the wxhaskell-devel list will be familiar with these.
...
>      +  The new codeline starts as version 0.15. Users will find that this is contained in the
>         directories:

If the new version is such a big change, how about calling it version 1.0?

This would also give us a larger range of versions for the wxWidgets-2.8 
compatibility branch. You know, sometimes even small changes require a 
major version bump, such as adding an instance to Selection, etc.

Re: [wxhaskell-users] Major changes to repo at code.haskell.org

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

On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote:

> Please shout loudly and soon if you have any problem with what I am planning to do, as I am planning
> to make these changes within the next week. The wxWidgets 2.9 support has been waiting in limbo for
> too long now (my fault, I accept).

Your plans sound great. Please go ahead!


Best,
Henning

[wxhaskell-users] Major changes to repo at code.haskell.org

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

Hi wxHaskellers,

I am about to apply a fairly significant set of changes to the wxHaskell
master repository at code.haskell.org. This is in order that I can apply
the changes needed to support wxWidgets versions from 2.9 onwards, and the
major architectural changes this entails.

The changes will be as follows:

   - The current mainline tip will be branched into a wxhaskell-0.13
   codeline, which will receive only minor updates going forward. This
   codeline will be appropriate for users of wxWidgets 2.8.x. In practice,
   this means that users who pull the darcs repo will see the following new
   directories:
      - wxdirect-0.13: The branch of wxDirect supporting wxWidgets 2.8.x
      - wxcore-0.13: The branch of wxcore supporting wxWidgets 2.8.x
      - wx-0.13: The branch of wx supporting wxWidgets 2.8.x
   - The mainline tip will be tagged WXHASKELL-0-13-BRANCH to show the
   historical relationship between the two branches.
   - The mainline will have the patches needed to update to support
   wxWidgets 2.9.x, based on the work by Dave Tapley and others, and sourced
   from the development repositories on Darcsden, Readers of the
   wxhaskell-devel list will be familiar with these.
      - Because Dave's codebase was branched late last summer, it has not
      been possible to simply push his patches to the wxHaskell mainline, since
      darcs never manages to resolve the differences. For this reason, I have
      developed a smaller, equivalent set of patches on whcih I have tried to
      maintain as much history as possible. This is regrettable, but I
don't see
      an easy way around the problem.
      - There are a number of changes, but the most significant is that
      there is a new module, wxc, which contains the wxWidgets C language
      wrapper. Wxcore is now a pure Haskell module. In addition, we
have removed
      the vestiges of Eiffel support from wxc.
      - The new codeline starts as version 0.15. Users will find that this
      is contained in the directories:
         - wxdirect: wxDirect version supporting wxWidgets 2.9.x and later.
         Because Eiffel support is removed, this version cannot be used with
         wxhaskell 0.13.
         - wxc: The C language wrapper for wxWidgets. On our supported
         platforms (Windows, Linux, OS X), this always generates a
shared library.
         As such it is theoretically possible for wxc to be used as
the basis for a
         wxWidgets binding for another language. There are members of the D
         community playing with this idea.
         - wxcore: A pure Haskell wrapper over wxc.
         - wx: This is basically unchanged from wx in revision 0.13.

When the new versions are committed, they will be accompanied by uploads to
Haskage from both branches, along with build instructions for both versions.

Shortly after the formal release of 0.15, I will be producing a cabal
wrapper for wx-config on Windows. This will simplify the Windows build
significantly, as it currently depends on my privately updated version of
wx-config-win on Google code.

Please shout loudly and soon if you have any problem with what I am
planning to do, as I am planning to make these changes within the next
week. The wxWidgets 2.9 support has been waiting in limbo for too long now
(my fault, I accept).

Best regards

Jeremy

Re: [wxhaskell-users] splitterWindow

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

On Mon, 2 Apr 2012, Jeremy O'Donoghue wrote:

> This is a very good idea, but I was thinking of doing almost exactly the opposite: before I apply the
> changes to the main repo, I was planning to create a wxHaskell-0.13 (wxWidgets 2.8.x) branch on
> code.haskell.org, probably by creating wxdirect-0.13, wxcore-0.13 and wx-0.13 branches as separate
> directories. The other option would be to move 0.13 support to Darcsden.

For the repositories of my projects I tend to use one repository per Cabal 
package, because I use darcs tags for tagging versions that I uploaded to 
Hackage and the versions, especially the minor versions, of the packages 
of one project are not always in sync. Translated to wxhaskell this means, 
current wxcore might have version 0.13.2.1 whereas wx might have version 
0.13.3.7.


> I think it makes sense to have a 'central' repo for changes. It is easy 
> for private repositories to be lost over time.
> 
> Does this work for you? 

This would be perfect. What is the advantage of darcsden compared to 
code.haskell.org? Currently I am very happy with code.haskell.org.


Best,
Henning

Re: [wxhaskell-users] splitterWindow

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

On 30 March 2012 08:42, Henning Thielemann <le...@he...>wrote:

>
> On Tue, 27 Mar 2012, Henning Thielemann wrote:
>
> > I want to use a splitterWindow. For instance I wanted to change the
> 'gravity'
> > because the default value is not appropriate for my application.
> > Unfortunately there is no splitterWindowSetSashGravity function.
>
> I have added splitterWindowSetSashGravity to WxcClassesMZ of my working
> copy of wxcore. I have also some other small additions like 'selection'
> attribute for notebooks. Since not everybody wants to move to the new
> wxwidgets immediately, how about updating wx-0.13 with small additions for
> a while? I could simply apply the patches myself and upload new wxhaskell
> packages to Hackage myself if the main maintainers want to concentrate on
> new wx versions.
>

This is a very good idea, but I was thinking of doing almost exactly the
opposite: before I apply the changes to the main repo, I was planning to
create a wxHaskell-0.13 (wxWidgets 2.8.x) branch on code.haskell.org,
probably by creating wxdirect-0.13, wxcore-0.13 and wx-0.13 branches as
separate directories. The other option would be to move 0.13 support to
Darcsden.

I think it makes sense to have a 'central' repo for changes. It is easy for
private repositories to be lost over time.

Does this work for you?

Regards
Jeremy

Re: [wxhaskell-users] splitterWindow

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

On Tue, 27 Mar 2012, Henning Thielemann wrote:

> I want to use a splitterWindow. For instance I wanted to change the 'gravity' 
> because the default value is not appropriate for my application. 
> Unfortunately there is no splitterWindowSetSashGravity function.

I have added splitterWindowSetSashGravity to WxcClassesMZ of my working 
copy of wxcore. I have also some other small additions like 'selection' 
attribute for notebooks. Since not everybody wants to move to the new 
wxwidgets immediately, how about updating wx-0.13 with small additions for 
a while? I could simply apply the patches myself and upload new wxhaskell 
packages to Hackage myself if the main maintainers want to concentrate on 
new wx versions.

[wxhaskell-users] splitterWindow

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

I want to use a splitterWindow. For instance I wanted to change the 
'gravity' because the default value is not appropriate for my application. 
Unfortunately there is no splitterWindowSetSashGravity function.

Then I like to react to a moved sash of the splitter window. I did not 
find an Event for this purpose. How can I define my own one?

Re: [wxhaskell-users] ListCtrl scroll state or Virtual ListCtrl, and I'd appreciate some mentoring

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

Hi Aur,

On 24 March 2012 22:07, Aur Saraf <son...@gm...> wrote:

> I need a ListCtrl that I can edit and not only append to. That means
> either a version of appendItem that takes an index that I've missed, a
> way to get and later set the scroll-state of a ListCtrl (and then I
> can just reset all items on every edit) or a way to use the
> wxLC_VIRTUAL style available in C++ wxWidgets.
>

For your purposes, the wrapper of ListCtrl in Graphics.UI.WX.Controls is
probably not going to do everything you will need it to. You will likely
need to drop down to the lower level API in wxcore.

If you look in Graphics.UI.WXCore.WxcClassesAL, you will find a pretty
complete binding to all of the functions in the wxWidgets C++ API. These
all start with listCtrl in their names, and are pretty much exact Haskell
representations of the C++ API functions. As an example,
wxListCtrl::InsertItem() becomes listCtrlInsertItem in Haskell. For
functions which have overloads in C++ (as this example does), you will find
that there are several variants of listCtrlInsertItem which have slightly
different names - the choice of which should be reasonably obvious.

Because the functions in the wxcore API are so closely related to the C++
API, the good news is that you can more or less just translate any sample
code for C++ into Haskell. The bad news is that it feels a lot like
programming in C++.


> Also, as I said in the title, I'd really appreciate if someone could
> take some time to be available for a few beginner questions on some
> chat or email platform. I find that wxHaskell has too much lore for me
> to learn without an experienced hand guiding me. I promise to research
> every question before I resort to asking my mentor.
>

You will find that list contributors are usually pretty helpful. I would
suggest that that you start with my blog:
http://wewantarock.wordpress.comWhile it is far from complete, and is
only updated rather sporadically, it
has been written to answer some of the issues I came up against when taking
on wxHaskell as a new maintainer.

For your specific problem with ListCtrl, you may do well to look at the
wxWidgets Programming book. This is (obviously) written for C++, but covers
Virtual ListCtrl (on page 330). There seems to be a downloadable PDF at
http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CGQQFjAE&url=http%3A%2F%2Fptgmedia.pearsoncmg.com%2Fimages%2F0131473816%2Fdownloads%2F0131473816_book.pdf&ei=DDxwT8KDFMKeOrWwqeEF&usg=AFQjCNG49vErXpJEtko5Xe1uROZP-Asp6w

Best regards
Jeremy

Re: [wxhaskell-users] ListCtrl scroll state or Virtual ListCtrl, and I'd appreciate some mentoring

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

On Sun, 25 Mar 2012, Aur Saraf wrote:

> I need a ListCtrl that I can edit and not only append to. That means
> either a version of appendItem that takes an index that I've missed, a
> way to get and later set the scroll-state of a ListCtrl (and then I
> can just reset all items on every edit) or a way to use the
> wxLC_VIRTUAL style available in C++ wxWidgets.

Note that the 'wx' package provides the high-level interface, but not 
everything can be handled through this interface. A richer set of 
functions is provided by the 'wxcore' package. There you find the modules 
Graphics.UI.WXCore.WxcClassesAL and Graphics.UI.WXCore.WxcClassesMZ that 
provide low-level interfaces to the methods of the classes starting with 
letters A-L and M-Z, respectively.

So if I want to find out about additional functions of listCtrl I first 
look into the wxWidgets documentation, i.e.
   /usr/share/doc/wx2.8-doc/wx-manual.html/wx_wxlistctrl.html

There I find a method named wxListCtrl::InsertItem in various flavors, 
also a variant with an explicit index. Now I can lookup listCtrlInsertItem 
in WxcClassesAL and find according functions.


> Also, as I said in the title, I'd really appreciate if someone could
> take some time to be available for a few beginner questions on some
> chat or email platform. I find that wxHaskell has too much lore for me
> to learn without an experienced hand guiding me. I promise to research
> every question before I resort to asking my mentor.

I think this mailing is a good place because all answers can be seen 
publically and thus may help other people with the same problems.

What I also use frequently in order to find the correct widget class are 
the example collections. There are some Haskell examples in the 'samples' 
folder of the wxhaskell repository and there are even more C++ examples in 
the wxwidgets documentation:
   /usr/share/doc/wx2.8-doc/wx-manual.html/wx_samples.html
  What I am really missing are screenshots of the widgets because often I 
cannot imagine the GUI elements from their literal description.

[wxhaskell-users] ListCtrl scroll state or Virtual ListCtrl, and I'd appreciate some mentoring

[Aur S. <son...@gm...>]

Hello,

I'm trying my hands at cloning Mark Russinovich's amazingly useful
procexp.exe for Linux, as it's hard to live without it. Also a good
chance to finally dirty my hands with GUI programming, weird that I
never have in five years of programming professionally.

To the uninitiated, I'm talking about this:
http://i229.photobucket.com/albums/ee312/Dzomlija/Vista%20Screenshots/process_explorer_2.jpg


I need a ListCtrl that I can edit and not only append to. That means
either a version of appendItem that takes an index that I've missed, a
way to get and later set the scroll-state of a ListCtrl (and then I
can just reset all items on every edit) or a way to use the
wxLC_VIRTUAL style available in C++ wxWidgets.


Can anyone help?


Also, as I said in the title, I'd really appreciate if someone could
take some time to be available for a few beginner questions on some
chat or email platform. I find that wxHaskell has too much lore for me
to learn without an experienced hand guiding me. I promise to research
every question before I resort to asking my mentor.


Thanks,
  Aur

[wxhaskell-users] wxHaskell Problems.

[Yoel J. <yo...@em...>]

[wxhaskell-users] Add DC::GetGDKWindow() when using GTK backend.

[Yoel J. <yo...@em...>]

[wxhaskell-users] Add DC::GetGDKWindow() when using GTK backend.

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

Hi,

Is it possible to add a binding to DC::GetGDKWIndow() when using GTK?  This
function is provided by WxWidgets but does not appear to be included in
WxHaskell.

I am attempting to write a widget that uses Cairo and need access to the
underlying GDK Window so I can use the GTK function `Gtk.renderWIthDrawable
:: Gtk.DrawWIndow -> Cairo a -> IO ()`.

Thanks,

Vivian

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

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

On 7 March 2012 14:38, Eric Kow <eri...@gm...> wrote:

> 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.
>

I'm in the process of trying to pull this all together.

One piece of good news is that I have just gotten my hands on a MacBook Pro
with a copy of VMWare Fusion. This means I have all of our supported
platforms available to me to test (well, a 32 bit Debian Stable, 64 bit
Windows 7 Enterprise and OSX Lion, which is a pretty good cross-section, I
think).

The less good news is that every attempt I have made to merge Dave's branch
with the mainline automatically has failed. I have given up and am doing
the merge manually.

This will result in identical source code in the end (I'm taking some care
over that), but there's a fair chance that I'll miss off some of the
check-in comments, although I'm doing my best to follow the order in which
work was done on the code.

Manual merging is not huge fun, and pretty painstaking, so please bear with
me - I want to get it right before I commit anything for wider use.

Jeremy

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell Problems.

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

On 13 Mar 2012, at 20:51, Paul-Michael Sorhaindo wrote:
> So after reading a blog post, I think it was your own talking about Debian and wxHaskell. I decided to use the repository on darcsden. I've forked and pulled the repository. After  running "cabal install" in in the wx folder I get this error


Also, one thing I noticed:

When building from checked out sources (rather than packages on hackage), you need to do this:
[this applies to Dave's branch and my branch of his branch]

cd wxdirect
cabal install
cd ..

cd wxc
cabal install
cd ..

cd wxcore
cabal install
cd ..

cd wx
cabal install
cd ..

If you just cd directly into wx without first going through wxdirect, etc, what will happen is that cabal-install will attempt to fetch the hackage version of wx's dependencies, ie. the hackage wxcore, etc.  However, what you really want is to install the darcs wxcore to go with the darcs wx.

If you prefer using sandboxed build environments, you should be able to do something like

cabal install cabal-dev
cabal install ./wxdirect ./wxc ./wxcore ./wx

Hope this helps,

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

Re: [wxhaskell-users] [wxhaskell-devel] wxHaskell Problems.

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

Hi Michael,

On 13 Mar 2012, at 20:51, Paul-Michael Sorhaindo wrote:
> I've been trying to install the latest package of wxcore which I believe is 0.13.2.1. 
> 
> I have taken several steps to try and get it to install here is my current situation.
> 
> I'm running Debian's wheezy.
> I have wxWidgets-2.9.3. built from source.

I'm afraid my efforts have been focused on MacOS X.
You'd contacted me on twitter, mentioning my branch, so I assumed you were on Mac too :-)

> So after reading a blog post, I think it was your own talking about Debian and wxHaskell. I decided to use the repository on darcsden.

Presumably, you're referring to
* http://darcsden.com/kowey/wxhaskell-osx64-dave

I don't recommend using my work, as it's really Mac specific.

Maybe try Dave or Jeremy's branches instead.  It's possible one of my changes is not portable to Linux.
* http://darcsden.com/DukeDave/wxhaskell-dev
* http://darcsden.com/jodonoghue/wxhaskell-wx29-jod

Sorry for the proliferation of branches. There's been quite a few lines of development lately.  Hopefully over time we will be able to merge these back all into mainline.

> src/cpp/ewxw_main.cpp:112:3:
>     error: ‘wxPendingEvents’ was not declared in this scope
> src/cpp/ewxw_main.cpp: In function ‘void ELJApp_initialize(void*, AppInitFunc, int, void*)’:
> 
> src/cpp/ewxw_main.cpp:123:3:
>     error: ‘wxPendingEvents’ was not declared in this scope
> cabal: Error: some packages failed to install:

I seem to remember that Dave's branch disables the use of wxPendingEvents outside of Windows.
(but then, so should mine)

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

[wxhaskell-users] wxHaskell Problems.

[Paul-Michael S. <P.S...@un...>]

Hi Eric,

I've been trying to install the latest package of wxcore which I believe is 0.13.2.1. 

I have taken several steps to try and get it to install here is my current situation.

I'm running Debian's wheezy.
I have wxWidgets-2.9.3. built from source.

Following advise of several tutorials I got several opengl packages, some of which I already had. (I've included a full list of my packages, not sure if will be useful though)

I then tried installing the packages from hackage through cabal.

This failed giving me missing functions or undefined functions in header files, I forget the exact message.


So after reading a blog post, I think it was your own talking about Debian and wxHaskell. I decided to use the repository on darcsden. I've forked and pulled the repository. After  running "cabal install" in in the wx folder I get this error

...Building stuff

src/cpp/eljvalidator.cpp:50:34:
     warning: ‘static void wxValidator::SetBellOnError(bool)’ is deprecated (declared at /usr/local/include/wx-2.9/wx/validate.h:77) [-Wdeprecated-declarations]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
src/cpp/ewxw_main.cpp: In function ‘void ELJApp_InitializeC(wxClosure*, int, char**)’:

src/cpp/ewxw_main.cpp:99:32:
     warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]

src/cpp/ewxw_main.cpp:112:3:
     error: ‘wxPendingEvents’ was not declared in this scope
src/cpp/ewxw_main.cpp: In function ‘void ELJApp_initialize(void*, AppInitFunc, int, void*)’:

src/cpp/ewxw_main.cpp:123:3:
     error: ‘wxPendingEvents’ was not declared in this scope
cabal: Error: some packages failed to install:
wx-0.13.2.1 depends on wxcore-0.13.2.1 which failed to install.
wxcore-0.13.2.1 failed during the building phase. The exception was:
ExitFailure 1


I hope I've provided enough information to help you get a sense of the problem.
Thanks for your time,

Michael Sorhaindo.

[wxhaskell-users] a bit more wxHaskell/OS X progress

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

Hi all,

I'm pleased to report that Dave Tapley's recent wxHaskell branch works on MacOS X Lion with GHC 7.0.x with a couple of minor patches.

My branch of his patch here:
  http://darcsden.com/kowey/wxhaskell-osx64-dave

I had an older branch based off older code (wxhaskell-osx64), which I'll delete after a while.
Hopefully this will reduce amount of merging we need to worry about.

Some users have reported needing to make modifications to build with GHC 7.4.  It might be
good to see if you need them with this new branch, and maybe send them along.

Thanks,

-- 
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...>]

On 9 Mar 2012, at 09:42, Frodo Kenny wrote:

> This could be the problem that the "install-name" of a shared library
> on the mac needs to be set to the correct absolute path to be able to
> link.
> I encountered the same problem with the shared library version of
> wxHaskell from Dave's branch (allowing ghci to work with wx!). That
> version is working on my mac with wx2.9.3 for Xcode 4.2. I explained
> the required fixes here :


I had forgotten to actually push the modified versions of the patches for wxcore/Setup.hs
(and another patch)

Basically it was vainly trying to link against libwxmsw29ud_xrc (windows wxWidgets libs) instead of the equivalent Mac versions

Not sure if that alone resolves Doaitse's issue though.

Sorry for the resulting noise and confusion!

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

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

[Frodo K. <fro...@gm...>]

This could be the problem that the "install-name" of a shared library
on the mac needs to be set to the correct absolute path to be able to
link.
I encountered the same problem with the shared library version of
wxHaskell from Dave's branch (allowing ghci to work with wx!). That
version is working on my mac with wx2.9.3 for Xcode 4.2. I explained
the required fixes here :

http://sourceforge.net/mailarchive/forum.php?thread_name=CAD3si9i_Hr5J36FanSTwdFHVkRPjxsC5Far0M_Zm5JBdeeKZgg%40mail.gmail.com&forum_name=wxhaskell-devel

Note that the attachments stop the text from being shown, so see the
replies for the actual mails.

Kenneth

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

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

Hi,

On 7 Mar 2012, at 15:39, S D Swierstra wrote:
> 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

Hmm, what does
  wx-config --libs --cppflags
say?

For comparison, mine is
-I/usr/local/Cellar/wxmac2.9/2.9.2/lib/wx/include/osx_cocoa-unicode-2.9 -I/usr/local/Cellar/wxmac2.9/2.9.2/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__
-L/usr/local/Cellar/wxmac2.9/2.9.2/lib   -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL -framework QuickTime -lwx_osx_cocoau_xrc-2.9 -lwx_osx_cocoau_html-2.9 -lwx_osx_cocoau_qa-2.9 -lwx_osx_cocoau_adv-2.9 -lwx_osx_cocoau_core-2.9 -lwx_baseu_xml-2.9 -lwx_baseu_net-2.9 -lwx_baseu-2.9 

I think it's perfectly normal that the filenames are prefixed by 'lib'

Is there any chance that you have an old wx-config lying around that's more easily reached than the 2.9 Cocoa one?

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