wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] Windows 7 GetCommandLine call interference

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

On Sat, 04 Apr 2015 21:19:43 +0200, Michael Jones <mi...@pr...>  
wrote:

> I have made a solution to the args problem. To review, if the latest  
> code on github is used on Ubuntu, and if agreements are passed on the  
> command line of the application, wxHaskell does a “getArgs” and passes  
> them on, and then there is an error on the command line. On Windows with  
> the most recent wxWidgets code, it pops a similar dialog.
>
> To get around the problem, I created startExt, runExt, and argsOnInitExt  
> so that I can pass a [String]. This allows me to filter out agreements  
> not destined for wx.
>
> I have attached a patch below to show what I did.
>
> Perhaps one of the developers can give this some consideration. I can  
> certainly post the patch in the bug tracker if desired, just tell me  
> where it is. I am not sure if the one on source forge is in use or not,  
> as the last date is Aug 2014.

The bug tracker on SourceForge is still in use, it has been quiet for a  
while in wxHaskell world.

The patch is not the solution, I wish it were that simple. GHC's run time  
system filters out the RTS parameters, this can be demonstrated with the  
following program (Arguments.hs):

> import System.Environment
>
> main = getArgs >>= print

The command
   Arguments x +RTS -RTS y
results in:
   ["x","y"]

wxWidgets (at least on Windows) does not use the arguments that are passed  
with wxcAppInitializeC, but reads directly from the argument buffer.

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-users] Windows 7 GetCommandLine call interference

[Michael J. <mi...@pr...>]

I have made a solution to the args problem. To review, if the latest code on github is used on Ubuntu, and if agreements are passed on the command line of the application, wxHaskell does a “getArgs” and passes them on, and then there is an error on the command line. On Windows with the most recent wxWidgets code, it pops a similar dialog.

To get around the problem, I created startExt, runExt, and argsOnInitExt so that I can pass a [String]. This allows me to filter out agreements not destined for wx.

I have attached a patch below to show what I did.

Perhaps one of the developers can give this some consideration. I can certainly post the patch in the bug tracker if desired, just tell me where it is. I am not sure if the one on source forge is in use or not, as the last date is Aug 2014.

Mike

From 13bd27df2e54972244a59fc38eccc7b9790a176c Mon Sep 17 00:00:00 2001
From: Michael Jones <mj...@li...>
Date: Sat, 4 Apr 2015 13:10:49 -0600
Subject: [PATCH] Offer command line args passing at startup

---
 wx/src/Graphics/UI/WX.hs                        |  5 +++++
 wxcore/src/haskell/Graphics/UI/WXCore.hs        | 10 +++++++++-
 wxcore/src/haskell/Graphics/UI/WXCore/Events.hs | 14 +++++++++++++-
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/wx/src/Graphics/UI/WX.hs b/wx/src/Graphics/UI/WX.hs
index f310e63..7827b2f 100644
--- a/wx/src/Graphics/UI/WX.hs
+++ b/wx/src/Graphics/UI/WX.hs
@@ -17,6 +17,7 @@ functionality provided by the "Graphics.UI.WXCore" library.
 module Graphics.UI.WX
   ( -- * Functions
     start
+  , startExt
     -- * Modules
   , module Graphics.UI.WX.Types
   , module Graphics.UI.WX.Attributes
@@ -58,3 +59,7 @@ import Graphics.UI.WXCore
 start :: IO a -> IO ()
 start io
   = run (unitIO io)
+
+startExt :: [String] -> IO a -> IO ()
+startExt args io
+  = runExt args (unitIO io)
\ No newline at end of file
diff --git a/wxcore/src/haskell/Graphics/UI/WXCore.hs b/wxcore/src/haskell/Graphics/UI/WXCore.hs
index a6381b2..b276433 100644
--- a/wxcore/src/haskell/Graphics/UI/WXCore.hs
+++ b/wxcore/src/haskell/Graphics/UI/WXCore.hs
@@ -40,6 +40,7 @@ module Graphics.UI.WXCore
 
         -- * Run
         , run
+        , runExt
         ) where
 
 import System.Mem( performGC )
@@ -77,6 +78,13 @@ run init
        performGC
        performGC
 
-
+runExt :: [String] -> IO a -> IO ()
+runExt args init
+  = do enableGUI
+       appOnInitExt args (do wxcAppInitAllImageHandlers
+                             init
+                             return ())
+       performGC
+       performGC
 
 
diff --git a/wxcore/src/haskell/Graphics/UI/WXCore/Events.hs b/wxcore/src/haskell/Graphics/UI/WXCore/Events.hs
index 12ca0a3..668761a 100644
--- a/wxcore/src/haskell/Graphics/UI/WXCore/Events.hs
+++ b/wxcore/src/haskell/Graphics/UI/WXCore/Events.hs
@@ -222,6 +222,7 @@ module Graphics.UI.WXCore.Events
 
         -- * Primitive
         , appOnInit
+        , appOnInitExt
 
         -- ** Client data
         , treeCtrlSetItemClientData
@@ -2820,7 +2821,18 @@ appOnInit init
   where
     onDelete ownerDeleted
       = init
-           
+          
+appOnInitExt :: [String] -> IO () -> IO ()
+appOnInitExt args init
+  = do closure  <- createClosure (return () :: IO ()) onDelete (\ev -> return ())   -- run init on destroy !
+       progName <- getProgName
+       argv     <- mapM newCWString (progName:args)
+       let argc = length argv
+       withArray (argv ++ [nullPtr]) $ \cargv -> wxcAppInitializeC closure argc cargv
+       mapM_ free argv
+  where
+    onDelete ownerDeleted
+      = init 
 
 
 ------------------------------------------------------------------------------------------
-- 
1.9.1



On Mar 28, 2015, at 7:58 PM, Michael Jones <mi...@pr...> wrote:

