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] Windows 7 GetCommandLine call interference
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
Re: [wxhaskell-users] installation problem on Win 8.1, WXCFG
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/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Is there a way to send a code to execute on main wx thread?
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 -- 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] installation problem on Win 8.1, WXCFG
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 -- 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
