wxhaskell-devel — wxhaskell developers

[wxhaskell-devel] Release 0.91?

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

L.S.,

I think it is about time to release wxHaskell 0.91, as the current release  
does not support wxWidgets 3.0 and wxWidgets 3.0.1 is much better than  
wxWidgets 2.9.5.

If no one objects, I will release wxHaskell 0.91 two weeks from now.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] trying to build on Maverick

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

I'm afraid I haven't looked into it recently.
I thought I saw some general dev activity on the list/tracker though.


On 13 June 2014 15:00, Matthias Bry <mat...@gm...> wrote:
> Hi Eric,
>
>
> Eric Kow <eric.kow@...> writes:
>
>> It *builds* for me with a hand-installed wxWidgets 2.9.5
> (...)
>> If I comment out the GHCiSupport code in wxcore, I can link, but
>> running the program I get this:
>>
>> dyld: Symbol not found: __ZThn912_N12wxHtmlWindow13GetHTMLWindowEv
>>   Referenced from:
>>/Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/
>>x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
>>   Expected in: flat namespace
>>  in
>>/Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/
>>x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
>> Trace/BPT trap: 5Hi Eric,
>
> did you happen to achieve anything eventually?
> I'm currently exactly at the same point as you in the quote above.
> Did you manage to compile BouncingBalls?
>
> For information, I'm running Mavericks with
> wxWidgets 2.9.5 compiled and installed by hand successfully
> (after removing some weird characters in python scripts)
> and installing wxHaskell by
>
>  cabal install wx cabal-macosx
>
> Thanks in advance,
>
> Matthias Bry
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

Re: [wxhaskell-devel] trying to build on Maverick

[Matthias B. <mat...@gm...>]

Hi Eric,


Eric Kow <eric.kow@...> writes:

> It *builds* for me with a hand-installed wxWidgets 2.9.5
(...)
> If I comment out the GHCiSupport code in wxcore, I can link, but
> running the program I get this:
> 
> dyld: Symbol not found: __ZThn912_N12wxHtmlWindow13GetHTMLWindowEv
>   Referenced from:
>/Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/
>x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
>   Expected in: flat namespace
>  in
>/Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/
>x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
> Trace/BPT trap: 5Hi Eric,

did you happen to achieve anything eventually? 
I'm currently exactly at the same point as you in the quote above. 
Did you manage to compile BouncingBalls?

For information, I'm running Mavericks with
wxWidgets 2.9.5 compiled and installed by hand successfully
(after removing some weird characters in python scripts) 
and installing wxHaskell by

 cabal install wx cabal-macosx 

Thanks in advance,

Matthias Bry

[wxhaskell-devel] Pull request 2

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

L.S.,

Did someone check the current pull request for wxHaskell on GitHub[0]? If  
no one objects, I will apply this patch a week from now.

Regards,
Henk-Jan van Tuyl



[0] https://github.com/wxHaskell/wxHaskell/pull/2/files



-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

[wxhaskell-devel] Installing under GHC 7.8.2 and wxWidgets 3.0.0.0

[Charles t. H. <cha...@ya...>]

Perhaps this will save someone some time.  These are the current 
versions in Arch Linux.  I had to make a few changes but it installed 
and I can link to it and produce runnable programs.

wxdirect/wxdirect.cabal:  Remove the upper version limit on "process" in 
the build depends

wxc/Setup.hs:  Line 238:  Remove the "2.9" from wxAcceptableVersions.  
Otherwise, I got:
Warning: No config found to match: /usr/bin/wx-config --version=2.9 
--version-full
           in /usr/lib/wx/config
...
readProcess failed: ...
setup: failed

I'm just learning Haskell but I don't think that section of code is 
working as intended.

wxcore/wxcore.cabal:  Remove the upper version limit on "array" in the 
build depends

wx installed without modification.

Re: [wxhaskell-devel] Bug ticket 85

[Atze D. <at...@uu...>]