> 
> I also notice that if I use the git repo:head for wxHaskell on Linux, I get a similar error + Usage as windows, but on the command line. The version of wxHaskell that cabal fetches does not have this problem.
> 
> On windows, I took the repo:head because the released wxHaskell that cabal downloads had a compile failure for a ‘long long’
> 
> So perhaps there something that has changed in wxHaskell that causes a generic problem.
> 
> 
> 
> On Mar 28, 2015, at 7:40 PM, Michael Jones <mi...@pr...> wrote:
> 
>> There is a response from wxWidgets trac
>> 
>> #16935:
>> http://trac.wxwidgets.org/ticket/16935#comment:1
>> 
>> On Mar 28, 2015, at 5:12 PM, Henk-Jan van Tuyl <hj...@ch...> wrote:
>> 
>>> On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones <mi...@pr...>
>>> wrote:
>>> 
>>>> On Win 7...
>>>> 
>>>> The latest code on github seems to result in a wxWidgets call to LPTSTR WINAPI GetCommandLine(void);
>>>> 
>>>> This results in popping a dialog complaining about command options. On Linux this does not happen. Looks like wxWidgets is trying to use this call to deal with unicode, but it unfortunately bypasses the Haskell argument mechanism and grabs everything including +/-RTS and passes it to wxWidgets for consideration. Perhaps wxHaskell should manage the arguments and strip off any arguments that are not destined for wxWidgets, or at least let the Haskell code intercept and manage the problem.
>>>> 
>>>> Is there some way to effect the wxHaskell initialization so that it prevents this call, so that an wxHaskell application running on Windows 7 can accept command line arguments properly?
>>>> 
>>>> I handling initialization with a start call within Haskell. Perhaps there is an alternate approach I am unaware of.
>>> 
>>> I am trying to change the internal representation of the command line, but it is likely to fail. The best thing would to let the wxWidgets people change the behavior of wxWidgets to let it be the same in Windows as in Linux. You could write a ticket for this[0]. To be sure this problems isn't forgotten, you should also write a wxHaskell ticket[1], preferably linking to the wxWidgets ticket.
>>> 
>>> The message about the unexpected parameter stems from wxWidgets\src\common\cmdline.cpp , method wxCmdLineParser::Parse(bool showUsage) . Maybe it is possible to specify a wxCmdLineParser, that handles the +RTS parameters correctly, in wxHaskell.
>>> 
>>> Regards,
>>> Henk-Jan van Tuyl
>>> 
>>> 
>>> [0] http://trac.wxwidgets.org/
>>> [1] http://sourceforge.net/p/wxhaskell/_list/tickets
>>> 
>>> -- 
>>> 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
>>> --
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the 
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] TableBase

[Michael J. <mi...@pr...>]

I re-reviewed the wx site, and notice wxdirect generates wxcore. So I am not sure where I would put any new C++ classes that were not part of wxWidgets itself. I guess one could argue for a wxWidgets table class with callbacks and then layering over that.



On Mar 30, 2015, at 3:29 PM, Michael Jones <mi...@pr...> wrote:

>> From my review, I think I would have to create a subclass of wxGridTableBase in C++, wrapper it in C wrapper, then wrapper C in Haskell. And to be general purpose, the subclass would have to make calls into Haskell with some way to register a function, like the way events work in wxHaskell.
> 
> Correct me if there is something I am missing.
> 
> And if I create this subclass, which is not part of wxWidgets source, where would it reside in wxHaskell source tree? I believe wxc is generated by wxdirect. Would it go in the wxcore tree as a subdir of UI/WxCore?
> 
> Mike
> 
> 
> 
> On Mar 30, 2015, at 4:44 AM, Henk-Jan van Tuyl <hj...@ch...> wrote:
> 
>> On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones <mi...@pr...> wrote:
>> 
>>> Is it possible to create a GridTableBase to manage the data rather than use the default created by a Grid?
>>> 
>>> If so, any example code around?
>> 
>> I downloaded all reverse dependencies of wx from Hackage, but they do not use GridTableBase, neither do the samples on GitHub. There is, however, a C++ sample program (griddemo) included in the wxWidgets source. WxHaskell is a huge library and much of it is uncharted territory, you will probably be the first to use GridTableBase in a Haskell program. It would be great if you could add a sample program to wxHaskell.
>> 
>> 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
>> --
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] TableBase

[Michael J. <mi...@pr...>]

From my review, I think I would have to create a subclass of wxGridTableBase in C++, wrapper it in C wrapper, then wrapper C in Haskell. And to be general purpose, the subclass would have to make calls into Haskell with some way to register a function, like the way events work in wxHaskell.

Correct me if there is something I am missing.

And if I create this subclass, which is not part of wxWidgets source, where would it reside in wxHaskell source tree? I believe wxc is generated by wxdirect. Would it go in the wxcore tree as a subdir of UI/WxCore?

Mike



On Mar 30, 2015, at 4:44 AM, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones <mi...@pr...> wrote:
> 
>> Is it possible to create a GridTableBase to manage the data rather than use the default created by a Grid?
>> 
>> If so, any example code around?
> 
> I downloaded all reverse dependencies of wx from Hackage, but they do not use GridTableBase, neither do the samples on GitHub. There is, however, a C++ sample program (griddemo) included in the wxWidgets source. WxHaskell is a huge library and much of it is uncharted territory, you will probably be the first to use GridTableBase in a Haskell program. It would be great if you could add a sample program to wxHaskell.
> 
> 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-users] installation problem on Win 8.1, WXCFG

[Van V. C. <Chr...@UR...>]

You could also look at the powershell scripts I have here.  

https://github.com/cessationoftime/wxHaskell-Windows-Builder

They are designed to build wxWidgets and wxHaskell on Windows. And there are 32 and 64 bit versions of them.  The 64 bit version uses MinGW-w64 without issue.  They have only been tested on Windows 7 though.  I don't think I modified the flags in config.gcc for 64 bits though, so I may just have two alternate ways to build 32 bits.



-----Original Message-----
From: Henk-Jan van Tuyl [mailto:hj...@ch...] 
Sent: Saturday, March 28, 2015 10:09 AM
To: wxh...@li...; Andrew Butterfield
Subject: Re: [wxhaskell-users] installation problem on Win 8.1, WXCFG

On Thu, 26 Mar 2015 22:52:14 +0100, Andrew Butterfield <And...@sc...> wrote:

