Re: [wxhaskell-users] Windows 7 GetCommandLine call interference
On Sat, 04 Apr 2015 21:19:43 +0200, Michael Jones m...@proclivis.com 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 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 m...@proclivis.com 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 hjgt...@chello.nl wrote: On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones m...@proclivis.com 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 hjgt...@chello.nl wrote: On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones m...@proclivis.com 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] Windows 7 GetCommandLine call interference
On Wed, 25 Mar 2015 22:57:12 +0100, Michael Jones m...@proclivis.com 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