I agree, better go forward,

regards,
Atze

On  23 Mar, 2014, at 18:16 , Henk-Jan van Tuyl <hj...@ch...> wrote:

> 
> L.S.,
> 
> To solve bug ticket 85 [0], I plan to change wxHaskell, so that GCC >= 4.5  
> must be used on Windows, instead of GCC < 4.5. As GCC 4.5 is already quite  
> old, I think we can drop the support for older versions. Is anyone opposed  
> to that?
> 
> Regards,
> Henk-Jan van Tuyl
> 
> 
> [0] http://sourceforge.net/p/wxhaskell/bugs/85/
> 
> 
> -- 
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
> 
> 
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: at...@uu... ............... /   |___\

[wxhaskell-devel] Bug ticket 85

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

L.S.,

To solve bug ticket 85 [0], I plan to change wxHaskell, so that GCC >= 4.5  
must be used on Windows, instead of GCC < 4.5. As GCC 4.5 is already quite  
old, I think we can drop the support for older versions. Is anyone opposed  
to that?

Regards,
Henk-Jan van Tuyl


[0] http://sourceforge.net/p/wxhaskell/bugs/85/


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

[wxhaskell-devel] ANNOUNCE: wxHaskell 0.90.1.0

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

L.S.,

I am happy to announce a new version of wxHaskell. This version binds to  
wxWidgets 2.9 [0].


What is it?
-----------
wxHaskell is a portable and native GUI library for Haskell. The goal of  
the project is to provide an industrial strength GUI library for Haskell,  
but without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore built on top of wxWidgets – a comprehensive C++  
library that is portable across all major GUI platforms; including GTK,  
Windows, X11, and MacOS X. Furthermore, it is a mature library (in  
development since 1992) that supports a wide range of widgets with the  
native look-and-feel.


What's new?
-----------
  - Added functionality: wxGrid: cell spans, cell renderers (numeric, auto  
string wrapping),
    wxScrolledWindow, wxSplitterWindow
  - Reanimated wxToggleButton, added wxBitmapToggleButton
  - Solved problem with spaces in pathnames (installation procedure,  
Windows)
  - Increased max version of dependencies
  - The external preprocessor (CPP) is now used
  - The presence of the wx-config executable is checked at installation time
  - The bitness of the wxWidgets dynamic libraries is compared to the  
bitness of the wxHaskell libraries
    to generate, at installation time; a warning is given when the bitness  
is incompatible
  - Documentation improvements
  - Bugs fixed


Links
-----
See the homepage of wxHaskell for more information:
   https://www.haskell.org/haskellwiki/WxHaskell

The packages are:
  - wxc       https://hackage.haskell.org/package/wxc
  - wxdirect  https://hackage.haskell.org/package/wxdirect
  - wxcore    https://hackage.haskell.org/package/wxcore
  - wx        https://hackage.haskell.org/package/wx

Regards,
Henk-Jan van Tuyl


[0] https://www.wxwidgets.org/


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] Let's release the current wxHaskell

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

On Sat, 22 Feb 2014 00:54:03 +0100, Henk-Jan van Tuyl <hj...@ch...>
wrote:

> I think we can release the current wxHaskell on Hackage and go on with
> wxWidgets 3.0.0 without branching on GitHub. If someone adds me to the
> list of maintainers (for the packages wxdirect, wxc, wxcore and wx) on
> Hackage, I will do this myself. My account on Hackage is HenkJanVanTuyl.
>
> The main advantage of this release is that this version installs properly
> on Windows.

As there is no response yet,  I suggest to tag the current version on
GitHub as version 0.90.1.0 and continue with 0.91.0.0

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] using graphicscontext inside a paint event

[Kristof B. <kr...@re...>]