:
> Configuring wxc-0.92.0.0...
>
> Please use the --wxcfg flag (as in wx-config --wxcfg=gcc_dll\mswud)
> or set the environment variable WXCFG (as in WXCFG=gcc_dll\mswud)
> to specify which configuration exactly you want to use.
> readProcess failed: readProcess: wx-config "--version" (exit 1): failed
> setup.exe: failed
> cabal: Error: some packages failed to install:
> wxc-0.92.0.0 failed during the configure step. The exception was:
> ExitFailure 1
> ------ log extract pause ------
>
> How do I fix this? What is going on?
>
> Installed 32-bit Haskell Platform on 64-bit Win 8.1
> (I did that because the instructions talk about mingw32-make)

Did you set WXWIN to the correct value, something like:
   WXWIN=C:\Libs\wxWidgets\3.0.2
?

Another reason why the compilation failed, might be that the configuration  
file specifies a debug build, instead of a release build.

You can build a 64 bit wxHaskell, even though there is a 32 in the name  
mingw32-make; take care that you build wxWidgets with the same bitness. To  
build wxWidgets as 64 bits DLLs, I changed some values in  
build\msw\config.gcc to:

   # Standard flags for CC
   CFLAGS ?= -m64

   # Standard flags for C++
   CXXFLAGS ?= -m64

   # Standard preprocessor flags (common for CC and CXX)
   CPPFLAGS ?= -D_M_AMD64


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.
https://urldefense.proofpoint.com/v2/url?u=http-3A__folding.stanford.edu_&d=AwICAg&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=uHa3P-6nCCMTSWKo6SVyf8SYFCvf99SptA09bTieRUEy2SyD4nufBTQADRVKI_1M&m=ip2ITmeH8JjeaVOP6S7dvYkPY6AK--8BeNlljxOFhbI&s=N1TYQLMct-l6TOc3bOAQE0vc9Yc9drWY5cFKUYGQTm8&e= 


https://urldefense.proofpoint.com/v2/url?u=http-3A__Van.Tuyl.eu_&d=AwICAg&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=uHa3P-6nCCMTSWKo6SVyf8SYFCvf99SptA09bTieRUEy2SyD4nufBTQADRVKI_1M&m=ip2ITmeH8JjeaVOP6S7dvYkPY6AK--8BeNlljxOFhbI&s=F29qCastd4COdxcCiSqWiE3WgvZRUVMIpUQ1JT3n_hc&e= 
https://urldefense.proofpoint.com/v2/url?u=http-3A__members.chello.nl_hjgtuyl_tourdemonad.html&d=AwICAg&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=uHa3P-6nCCMTSWKo6SVyf8SYFCvf99SptA09bTieRUEy2SyD4nufBTQADRVKI_1M&m=ip2ITmeH8JjeaVOP6S7dvYkPY6AK--8BeNlljxOFhbI&s=MTQnPb5MaHzo76s0T5xQRyCQr884T1puiAtJjMyh-2g&e= 
Haskell programming
--

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. https://urldefense.proofpoint.com/v2/url?u=http-3A__goparallel.sourceforge.net_&d=AwICAg&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=uHa3P-6nCCMTSWKo6SVyf8SYFCvf99SptA09bTieRUEy2SyD4nufBTQADRVKI_1M&m=ip2ITmeH8JjeaVOP6S7dvYkPY6AK--8BeNlljxOFhbI&s=FyCdFkCLS4eHm9rBk1b8PYSnzOVGMVBWtaM6gBqUw7M&e= 
_______________________________________________
wxhaskell-users mailing list
wxh...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_wxhaskell-2Dusers&d=AwICAg&c=4sF48jRmVAe_CH-k9mXYXEGfSnM3bY53YSKuLUQRxhA&r=uHa3P-6nCCMTSWKo6SVyf8SYFCvf99SptA09bTieRUEy2SyD4nufBTQADRVKI_1M&m=ip2ITmeH8JjeaVOP6S7dvYkPY6AK--8BeNlljxOFhbI&s=H09v2CGTefNe4Dh3d7S5nFJCHEjffCj1M0uigVqstWw&e= 

Re: [wxhaskell-users] TableBase

[Michael J. <mi...@pr...>]

Ok, but I might have to ask some questions here. I’m a bit green on both. My concern is there are wxc functions with Ptr that I think are basically function callbacks, but I have to know the type signature of them, and that seems to involve some knowledge of wxWidgets and marshaling, etc.

I guess I need to find some documentation on wxHaskell’s methods of interfacing with C. etc.

Mike


On Mar 30, 2015, at 4:44 AM, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones <mi...@pr...> wrote:
> 
>> Is it possible to create a GridTableBase to manage the data rather than use the default created by a Grid?
>> 
>> If so, any example code around?
> 
> I downloaded all reverse dependencies of wx from Hackage, but they do not use GridTableBase, neither do the samples on GitHub. There is, however, a C++ sample program (griddemo) included in the wxWidgets source. WxHaskell is a huge library and much of it is uncharted territory, you will probably be the first to use GridTableBase in a Haskell program. It would be great if you could add a sample program to wxHaskell.
> 
> 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-users] TableBase

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

On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones <mi...@pr...>  
wrote:

> Is it possible to create a GridTableBase to manage the data rather than  
> use the default created by a Grid?
>
> If so, any example code around?

I downloaded all reverse dependencies of wx from Hackage, but they do not  
use GridTableBase, neither do the samples on GitHub. There is, however, a  
C++ sample program (griddemo) included in the wxWidgets source. WxHaskell  
is a huge library and much of it is uncharted territory, you will probably  
be the first to use GridTableBase in a Haskell program. It would be great  
if you could add a sample program to wxHaskell.

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

[wxhaskell-users] TableBase

[Michael J. <mi...@pr...>]

Is it possible to create a GridTableBase to manage the data rather than use the default created by a Grid?

If so, any example code around?

Mike

Re: [wxhaskell-users] Windows 7 GetCommandLine call interference

[Michael J. <mi...@pr...>]

I also notice that if I use the git repo:head for wxHaskell on Linux, I get a similar error + Usage as windows, but on the command line. The version of wxHaskell that cabal fetches does not have this problem.

On windows, I took the repo:head because the released wxHaskell that cabal downloads had a compile failure for a ‘long long’

