Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
I finally solved the compile problem. Running "cabal clean” in the original tree fixed it. I have no idea how it mucked with the sandbox, but it did. After I did the clean, even more things failed, but after recreating the sandbox it worked. I had tried to recreate the sandbox before and it did not help. It required both a clean of the source tree and a recreation of the sandbox. On Apr 4, 2015, at 5:04 PM, Michael Jones wrote: > Henk-Jan, > > I think you are right about Windows, but it does pass them on Linux, and this > does make my app work on Ubuntu. It is not the RTS args that are the problem, > it is the args for the application that come after. Windows has the further > problem of bypassing the passed args completely. My take was that once > Windows has a way to stop the Win32 call, it still has the problem this > solved. > > BTW, > > I compiled up wxWidgets 3.0.2 on Ubuntu so I could try to hack it a bit, and > then compile the git head of wxHaskell as referenced in a sandbox, and > compiled by ghc 7.8.4 and get this link error: > > .../.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/wxc-0.92.0.0/libwxc.so: > undefined reference to `wxDateTime::SetHour(unsigned > short)@WXU_UNOFFICIAL_3.0’ > > I can’t find any references WXU_UNOFFICIAL_3.0 in any code, and the @WXU… is > unfamiliar to me. > > I ran ./configure for wxHaskell and it finds 3.0.2. Yet the problem persists. > My assumption is I can run ./configure in the source tree and then reference > that tree in a sandbox. > > I remembered that when I installed wxWidgets with apt-get it had names with > “unofficial” in them. When I removed it I used apt-get purge to get rid of > any configurations. Is there something that might have been left behind by > the apt-get version? > > Mike > > > > > On Apr 4, 2015, at 4:55 PM, Henk-Jan van Tuyl wrote: > >> On Sat, 04 Apr 2015 21:19:43 +0200, Michael Jones 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 >> -- > > > > -- > 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 > wxhaskell-users@lists.sourceforge.net > https://lists.sou
Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
Henk-Jan, I think you are right about Windows, but it does pass them on Linux, and this does make my app work on Ubuntu. It is not the RTS args that are the problem, it is the args for the application that come after. Windows has the further problem of bypassing the passed args completely. My take was that once Windows has a way to stop the Win32 call, it still has the problem this solved. BTW, I compiled up wxWidgets 3.0.2 on Ubuntu so I could try to hack it a bit, and then compile the git head of wxHaskell as referenced in a sandbox, and compiled by ghc 7.8.4 and get this link error: .../.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/wxc-0.92.0.0/libwxc.so: undefined reference to `wxDateTime::SetHour(unsigned short)@WXU_UNOFFICIAL_3.0’ I can’t find any references WXU_UNOFFICIAL_3.0 in any code, and the @WXU… is unfamiliar to me. I ran ./configure for wxHaskell and it finds 3.0.2. Yet the problem persists. My assumption is I can run ./configure in the source tree and then reference that tree in a sandbox. I remembered that when I installed wxWidgets with apt-get it had names with “unofficial” in them. When I removed it I used apt-get purge to get rid of any configurations. Is there something that might have been left behind by the apt-get version? Mike On Apr 4, 2015, at 4:55 PM, Henk-Jan van Tuyl wrote: > On Sat, 04 Apr 2015 21:19:43 +0200, Michael Jones 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 > -- -- 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
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 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 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 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 wrote: >> >>> On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones >>> 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 wxWidg
Re: [wxhaskell-users] TableBase
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 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 wrote: > >> On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones 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 > wxhaskell-users@lists.sourceforge.net > 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] TableBase
>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 wrote: > On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] TableBase
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 wrote: > On Mon, 30 Mar 2015 06:23:40 +0200, Michael Jones 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] TableBase
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 -- 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
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 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 wrote: > >> On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones >> 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 > wxhaskell-users@lists.sourceforge.net > 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
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 wrote: > On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones > 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] installation problem on Win 8.1, WXCFG
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 wrote:
> On Thu, 26 Mar 2015 22:52:14 +0100, Andrew Butterfield
> 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/
> ___
> wxhas
[wxhaskell-users] Windows 7 GetCommandLine call interference
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);
}--
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
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Timer results in lockup
I have an application using a timer with a 200ms interval. When I change the interval to 100ms, the application locks up. I assumed the problem was a callback was made before the previous callback was complete. So I added an MVar to protect against executing IO in parallel. With 200ms, the MVar code runs fine. But at 100mS it locks up. I tried to use putStrLn to prove that a try on MVar got a nothing and that the extra callback exited without any IO. However, I never saw any printing. But this could just be a problem of overlapping IO itself. What I was was callbacks that did not appear to overlap, followed by lockup. My assumption is the lockup happens before the callback can do a try on the MVar Does anyone know: - Will the timer callback if a previous callback is not complete? - Is there any known lockup from overlapping callbacks? - Is there a proper way to handling potential overlapping callbacks? As far as I can tell, the only mechanism I have other than synchronization techniques, is to manipulate the interval from the callback. - If the interval is lengthened and shortened, does the current time remain in tack? - If the time is shortened, would it trigger an immediate callback if the time is less than the current timer? - Or is the timer restarted with the interval changed? I am using the latest version of wxHaskell. Just built it yesterday and wrote my first app. Using 3.0.1 on Ubuntu 14 TLS. Mike -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Timer results in lockup
I have an application using a timer with a 200ms interval. When I change the interval to 100ms, the application locks up. I assumed the problem was a callback was made before the previous callback was complete. So I added an MVar to protect against executing IO in parallel. With 200ms, the MVar code runs fine. But at 100mS it locks up. I tried to use putStrLn to prove that a try on MVar got a nothing and that the extra callback exited without any IO. However, I never saw any printing. But this could just be a problem of overlapping IO itself. What I was was callbacks that did not appear to overlap, followed by lockup. My assumption is the lockup happens before the callback can do a try on the MVar Does anyone know: - Will the timer callback if a previous callback is not complete? - Is there any known lockup from overlapping callbacks? - Is there a proper way to handling potential overlapping callbacks? As far as I can tell, the only mechanism I have other than synchronization techniques, is to manipulate the interval from the callback. - If the interval is lengthened and shortened, does the current time remain in tack? - If the time is shortened, would it trigger an immediate callback if the time is less than the current timer? - Or is the timer restarted with the interval changed? I am using the latest version of wxHaskell. Just built it yesterday and wrote my first app. Using 3.0.1 on Ubuntu 14 TLS. Mike -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