On 10-03-14 14:13, Henk-Jan van Tuyl wrote:
> On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen 
> <kr...@re...> wrote:
>
>> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't
>> allow
>> me to create a graphicscontext from a paint event.
> :
> :
>> I am willing to help coding this functionality.
>
> It's always great if someone is willing to help improve wxHaskell, but 
> I can't say anything about this, until I have done some studying on 
> the subject.
>
I see.  I am coding this up because I really need it, but feedback
is welcome of course.  My final version is here:

https://github.com/kuribas/wxHaskell

If you like it I'll put a pull request.

I basically have this, plus helper functions (there was no wxGCDC API).
paintGc is new, and the type for paintRaw has changed:

class Paint w where
   -- | Paint double buffered to a device context. The context is always
   -- cleared before drawing. Takes the current view rectangle (adjusted
   -- for scrolling) as an argument.
   paint     :: Event w (DC () -> Rect -> IO ())
   -- | Paint directly to the on-screen device context. Takes the current
   -- view rectangle and a list of dirty rectangles as arguments.\
   paintRaw  :: Event w (PaintDC () -> Rect -> [Rect] -> IO ())
   -- | Paint double buffered to a 'GCDC' device context, for
   -- anti-aliased drawing. The context is always cleared before
   -- drawing. Takes the current view rectangle (adjusted for
   -- scrolling) as an argument.
   paintGc   :: Event w (GCDC () -> Rect -> IO ())
   -- | Emit a paint event to the specified widget.
   repaint   :: w -> IO ()

The change of type for the paintRaw event shouldn't pose compatibility
problems in most cases, otherwise it would be as simple as changing
the type from (DC ()) to (DC a).

Kristof

Re: [wxhaskell-devel] using graphicscontext inside a paint event

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

On Sun, 09 Mar 2014 20:10:28 +0100, Kristof Bastiaensen  
<kr...@re...> wrote:

> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't
> allow
> me to create a graphicscontext from a paint event.
:
:
> I am willing to help coding this functionality.

It's always great if someone is willing to help improve wxHaskell, but I  
can't say anything about this, until I have done some studying on the  
subject.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] using graphicscontext inside a paint event

[Kristof B. <kr...@re...>]

I have made some changes on my github fork, which I like better:

paintRaw now has type:
paintRaw  :: Event w (PaintDC () -> Rect -> [Rect] -> IO ())

So you can use "graphicsContextCreate paintDC".
I removed my new handler paintRawContext, since it isn't needed.
This should be mostly compatible with old code, since (PaintDC ())
should work with (DC a)

I currently have:
paintContext :: Event w (DC () -> GraphicsContext () -> Rect -> IO ())

Maybe it would be better to have the following handler?
paintGcdc :: Event w (GCDC () -> Rect -> IO ())

I have read that gcdc implements anti-aliasing, but I didn't try it yet...

I also duplicated the code of dcBufferWithRefEx to take an extra 
graphicscontext
argument, but I'd like to find a way to tidy that up...

Regards,
Kristof

On 09-03-14 23:21, Kristof Bastiaensen wrote:
> I implemented this idea of adding a new paint event handler:
> https://github.com/kuribas/wxHaskell/commit/a779f8e7e34fe03822f380c4cdd1aa8a9ed97e81
>
> I could be tidied up, because I duplicated a lot of code...
>
> Regards,
> Kristof Bastiaensen
>
> On 09-03-14 20:10, Kristof Bastiaensen wrote:
>> Hi,
>>
>> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't
>> allow
>> me to create a graphicscontext from a paint event.
>>
>> The reason is the type of the function:
>>
>> graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ())
>>
>> while the paint event callback takes a DC () as argument, which is more
>> general.  It seem wxwidgets needs to know the type of the DC to create
>> a graphicscontext.  Also wxwidgets 2.8 doesn't have a function to create
>> one from a  memoryDC, but 3.0 has.
>>
>> One solution I came up with would be to replace DC () in the paint-event
>> to  MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw
>> event.  This callback would also work with a more general function.
>> Unfortunately it fails on Mac-OS since no memoryDc is used in the paint
>> callback.
>>
>> And it still feels like a low level solution, it would be nicer to have
>> a higher level
>> API that can abstract away these problems.  Maybe making a new paint
>> callback that already includes the graphiccontext?  Also creating a
>> graphicspath from a haskell datatype would be nice.
>>
>> I am willing to help coding this functionality.
>>
>> Regards,
>> Kristof Bastiaensen
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] using graphicscontext inside a paint event