So perhaps there something that has changed in wxHaskell that causes a generic problem.



On Mar 28, 2015, at 7:40 PM, Michael Jones <mi...@pr...> wrote:

> There is a response from wxWidgets trac
> 
> #16935:
> http://trac.wxwidgets.org/ticket/16935#comment:1
> 
> On Mar 28, 2015, at 5:12 PM, Henk-Jan van Tuyl <hj...@ch...> wrote:
> 
>> On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones <mi...@pr...>
>> wrote:
>> 
>>> On Win 7...
>>> 
>>> The latest code on github seems to result in a wxWidgets call to LPTSTR WINAPI GetCommandLine(void);
>>> 
>>> This results in popping a dialog complaining about command options. On Linux this does not happen. Looks like wxWidgets is trying to use this call to deal with unicode, but it unfortunately bypasses the Haskell argument mechanism and grabs everything including +/-RTS and passes it to wxWidgets for consideration. Perhaps wxHaskell should manage the arguments and strip off any arguments that are not destined for wxWidgets, or at least let the Haskell code intercept and manage the problem.
>>> 
>>> Is there some way to effect the wxHaskell initialization so that it prevents this call, so that an wxHaskell application running on Windows 7 can accept command line arguments properly?
>>> 
>>> I handling initialization with a start call within Haskell. Perhaps there is an alternate approach I am unaware of.
>> 
>> I am trying to change the internal representation of the command line, but it is likely to fail. The best thing would to let the wxWidgets people change the behavior of wxWidgets to let it be the same in Windows as in Linux. You could write a ticket for this[0]. To be sure this problems isn't forgotten, you should also write a wxHaskell ticket[1], preferably linking to the wxWidgets ticket.
>> 
>> The message about the unexpected parameter stems from wxWidgets\src\common\cmdline.cpp , method wxCmdLineParser::Parse(bool showUsage) . Maybe it is possible to specify a wxCmdLineParser, that handles the +RTS parameters correctly, in wxHaskell.
>> 
>> Regards,
>> Henk-Jan van Tuyl
>> 
>> 
>> [0] http://trac.wxwidgets.org/
>> [1] http://sourceforge.net/p/wxhaskell/_list/tickets
>> 
>> -- 
>> 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
>> --
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Windows 7 GetCommandLine call interference

[Michael J. <mi...@pr...>]

There is a response from wxWidgets trac

#16935:
http://trac.wxwidgets.org/ticket/16935#comment:1

On Mar 28, 2015, at 5:12 PM, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones <mi...@pr...>
> wrote:
> 
>> On Win 7...
>> 
>> The latest code on github seems to result in a wxWidgets call to LPTSTR WINAPI GetCommandLine(void);
>> 
>> This results in popping a dialog complaining about command options. On Linux this does not happen. Looks like wxWidgets is trying to use this call to deal with unicode, but it unfortunately bypasses the Haskell argument mechanism and grabs everything including +/-RTS and passes it to wxWidgets for consideration. Perhaps wxHaskell should manage the arguments and strip off any arguments that are not destined for wxWidgets, or at least let the Haskell code intercept and manage the problem.
>> 
>> Is there some way to effect the wxHaskell initialization so that it prevents this call, so that an wxHaskell application running on Windows 7 can accept command line arguments properly?
>> 
>> I handling initialization with a start call within Haskell. Perhaps there is an alternate approach I am unaware of.
> 
> I am trying to change the internal representation of the command line, but it is likely to fail. The best thing would to let the wxWidgets people change the behavior of wxWidgets to let it be the same in Windows as in Linux. You could write a ticket for this[0]. To be sure this problems isn't forgotten, you should also write a wxHaskell ticket[1], preferably linking to the wxWidgets ticket.
> 
> The message about the unexpected parameter stems from wxWidgets\src\common\cmdline.cpp , method wxCmdLineParser::Parse(bool showUsage) . Maybe it is possible to specify a wxCmdLineParser, that handles the +RTS parameters correctly, in wxHaskell.
> 
> Regards,
> Henk-Jan van Tuyl
> 
> 
> [0] http://trac.wxwidgets.org/
> [1] http://sourceforge.net/p/wxhaskell/_list/tickets
> 
> -- 
> 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-users] Windows 7 GetCommandLine call interference

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

On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones <mi...@pr...>
wrote:

> On Win 7...
>
> The latest code on github seems to result in a wxWidgets call to LPTSTR  
> WINAPI GetCommandLine(void);
>
> This results in popping a dialog complaining about command options. On  
> Linux this does not happen. Looks like wxWidgets is trying to use this  
> call to deal with unicode, but it unfortunately bypasses the Haskell  
> argument mechanism and grabs everything including +/-RTS and passes it  
> to wxWidgets for consideration. Perhaps wxHaskell should manage the  
> arguments and strip off any arguments that are not destined for  
> wxWidgets, or at least let the Haskell code intercept and manage the  
> problem.
>
> Is there some way to effect the wxHaskell initialization so that it  
> prevents this call, so that an wxHaskell application running on Windows  
> 7 can accept command line arguments properly?
>
> I handling initialization with a start call within Haskell. Perhaps  
> there is an alternate approach I am unaware of.

I am trying to change the internal representation of the command line, but  
it is likely to fail. The best thing would to let the wxWidgets people  
change the behavior of wxWidgets to let it be the same in Windows as in  
Linux. You could write a ticket for this[0]. To be sure this problems  
isn't forgotten, you should also write a wxHaskell ticket[1], preferably  
linking to the wxWidgets ticket.

The message about the unexpected parameter stems from  
wxWidgets\src\common\cmdline.cpp , method wxCmdLineParser::Parse(bool  
showUsage) . Maybe it is possible to specify a wxCmdLineParser, that  
handles the +RTS parameters correctly, in wxHaskell.

Regards,
Henk-Jan van Tuyl


[0] http://trac.wxwidgets.org/
[1] http://sourceforge.net/p/wxhaskell/_list/tickets

-- 
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-users] installation problem on Win 8.1, WXCFG

[Michael J. <mi...@pr...>]

Andrew,

I just compiled on Win 7 64 bit. I’m not experienced with compiling wxWidgets, but this is what I did:

Installed TDM GCC 64 bit.
Change path to put it before the Haskell gcc
Downloaded wxWidgets 3.0.2 tarball. Not the git head. It had some problems compiling.

export WXWIN="C:\Users\…your-name...\Documents\wxWidgets-3.0.2"
export WXCFG="gcc_dll\mswu"

Run cmd.exe and cd to build\msw

mingw32-make -j8 -f Makefile.gcc SHARED=1 UNICODE=1 BUILD=release VENDOR=cl CXXFLAGS="-fno-keep-inline-dllexport -std=gcc++11" MONOLITHIC=1

Note, gcc++11, not c++11

Search for the two dll files in lib and copy them to c:\Widows\System32 or wherever you want them

Get the latest wxHaskell code, because the last release has this compile error:

 "C:\Program Files\Haskell Platform\2014.2.0.0\mingw\bin\gcc.exe" "-Isrc/include" "-IC:\SourceCode\wxWidgets\include" "-IC:\SourceCode\wxWidgets\lib\gcc_dll\mswu" "-DWXUSINGDLL" "-D_UNICODE" "-D__WXDEBUG__" "-D__WXMSW__" "-DHAVE_W32API_H" "-DwxcREFUSE_MEDIACTRL" "-DBUILD_DLL" "-c" "src\cpp\eljlistctrl.cpp" "-o" "dist\dist-sandbox-d11f86f1\build\src/cpp/eljlistctrl.o"
src\cpp\eljlistctrl.cpp: In function 'int ListCmp(long int, long int, long int)':
src\cpp\eljlistctrl.cpp:16:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src\cpp\eljlistctrl.cpp:16:53: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src\cpp\eljlistctrl.cpp: In function 'bool wxListCtrl_SortItems(wxListCtrl*, void*, void*)':
src\cpp\eljlistctrl.cpp:478:41: error: cast from 'EiffelSort* {aka _EiffelSort*}' to 'long int' loses precision [-fpermissive]
src\cpp\eljlistctrl.cpp:478:44: error: invalid conversion from 'int (*)(long int, long int, long int)' to 'wxListCtrlCompare {aka int (*)(long long int, long long int, long long int)}' [-fpermissive]
C:\SourceCode\wxWidgets\include/wx/msw/listctrl.h:342:10: error:   initializing argument 1 of 'bool wxListCtrl::SortItems(wxListCtrlCompare, wxIntPtr)' [-fpermissive]
cabal.exe: Error: some packages failed to install:
wxc-0.91.0.0 failed during the building phase. The exception was:
ExitFailure 1

Add the latest wxHaskell code path to my sandbox.

Fix windows path so that the Haskell gcc comes first again

Compile the wxHaskell app.

Find the wxc.dll in the sandbox and copy to c:\Windows\System32 or wherever you want it

And things work.

Note my other e-mail about command line args.

With the above, my linux wxHaskell app compiled and ran on Windows 7 64 bit.

Like I said, not an expert on this. Just hacked to something that worked.

Mike

On Mar 28, 2015, at 8:09 AM, Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Thu, 26 Mar 2015 22:52:14 +0100, Andrew Butterfield  
> <And...@sc...> wrote:
> 
> :
>> Configuring wxc-0.92.0.0...
>> 
>> Please use the --wxcfg flag (as in wx-config --wxcfg=gcc_dll\mswud)
>> or set the environment variable WXCFG (as in WXCFG=gcc_dll\mswud)
>> to specify which configuration exactly you want to use.
>> readProcess failed: readProcess: wx-config "--version" (exit 1): failed
>> setup.exe: failed
>> cabal: Error: some packages failed to install:
>> wxc-0.92.0.0 failed during the configure step. The exception was:
>> ExitFailure 1
>> ------ log extract pause ------
>> 
>> How do I fix this? What is going on?
>> 
>> Installed 32-bit Haskell Platform on 64-bit Win 8.1
>> (I did that because the instructions talk about mingw32-make)
> 
> Did you set WXWIN to the correct value, something like:
>   WXWIN=C:\Libs\wxWidgets\3.0.2
> ?
> 
> Another reason why the compilation failed, might be that the configuration  
> file specifies a debug build, instead of a release build.
> 
> You can build a 64 bit wxHaskell, even though there is a 32 in the name  
> mingw32-make; take care that you build wxWidgets with the same bitness. To  
> build wxWidgets as 64 bits DLLs, I changed some values in  
> build\msw\config.gcc to:
> 
>   # Standard flags for CC
>   CFLAGS ?= -m64
> 
>   # Standard flags for C++
>   CXXFLAGS ?= -m64
> 
>   # Standard preprocessor flags (common for CC and CXX)
>   CPPFLAGS ?= -D_M_AMD64
> 
> 
> 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
> --
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] installation problem on Win 8.1, WXCFG

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

On Thu, 26 Mar 2015 22:52:14 +0100, Andrew Butterfield  
<And...@sc...> wrote:

:
> Configuring wxc-0.92.0.0...
>
> Please use the --wxcfg flag (as in wx-config --wxcfg=gcc_dll\mswud)
> or set the environment variable WXCFG (as in WXCFG=gcc_dll\mswud)
> to specify which configuration exactly you want to use.
> readProcess failed: readProcess: wx-config "--version" (exit 1): failed
> setup.exe: failed
> cabal: Error: some packages failed to install:
> wxc-0.92.0.0 failed during the configure step. The exception was:
> ExitFailure 1
> ------ log extract pause ------
>
> How do I fix this? What is going on?
>
> Installed 32-bit Haskell Platform on 64-bit Win 8.1
> (I did that because the instructions talk about mingw32-make)

Did you set WXWIN to the correct value, something like:
   WXWIN=C:\Libs\wxWidgets\3.0.2
?

Another reason why the compilation failed, might be that the configuration  
file specifies a debug build, instead of a release build.

You can build a 64 bit wxHaskell, even though there is a 32 in the name  
mingw32-make; take care that you build wxWidgets with the same bitness. To  
build wxWidgets as 64 bits DLLs, I changed some values in  
build\msw\config.gcc to:

   # Standard flags for CC
   CFLAGS ?= -m64

   # Standard flags for C++
   CXXFLAGS ?= -m64

   # Standard preprocessor flags (common for CC and CXX)
   CPPFLAGS ?= -D_M_AMD64


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