[Kristof B. <kr...@re...>]

I implemented this idea of adding a new paint event handler:
https://github.com/kuribas/wxHaskell/commit/a779f8e7e34fe03822f380c4cdd1aa8a9ed97e81

I could be tidied up, because I duplicated a lot of code...

Regards,
Kristof Bastiaensen

On 09-03-14 20:10, Kristof Bastiaensen wrote:
> Hi,
>
> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't
> allow
> me to create a graphicscontext from a paint event.
>
> The reason is the type of the function:
>
> graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ())
>
> while the paint event callback takes a DC () as argument, which is more
> general.  It seem wxwidgets needs to know the type of the DC to create
> a graphicscontext.  Also wxwidgets 2.8 doesn't have a function to create
> one from a  memoryDC, but 3.0 has.
>
> One solution I came up with would be to replace DC () in the paint-event
> to  MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw
> event.  This callback would also work with a more general function.
> Unfortunately it fails on Mac-OS since no memoryDc is used in the paint
> callback.
>
> And it still feels like a low level solution, it would be nicer to have
> a higher level
> API that can abstract away these problems.  Maybe making a new paint
> callback that already includes the graphiccontext?  Also creating a
> graphicspath from a haskell datatype would be nice.
>
> I am willing to help coding this functionality.
>
> Regards,
> Kristof Bastiaensen
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] using graphicscontext inside a paint event

[Kristof B. <kr...@re...>]

Hi,

I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't 
allow
me to create a graphicscontext from a paint event.

The reason is the type of the function:

graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ())

while the paint event callback takes a DC () as argument, which is more
general.  It seem wxwidgets needs to know the type of the DC to create
a graphicscontext.  Also wxwidgets 2.8 doesn't have a function to create
one from a  memoryDC, but 3.0 has.

One solution I came up with would be to replace DC () in the paint-event
to  MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw
event.  This callback would also work with a more general function.
Unfortunately it fails on Mac-OS since no memoryDc is used in the paint 
callback.

And it still feels like a low level solution, it would be nicer to have 
a higher level
API that can abstract away these problems.  Maybe making a new paint
callback that already includes the graphiccontext?  Also creating a
graphicspath from a haskell datatype would be nice.

I am willing to help coding this functionality.

Regards,
Kristof Bastiaensen

Re: [wxhaskell-devel] Let's release the current wxHaskell

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

On Sat, 22 Feb 2014 17:21:58 +0100, Conal Elliott <co...@co...> wrote:

> I'm always glad to hear of wxHaskell activity. Has there been any  
> progress
> on the wxHaskell-vs-ghci issue  
> <http://sourceforge.net/p/wxhaskell/bugs/84/>?
> -- Conal

Not as far as I know; I hope someone else can handle this soon. My  
personal priorities are:
  - Getting a reasonably reliable wxHaskell (for wxWidgets 3.0)
  - Making wxHaskell easy to compile and/or creating binary packages,
    so that more people start using wxHaskell and eventually participate in  
the development

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] Let's release the current wxHaskell

[Conal E. <co...@co...>]

I'm always glad to hear of wxHaskell activity. Has there been any progress
on the wxHaskell-vs-ghci issue <http://sourceforge.net/p/wxhaskell/bugs/84/>?
-- Conal


On Fri, Feb 21, 2014 at 3:54 PM, Henk-Jan van Tuyl <hj...@ch...>wrote:

>
> L.S.,
>
> I think we can release the current wxHaskell on Hackage and go on with
> wxWidgets 3.0.0 without branching on GitHub. If someone adds me to the
> list of maintainers (for the packages wxdirect, wxc, wxcore and wx) on
> Hackage, I will do this myself. My account on Hackage is HenkJanVanTuyl.
>
> The main advantage of this release is that this version installs properly
> on Windows.
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

Re: [wxhaskell-devel] Let's release the current wxHaskell

[Atze D. <at...@uu...>]

LS.,

Adding new maintainers to the maintainer group for wx on Hackage has to be done by Jeremy O'Donoghue as he still is the main maintainer as far as Hackage is concerned. Please add me (Hackage account AtzeDijkstra) too.

regards,
Atze Dijkstra

On  22 Feb, 2014, at 00:54 , Henk-Jan van Tuyl <hj...@ch...> wrote:

> 
> L.S.,
> 
> I think we can release the current wxHaskell on Hackage and go on with  
> wxWidgets 3.0.0 without branching on GitHub. If someone adds me to the  
> list of maintainers (for the packages wxdirect, wxc, wxcore and wx) on  
> Hackage, I will do this myself. My account on Hackage is HenkJanVanTuyl.
> 
> The main advantage of this release is that this version installs properly  
> on Windows.
> 
> Regards,
> Henk-Jan van Tuyl
> 
> 
> -- 
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
> 
> 
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: at...@uu... ............... /   |___\

[wxhaskell-devel] Let's release the current wxHaskell

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

L.S.,

I think we can release the current wxHaskell on Hackage and go on with  
wxWidgets 3.0.0 without branching on GitHub. If someone adds me to the  
list of maintainers (for the packages wxdirect, wxc, wxcore and wx) on  
Hackage, I will do this myself. My account on Hackage is HenkJanVanTuyl.

The main advantage of this release is that this version installs properly  
on Windows.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] wxWidgets on github

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

On Wed, 29 Jan 2014 15:23:33 +0100, Alex Rozenshteyn  
<rpg...@gm...> wrote:

> Hello,
>
> I am under the impression that wxHaskell is being (more or less) actively
> developed at https://github.com/wxHaskell/wxHaskell and that you are the
> primary developer. I am emailing you directly because there appears to be
> no publicly accessible issues list on that repository, and because I  
> would
> like to file an issue. Namely, I just compiled the source with wxWidgets
> 3.0 (which is packaged in debian) instead of 2.9 (which is not) and
> everything seems to work just fine.
>
> I hacked this up by changing the required version, but there's probably a
> better way that allows either 2.9 or 3.0.

You can use
   http://sourceforge.net/p/wxhaskell/_list/tickets
for bugs and feature requests, for Support Requests it is better to use  
the wxHaskell users list[0] or wxHaskell developer list[1].

wxHaskell does not work reliably with wxWidgets 3.0.0 on Windows or OS X.  
I hope someone can tell us that wxHaskell works fine with wxWidgets 2.9.5  
on OS X, so that we can release the current wxHaskell on Hackage and go on  
with wxWidgets 3.0.0 without branching on GitHub.

Regards,
Henk-Jan van Tuyl

[0] https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[1] https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

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

On Fri, 03 Jan 2014 16:08:45 +0100, Mark <hs...@be...> wrote:

> Henk-Jan van Tuyl <hjgtuyl@...> writes:
>
>>
>> On Mon, 18 Nov 2013 16:23:25 +0100, Henk-Jan van Tuyl
>> <hjgtuyl@...>
>> wrote:
>>
>
>> I spoke too soon, the setup of wxc contains a version number (2.9); I  
>> will
>> try to get things working for both 2.9 and 3.0.
>>
>
>
> Any progress on this.(Macports does not supply wx Widgets 2.9 anymore  
> just 3.0)
>
> Thanks
> Mark

I hoped that someone could tell me that wxHaskell works fine with  
wxWidgets 2.9.5 on OS X, so that we can release the current version. (The  
most recent version of wxHaskell on Hackage does not compile on Windows.)  
For wxWidgets 3.0, there are several updates necessary; debugging is  
however an enormous amount of work, as long as wxHaskell does not run  
within GHCi. The scientific way to update wxHaskell would be to study all  
changes in wxWidgets, but that is also an enormous amount of work.

For proper debugging it would be an big improvement, if we had a debugger  
that would step through both Haskell and C/C++ code.

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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

Re: [wxhaskell-devel] New Stable Major wxWidgets 3.0.0 Release

[Mark <hs...@be...>]

Henk-Jan van Tuyl <hjgtuyl@...> writes:

> 
> On Mon, 18 Nov 2013 16:23:25 +0100, Henk-Jan van Tuyl
> <hjgtuyl@...>  
> wrote:
> 

> I spoke too soon, the setup of wxc contains a version number (2.9); I will  
> try to get things working for both 2.9 and 3.0.
> 


Any progress on this.(Macports does not supply wx Widgets 2.9 anymore just 3.0)

Thanks
Mark

Re: [wxhaskell-devel] Is wxHaskell tested on Linux, OS X?

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

With apologies for breaking the thread, I've started commenting my
progress on http://thread.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/993

which is specific to the current version of MacOS X which I am using
(10.9), had recently upgraded.


On 5 December 2013 22:58, Henk-Jan van Tuyl <hj...@ch...> wrote:
> On Thu, 05 Dec 2013 14:24:44 +0100, Eric Kow <eri...@gm...> wrote:
>
>> I have Ubuntu 12.04 users with hand-compiled wxWidgets 2.9.5 using
>> current wxHaskell HEAD (2f065e5348343ab95ad3f1465af2619d31bcdf37)
>>
>> I was using something similar on MacOSX 10.7 (Lion), but now that I've
>> upgraded to 10.9, I do seem to have some breakage.  Part of it is
>> confusing though because I also figured I'd try building against
>> wxWidgets 3.0 (with some tweaks to wxHaskell src to allow for this).
>>
>> So on 10.7 OK, on 10.9 still having runtime linker error
>>
>
> I have experienced problems with wxWidget 3.0 as well; it seems that some
> extra updates are necessary. Could you test wxHaskell with wxWidgets 2.9.5
> on OS X? If that works, we can release wxHaskell for wxWidgets 2.9 and start
> working on a new release for wxWidgets 2.9 + 3.0
>
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --



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

Re: [wxhaskell-devel] trying to build on Maverick

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

Hi Andrew,

Well I'm a bit further along, but not by much.
It *builds* for me with a hand-installed wxWidgets 2.9.5 (in stow) and
the current Git wxHaskell (2f065e53), but when I try to build a sample
program, I get this linker error

ghc -package-db
../../.cabal-sandbox/x86_64-osx-ghc-7.6.3-packages.conf.d -package wx
-o BouncingBalls BouncingBalls.hs
Linking BouncingBalls ...
Undefined symbols for architecture x86_64:
  "_CPSSignalAppReady", referenced from:
      _s7vsd_info in libHSwxcore-0.90.1.0.a(GHCiSupport.o)
ld: symbol(s) not found for architecture x86_64

If I comment out the GHCiSupport code in wxcore, I can link, but
running the program I get this:

dyld: Symbol not found: __ZThn912_N12wxHtmlWindow13GetHTMLWindowEv
  Referenced from:
/Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
  Expected in: flat namespace
 in /Users/kowey/ETC/haskell/wxHaskell/.cabal-sandbox/lib/x86_64-osx-ghc-7.6.3/wxc-0.90.1.0/libwxc.dylib
Trace/BPT trap: 5