[wxhaskell-users] Is there a way to send a code to execute on main wx thread?

[Grzegorz M. <grz...@gm...>]

Hello,

I am using wxHaskell to show a simple window with a button. A click on
the button begins a task which takes a screenshot of the screen, does
some computation on it and then simulates mouse clicks.
Currently this task runs in the main wx thread, which makes the button
unnecessarily unnresponsive for some time.

Ideally I would like to be able to run this task in a separate thread
and only send the GUI related code to execute on the main thread. I can
not run GUI related code on a different thread, because wx, like most
GUI libraries, is not thread safe.

On wxPython documentation I read that this could be possible with
events, however I could not find anything in wxHaskell which corresponds
to creating new custom events and wx.postEvent method, which fires the
event to the main thread. This method is described here:
http://wiki.wxpython.org/Non-Blocking%20Gui#Communicating_with_the_main_thread
.

So my question is whether it is possible to do it in the way as
described in the wiki above or do you have a different solution to my
problem?

Thank you,
Grzegorz Milka

[wxhaskell-users] installation problem on Win 8.1, WXCFG

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

All,
  I've been following the installation instructions  in section 1 of 
https://wiki.haskell.org/WxHaskell/Windows

wxWidgets 3.0 and wxhaskell >=0.92

All goes well until I try to install wxc

------ log extract start -----
.......
Installed wxdirect-0.92.0.0

C:\ghc\wxHaskell>cabal install .\wxc
Resolving dependencies...
Configuring wxc-0.92.0.0...
Failed to install wxc-0.92.0.0
Last 10 lines of the build log ( 
C:\Users\butrfeld\AppData\Roaming\cabal\logs\wx
c-0.92.0.0.log ):
[1 of 1] Compiling Main             ( wxc\Setup.hs, wxc\dist\setup\Main.o )
Linking .\wxc\dist\setup\setup.exe ...
Could not find a dynamic library to check bitness, continuing installation
Configuring wxc-0.92.0.0...

Please use the --wxcfg flag (as in wx-config --wxcfg=gcc_dll\mswud)
or set the environment variable WXCFG (as in WXCFG=gcc_dll\mswud)
to specify which configuration exactly you want to use.
readProcess failed: readProcess: wx-config "--version" (exit 1): failed
setup.exe: failed
cabal: Error: some packages failed to install:
wxc-0.92.0.0 failed during the configure step. The exception was:
ExitFailure 1
--------- log extract pause -----

This is strange, so I check, and to be sure, I set WXCFG
----- log  extract resume -------
C:\ghc\wxHaskell>echo %WXCFG%
gcc_dll\mswu

C:\ghc\wxHaskell>Set WXCFG=gcc_dll\mswu
------ log extract pause ------

Seems alright - let's try again...
----- log extract resume -------
C:\ghc\wxHaskell>cabal install .\wxc
Resolving dependencies...
Configuring wxc-0.92.0.0...
Failed to install wxc-0.92.0.0
Last 10 lines of the build log ( 
C:\Users\butrfeld\AppData\Roaming\cabal\logs\wx
c-0.92.0.0.log ):
Could not find a dynamic library to check bitness, continuing installation
Configuring wxc-0.92.0.0...

Please use the --wxcfg flag (as in wx-config --wxcfg=gcc_dll\mswud)
or set the environment variable WXCFG (as in WXCFG=gcc_dll\mswud)
to specify which configuration exactly you want to use.
readProcess failed: readProcess: wx-config "--version" (exit 1): failed
setup.exe: failed
cabal: Error: some packages failed to install:
wxc-0.92.0.0 failed during the configure step. The exception was:
ExitFailure 1
------ log extract pause ------

How do I fix this? What is going on?

Installed 32-bit Haskell Platform on 64-bit Win 8.1
(I did that because the instructions talk about mingw32-make)

Regards, and thanks,
   Andrew

[wxhaskell-users] Windows 7 GetCommandLine call interference

[Michael J. <mi...@pr...>]

On Win 7...

The latest code on github seems to result in a wxWidgets call to LPTSTR WINAPI GetCommandLine(void);

This results in popping a dialog complaining about command options. On Linux this does not happen. Looks like wxWidgets is trying to use this call to deal with unicode, but it unfortunately bypasses the Haskell argument mechanism and grabs everything including +/-RTS and passes it to wxWidgets for consideration. Perhaps wxHaskell should manage the arguments and strip off any arguments that are not destined for wxWidgets, or at least let the Haskell code intercept and manage the problem.

Is there some way to effect the wxHaskell initialization so that it prevents this call, so that an wxHaskell application running on Windows 7 can accept command line arguments properly?

I handling initialization with a start call within Haskell. Perhaps there is an alternate approach I am unaware of.

Mike

Not knowing the code base, and by searching, it seems it is probably calling this wxWidgets code:

static bool
wxMSWEntryCommon(HINSTANCE hInstance, int nCmdShow)
{
    // remember the parameters Windows gave us
    wxSetInstance(hInstance);
#ifdef __WXMSW__
    wxApp::m_nCmdShow = nCmdShow;
#endif

    // parse the command line: we can't use pCmdLine in Unicode build so it is
    // simpler to never use it at all (this also results in a more correct
    // argv[0])

    // break the command line in words
    wxArrayString args;

    const wxChar *cmdLine = ::GetCommandLine();
    if ( cmdLine )
    {
        args = wxCmdLineParser::ConvertStringToArgs(cmdLine);
    }

[wxhaskell-users] Created a powershell script to automatically download and build wxHaskell requirements on Windows

[Chris V. V. <ces...@gm...>]

I created a powershell script that automatically downloads and builds all
dependencies for wxHaskell including proper setup of MinGW32. And exports
the environment variables you need to launch wxHaskell and wxWidgets
programs. Clone it on github
<https://github.com/cessationoftime/wxHaskell-Windows-Builder>

Chris

Re: [wxhaskell-users] Error using FFI with wxHaskell

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

Am 02.09.2014 um 09:25 schrieb Vivian McPhail:

> I've tried using pointers (Ptr a) but (DC a) and (Gtk.DrawWindow) aren't
> members of `Storable`.

I don't think there is any restriction to the type of the pointer 
target. Does GHC expect, that DC is Storable when you use an argument of 
type Ptr (DC a)?

Re: [wxhaskell-users] Error using FFI with wxHaskell

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

Hi,

I've tried using pointers (Ptr a) but (DC a) and (Gtk.DrawWindow) aren't
members of `Storable`.

On Linux WxWidgets is written on top of GTK and I am trying to access an
underlying Gtk.DrawWindow so that I can perform cairo rendering on that
window.

Any ideas?

Vivian


On 31 August 2014 19:33, Henning Thielemann <
sch...@he...> wrote:

> Am 31.08.2014 um 06:48 schrieb Vivian McPhail:
>
>
>  foreign import ccall unsafe "plot.cc gdk_get_drawable"
>>          c_gdkGetDrawable :: DC a -> IO Gtk.DrawWindow
>>
>
>  How do I fix these errors?
>>
>
> You certainly need to use pointers, e.g. Ptr (DC a).
>
>

Re: [wxhaskell-users] Error using FFI with wxHaskell

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

Am 31.08.2014 um 06:48 schrieb Vivian McPhail:

> foreign import ccall unsafe "plot.cc gdk_get_drawable"
>          c_gdkGetDrawable :: DC a -> IO Gtk.DrawWindow

> How do I fix these errors?

You certainly need to use pointers, e.g. Ptr (DC a).

[wxhaskell-users] Error using FFI with wxHaskell

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

Hi,

I defined in "plot.cc":

#include <gdk/gdk.h>
#include <wx/wx.h>


extern "C" {
  GdkWindow* gdk_get_drawable(wxPaintDC* dc)
  {
    return dc->GetGDKWindow();
  }
}

And then in my haskell source Plot.hs:

#else
foreign import ccall unsafe "plot.cc gdk_get_drawable"
        c_gdkGetDrawable :: DC a -> IO Gtk.DrawWindow
#endif

Which results in these errors:

[1 of 2] Compiling Graphics.UI.WX.Plot ( lib/Graphics/UI/WX/Plot.hs,
dist/build/Graphics/UI/WX/Plot.o )

lib/Graphics/UI/WX/Plot.hs:151:1:
    Unacceptable argument type in foreign declaration:
      Object (CWxObject (CDC a))
    When checking declaration:
      foreign import ccall unsafe "static plot.cc gdk_get_drawable"
c_gdkGetDrawable
        :: DC a -> IO Gtk.DrawWindow

lib/Graphics/UI/WX/Plot.hs:151:1:
    Unacceptable result type in foreign declaration: IO Gtk.DrawWindow
    When checking declaration:
      foreign import ccall unsafe "static plot.cc gdk_get_drawable"
c_gdkGetDrawable
        :: DC a -> IO Gtk.DrawWindow

How do I fix these errors?

Thanks,

Vivian

Re: [wxhaskell-users] wxHaskell - install problems..

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

Adding

export CPLUS_INCLUDE_PATH=/usr/include/c++/4.2.1/

made things work,

 Thanks,
 Doaitse


On 27 Aug 2014, at 21:51 , Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Wed, 27 Aug 2014 20:40:20 +0200, S D Swierstra <doa...@gm...> wrote:
> 
>> I installed the new wxWidgets on my MacBook, and then tried to install wx:
> :
>> ...
>> Configuring wxc-0.91.0.0...
>> Configuring wxc to build against wxWidgets 3.0.1.0
>> 
>> Building wxc
>> /usr/bin/gcc -Isrc/include -I/usr/local/include/wx-3.0 -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 -D__WXOSX_COCOA__ -D__WXOSX__ -D__WXMAC__ -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/apppath.cpp -o dist/build/src/cpp/apppath.o
>> In file included from src/cpp/apppath.cpp:1:
>> In file included from src/include/wrapper.h:20:
>> In file included from /usr/local/include/wx-3.0/wx/wx.h:15:
>> In file included from /usr/local/include/wx-3.0/wx/object.h:19:
>> In file included from /usr/local/include/wx-3.0/wx/memory.h:15:
>> In file included from /usr/local/include/wx-3.0/wx/string.h:46:
>> /usr/local/include/wx-3.0/wx/strvararg.h:30:18: fatal error: 'tr1/type_traits' file not found
>>        #include <tr1/type_traits>
>>                 ^
>> 1 error generated.
>> Updating documentation index
>> /Users/doaitse/Library/Haskell/share/doc/index.html
>> 
>> Any idea how to proceed?
>> 
>> Doaitse
> 
> The file that is not found is a C++ header file, I use on my Windows system the command:
>  Set CPLUS_INCLUDE_PATH=%HASKELL_COMPILER_DIR%\mingw\lib\gcc\mingw32\4.5.2\include\c++
> so that the compiler can find the C++ header files (note that the GCC version differs depending on the version and bitness of GHC).
> 
> Henk-Jan
> 
> 
> -- 
> 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-users] wxHaskell - install problems..

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

On Wed, 27 Aug 2014 20:40:20 +0200, S D Swierstra  
<doa...@gm...> wrote:

> I installed the new wxWidgets on my MacBook, and then tried to install  
> wx:
:
> ...
> Configuring wxc-0.91.0.0...
> Configuring wxc to build against wxWidgets 3.0.1.0
>
> Building wxc
> /usr/bin/gcc -Isrc/include -I/usr/local/include/wx-3.0  
> -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 -D__WXOSX_COCOA__  
> -D__WXOSX__ -D__WXMAC__ -DWXUSINGDLL -D_FILE_OFFSET_BITS=64  
> -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/apppath.cpp -o  
> dist/build/src/cpp/apppath.o
> In file included from src/cpp/apppath.cpp:1:
> In file included from src/include/wrapper.h:20:
> In file included from /usr/local/include/wx-3.0/wx/wx.h:15:
> In file included from /usr/local/include/wx-3.0/wx/object.h:19:
> In file included from /usr/local/include/wx-3.0/wx/memory.h:15:
> In file included from /usr/local/include/wx-3.0/wx/string.h:46:
> /usr/local/include/wx-3.0/wx/strvararg.h:30:18: fatal error:  
> 'tr1/type_traits' file not found
>         #include <tr1/type_traits>
>                  ^
> 1 error generated.
> Updating documentation index
> /Users/doaitse/Library/Haskell/share/doc/index.html
>
> Any idea how to proceed?
>
>  Doaitse

The file that is not found is a C++ header file, I use on my Windows  
system the command:
   Set  
CPLUS_INCLUDE_PATH=%HASKELL_COMPILER_DIR%\mingw\lib\gcc\mingw32\4.5.2\include\c++
so that the compiler can find the C++ header files (note that the GCC  
version differs depending on the version and bitness of GHC).

Henk-Jan


-- 
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-users] Need Win-64 version of wx-config.exe

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

On Fri, 15 Aug 2014 19:09:17 +0200, Howard B. Golden  
<how...@ya...> wrote:

> Hi,
>
> I tried to install the wx-config.exe file at  
> https://sourceforge.net/projects/wxhaskell/files/wx-config-win/ on  
> Windows 7 Professional 64. It won't run because it is a 32-bit  
> executable. If possible, please provide either a 64-bit version of  
> wx-config.exe or the source code so I can recompile it for 64-bits.
>
> It would be very helpful if you could submit your new version of  
> wx-config for Windows to the original author of wx-config for Windows. I  
> spent a lot of time recompiling the 2006 version and wondering why it  
> wouldn't work with the latest wxHaskell.

I just saw your email; you can find the source code for wx-config at:
   https://github.com/wxHaskell/wxHaskell/blob/master/wx-config-win/wx-config-win/wx-config.cpp
Please read the installation instructions at
   https://www.haskell.org/haskellwiki/WxHaskell/Windows
carefully, as the compilation/installation is very tricky. I did not try  
64 bit compilation so far, but I succeeded running the 32 bit software on  
my 64 bit Windows system.

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-users] wxHaskell - install problems..

[S D S. <doa...@gm...>]

I installed the new wxWidgets on my MacBook, and then tried to install wx:

MacBook-Doaitse-2:Dazzle doaitse$ cabal install wx
Resolving dependencies...
Configuring wxdirect-0.91.0.0...
Building wxdirect-0.91.0.0...
Installed wxdirect-0.91.0.0
Configuring wxc-0.91.0.0...
Building wxc-0.91.0.0...
Failed to install wxc-0.91.0.0
Build log ( /Users/doaitse/.cabal/logs/wxc-0.91.0.0.log ):
[1 of 1] Compiling Main             ( /var/folders/9m/xpbyx5fs19xcf68s9wjjy12c0000gn/T/wxc-0.91.0.0-98293/wxc-0.91.0.0/dist/setup/setup.hs, /var/folders/9m/xpbyx5fs19xcf68s9wjjy12c0000gn/T/wxc-0.91.0.0-98293/wxc-0.91.0.0/dist/setup/Main.o )
Linking /var/folders/9m/xpbyx5fs19xcf68s9wjjy12c0000gn/T/wxc-0.91.0.0-98293/wxc-0.91.0.0/dist/setup/setup ...
Configuring wxc-0.91.0.0...
Configuring wxc to build against wxWidgets 3.0.1.0

Building wxc
/usr/bin/gcc -Isrc/include -I/usr/local/include/wx-3.0 -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 -D__WXOSX_COCOA__ -D__WXOSX__ -D__WXMAC__ -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/apppath.cpp -o dist/build/src/cpp/apppath.o
In file included from src/cpp/apppath.cpp:1:
In file included from src/include/wrapper.h:20:
In file included from /usr/local/include/wx-3.0/wx/wx.h:15:
In file included from /usr/local/include/wx-3.0/wx/object.h:19:
In file included from /usr/local/include/wx-3.0/wx/memory.h:15:
In file included from /usr/local/include/wx-3.0/wx/string.h:46:
/usr/local/include/wx-3.0/wx/strvararg.h:30:18: fatal error: 'tr1/type_traits' file not found
        #include <tr1/type_traits>
                 ^
1 error generated.
Updating documentation index
/Users/doaitse/Library/Haskell/share/doc/index.html

Any idea how to proceed?

 Doaitse


On 20 Aug 2014, at 22:23 , Henk-Jan van Tuyl <hj...@ch...> wrote:

> On Wed, 20 Aug 2014 21:33:52 +0200, Gregory Guthrie <gu...@mu...>  
> wrote:
> 
>> I did an upgrade to the current Haskell Platform (2014.2.0.0, = ghci  
>> 7.8), and now wxHaskell seems to be broken.
>> 
>> Environment seems to be OK:
>>   WXC_VERSION = 0.90.0.3
> 
> It is better to install wxHaskell 0.91
> 
>>   GHC_Version = 7.8.3
>>   WxWin = e:\plang\Libraries\wxWidgets-3.0.1
>>   WxCfg = gcc_dll\mswu
>> PATH set as per directions  
>> (https://www.haskell.org/haskellwiki/WxHaskell/Windows).
>> I do notice that page is in terms of Version 2.9.5, I am not sure how  
>> that relates to the 3.0.1 version installed (as above).
> 
> The installation procedure is exactly the same, the page is updated in the  
> meanwhile.
> 
>> 
>> I installed wxWidgets from: wxMSW-3.0.1-Setup
>> 
>> I did not build from source, but instead used: wxMSW.exe;
>> I also did a cabal install of (wx, wxcore), and all seemed to go well.
>> 
>> But;
>>    trying to run wxHello in GHCi fails - can't find uuid.dll
> 
> You have to install several DLLs as described in
>   https://www.haskell.org/haskellwiki/WxHaskell/Windows#DLLs
> 
> GHCi cannot handle wxHaskell at the moment, see
>   https://ghc.haskell.org/trac/ghc/ticket/7103
> 
>> 
>>   Trying to compile from GHC works, but execution fails: Cannot fine  
>> procedure entry point wxBitmapToggleButton_Create in dynamic library  
>> wxc.dll
>> 
>>   Trying to run from Leksah, fails: cabal missing dependency GLFW -any
> 
> I will investigate these points.
> 
> 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
> --
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users