On 18 December 2013 15:30, Andrew Butterfield
<And...@sc...> wrote:
> Hi all,
>   first apologies - my last post here was to say I would try and build on
> Windows 7 and give feedback to improve
> the build instructions - that was over a year ago, and then I got hit by a
> work tsunami…
>
> I’m back now, and with a Macbook Pro available as build experiment machine,
> trying to see if I can install it here
>  It tried the approach on  http://www.haskell.org/haskellwiki/WxHaskell/Mac
>
> It failed with
> ——————
> src/cpp/eljgrid.cpp:61:65: error: too few arguments to function call,
> expected
>       3, have 2
>         self->PaintBackground(wxRect(x, y, w, h), (wxGridCellAttr*)attr);
>         ~~~~~~~~~~~~~~~~~~~~~                                          ^
> ———————
> Checking messages suggest I go to the github repo and use that,
> so on to Attempt 2.
>
> Attempt 2 -
> Mac OS X : 10.9.1
> GHC: 7.6.2 (Platform 2013.2.0.0)
> Xcode 5.0.2
> :- which gcc
> /usr/bin/gcc
> :- which cpp
> /usr/bin/cpp
> :- which clang
> /usr/bin/clang
>
>
> Cloned from https://github.com/wxHaskell/wxHaskell
> :
> bin/mk-devel  fails
> I see from the log that both gcc and clang get used at different places in
> the build.
> Is this the clang issue that requires the workaround posted recently?
>
> Or is there something different going on ?
>
> Log file attached
>
>
> Regards
>
> Andrew Butterfield
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>



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

[wxhaskell-devel] trying to build on Maverick

[Andrew B. <And...@sc...>]

Hi all,
  first apologies - my last post here was to say I would try and build on Windows 7 and give feedback to improve
the build instructions - that was over a year ago, and then I got hit by a work tsunami…

I’m back now, and with a Macbook Pro available as build experiment machine, trying to see if I can install it here
 It tried the approach on  http://www.haskell.org/haskellwiki/WxHaskell/Mac

It failed with
——————
src/cpp/eljgrid.cpp:61:65: error: too few arguments to function call, expected
      3, have 2
        self->PaintBackground(wxRect(x, y, w, h), (wxGridCellAttr*)attr);
        ~~~~~~~~~~~~~~~~~~~~~                                          ^
———————
Checking messages suggest I go to the github repo and use that,
so on to Attempt 2.

Attempt 2 - 
Mac OS X : 10.9.1
GHC: 7.6.2 (Platform 2013.2.0.0)
Xcode 5.0.2
:- which gcc
/usr/bin/gcc
:- which cpp
/usr/bin/cpp
:- which clang
/usr/bin/clang


Cloned from https://github.com/wxHaskell/wxHaskell
:
bin/mk-devel  fails
I see from the log that both gcc and clang get used at different places in the build.
Is this the clang issue that requires the workaround posted recently?

Or is there something different going on ?

Log file attached 

Regards

Andrew Butterfield

Re: [wxhaskell-devel] Is wxHaskell tested on Linux, OS X?

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

On Thu, 05 Dec 2013 14:24:44 +0100, Eric Kow <eri...@gm...> wrote:

> I have Ubuntu 12.04 users with hand-compiled wxWidgets 2.9.5 using
> current wxHaskell HEAD (2f065e5348343ab95ad3f1465af2619d31bcdf37)
>
> I was using something similar on MacOSX 10.7 (Lion), but now that I've
> upgraded to 10.9, I do seem to have some breakage.  Part of it is
> confusing though because I also figured I'd try building against
> wxWidgets 3.0 (with some tweaks to wxHaskell src to allow for this).
>
> So on 10.7 OK, on 10.9 still having runtime linker error
>

I have experienced problems with wxWidget 3.0 as well; it seems that some  
extra updates are necessary. Could you test wxHaskell with wxWidgets 2.9.5  
on OS X? If that works, we can release wxHaskell for wxWidgets 2.9 and  
start working on a new release for wxWidgets 2.9 + 3.0

Regards,
Henk-Jan van Tuyl


-- 
Folding@home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


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