Hi All,
Who is committing and reviewing patches these days?
I have made two fixes, which is attached to this email. One is for a fix
that both David Rogers and I experienced. See
http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1278
and http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/861.
The other fix is to make wxHaskell compile on GHC 7.6.1.
I made the patches using:
darcs send --output "patch_name" --author "Mads Lindstroem" --from "Mads
Lindstroem" -i
Greetings,
Mads Lindstrøm
1 patch for repository http://code.haskell.org/wxhaskell:
Tue Dec 4 20:24:12 CET 2012 mads.lindstr...@gmail.com
* GTK-Fix: Removing dereferencing before setting to NULL
New patches:
[GTK-Fix: Removing dereferencing before setting to NULL
mads.lindstr...@gmail.com**20121204192412
Ignore-this: df2135dc42d1585dda5e8ffbe6ec0419
] hunk ./wxc/src/cpp/eljpen.cpp 159
EWXWEXPORT(void,wxPen_GetStipple)(void* self,wxBitmap* _ref)
{
#if defined(__WXGTK__)
- *_ref = NULL;
+ _ref = NULL;
#else
*_ref = *(((wxPen*)self)->GetStipple());
#endif
Context:
[Bump wxdirect version number to 0.90.0.1
shelarcy <shela...@gmail.com>**20120418143631
Ignore-this: 2fac8c2b54459864dab8c113ae0e3416
]
[Relax time package dependency to wxdirect-0.90
shelarcy <shela...@gmail.com>**20120418143433
Ignore-this: 1b8adf33d9d72971abd5205004bc1509
GHC 7.4.1's time package version is 1.4. So, wxdirect-0.90 requires to reinstall
time package less than 1.3 when using GHC 7.4.1.
http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html#id3019262
Only wxdirect-0.90 has this problem. Because wxdirect-0.13.1.2 already fixed this
problem and other package' time package dependencies are more relaxed form.
]
[Fix error building on some 32 bit targets.
jeremy.odonog...@gmail.com**20120414142124
Ignore-this: 212d1935582b619313032033a20834d
Apply patch due to Heinrich Apfelmus (apfel...@quantentunnel.de). His description
attached below:
"I just tripped over a bug in the Setup.hs belonging to wxc that
prevented me from compiling wxHaskell with 32bit architecture.
The problem is the following: in the function linkSharedLib , the
function runProgram is commented out and the function system is used
instead. This is not correct because gcc may (and in my case: does)
carry additional command line options! (Besides, the verbose output is
lost.)
Apparently, this was done because the runProgram didn't work for some
reason. The reason is that some command line options are actually two
arguments. In particular, setting the output file via
"-o " ++ out_dir </> sharedLibName ver basename,
is not correct, the right way to go about it are two arguments
"-o", out_dir </> sharedLibName ver basename,
Same for the "-install_name" option. Four lines need to be changed in
the linkCxxOpts file, then runProgram will work."
]
[Modernise System.Exit import in wxc.
Eric Kow <eric....@gmail.com>**20120413161642
Ignore-this: 2bd4fbea71cf7f92e810074bb122b3da
Needed to build with GHC 7.4.1
]
[wx-config-win version suitable for Windows users building for wxWidgets 2.9.
jeremy.odonog...@gmail.com**20120413121421
Ignore-this: 153eb358c7244b0bf4469e32840be20f
The attached wx-confg-win directory is forked from http://wx-config-win.googlecode.com
and represents a substantially simplified implementation of the wx-config script.
Compared to the version at Google Code, this is modified as follows:
- Support wxWidgets 2.9 (by far the major change)
- Support build on Visual Studio as well as GCC
Note that he changes have *only* been tested for wxWidgets compiled with MinGW
compiler, and almost certainly will not work for wxWidgets compiled with other
compilers.
Note that wx-config.cpp can be successfully compiled using a MinGW compiler
with the following command line:
g++ wx-config.cpp -o wx-config.exe
For the convenience of those who do not have a working MinGW or Visual Studio
installation, I have included a pre-compiled and linked wx-config.exe which
will work if you place it in your path.
Note that this is a temporary work-around until I can find a way to cabal install
wx-config-win. Currently I find that ghc wx-config.cpp -lstdc++ compiles and
links, but is no use as it dynamically links libstdc++.dll, and this is not
in the path when time comes to run wx-config.§
]
[Put upper version bounds on wxHaskell for wxWidgets 2.8
jeremy.odonog...@gmail.com**20120413121209
Ignore-this: d7ce71f39546341cb0c8693b1f8eac8a
]
[TAG WXWIDGETS_2.9_SUPPORT_ADDED
jeremy.odonog...@gmail.com**20120413104141
Ignore-this: ce1e5237e084ab3ee063c17902ad02f9
]
Patch bundle hash:
1ab3c1ae15f70f134eda447d8f2d486b8258a4a9
1 patch for repository /home/mads/wxhaskell:
Thu Dec 13 19:33:34 CET 2012 mads.lidnstr...@gmail.com
* Import CInt, CWchar, CDoulbe so that it compiles on GHC 7.6.1
New patches:
[Import CInt, CWchar, CDoulbe so that it compiles on GHC 7.6.1
mads.lidnstr...@gmail.com**20121213183334
Ignore-this: e2b368d7a1d71cb93c7cfd2373314a5f
] {
hunk ./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs 263
import Graphics.UI.WXCore.Draw
import Graphics.UI.WXCore.Defines
+import Foreign.C.Types(CInt(..), CWchar(..))
+
------------------------------------------------------------------------------------------
-- Controls (COMMAND events)
------------------------------------------------------------------------------------------
hunk ./wxdirect/src/CompileClasses.hs 58
, "import " ++ module1
, "import " ++ module2
, "import " ++ moduleRoot ++ moduleClassTypesName
- , ""
]
]
hunk ./wxdirect/src/CompileClasses.hs 105
, "import System.IO.Unsafe( unsafePerformIO )"
, "import " ++ moduleRoot ++ "WxcTypes"
, "import " ++ moduleRoot ++ moduleClassTypesName
+ , "import Foreign.C.Types(CInt(..), CWchar(..), CDouble(..))"
, ""
]
]
}
Context:
[GTK-Fix: Removing dereferencing before setting to NULL
mads.lindstr...@gmail.com**20121204192412
Ignore-this: df2135dc42d1585dda5e8ffbe6ec0419
]
[Bump wxdirect version number to 0.90.0.1
shelarcy <shela...@gmail.com>**20120418143631
Ignore-this: 2fac8c2b54459864dab8c113ae0e3416
]
[Relax time package dependency to wxdirect-0.90
shelarcy <shela...@gmail.com>**20120418143433
Ignore-this: 1b8adf33d9d72971abd5205004bc1509
GHC 7.4.1's time package version is 1.4. So, wxdirect-0.90 requires to reinstall
time package less than 1.3 when using GHC 7.4.1.
http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html#id3019262
Only wxdirect-0.90 has this problem. Because wxdirect-0.13.1.2 already fixed this
problem and other package' time package dependencies are more relaxed form.
]
[Fix error building on some 32 bit targets.
jeremy.odonog...@gmail.com**20120414142124
Ignore-this: 212d1935582b619313032033a20834d
Apply patch due to Heinrich Apfelmus (apfel...@quantentunnel.de). His description
attached below:
"I just tripped over a bug in the Setup.hs belonging to wxc that
prevented me from compiling wxHaskell with 32bit architecture.
The problem is the following: in the function linkSharedLib , the
function runProgram is commented out and the function system is used
instead. This is not correct because gcc may (and in my case: does)
carry additional command line options! (Besides, the verbose output is
lost.)
Apparently, this was done because the runProgram didn't work for some
reason. The reason is that some command line options are actually two
arguments. In particular, setting the output file via
"-o " ++ out_dir </> sharedLibName ver basename,
is not correct, the right way to go about it are two arguments
"-o", out_dir </> sharedLibName ver basename,
Same for the "-install_name" option. Four lines need to be changed in
the linkCxxOpts file, then runProgram will work."
]
[Modernise System.Exit import in wxc.
Eric Kow <eric....@gmail.com>**20120413161642
Ignore-this: 2bd4fbea71cf7f92e810074bb122b3da
Needed to build with GHC 7.4.1
]
[wx-config-win version suitable for Windows users building for wxWidgets 2.9.
jeremy.odonog...@gmail.com**20120413121421
Ignore-this: 153eb358c7244b0bf4469e32840be20f
The attached wx-confg-win directory is forked from http://wx-config-win.googlecode.com
and represents a substantially simplified implementation of the wx-config script.
Compared to the version at Google Code, this is modified as follows:
- Support wxWidgets 2.9 (by far the major change)
- Support build on Visual Studio as well as GCC
Note that he changes have *only* been tested for wxWidgets compiled with MinGW
compiler, and almost certainly will not work for wxWidgets compiled with other
compilers.
Note that wx-config.cpp can be successfully compiled using a MinGW compiler
with the following command line:
g++ wx-config.cpp -o wx-config.exe
For the convenience of those who do not have a working MinGW or Visual Studio
installation, I have included a pre-compiled and linked wx-config.exe which
will work if you place it in your path.
Note that this is a temporary work-around until I can find a way to cabal install
wx-config-win. Currently I find that ghc wx-config.cpp -lstdc++ compiles and
links, but is no use as it dynamically links libstdc++.dll, and this is not
in the path when time comes to run wx-config.§
]
[Put upper version bounds on wxHaskell for wxWidgets 2.8
jeremy.odonog...@gmail.com**20120413121209
Ignore-this: d7ce71f39546341cb0c8693b1f8eac8a
]
[TAG WXWIDGETS_2.9_SUPPORT_ADDED
jeremy.odonog...@gmail.com**20120413104141
Ignore-this: ce1e5237e084ab3ee063c17902ad02f9
]
Patch bundle hash:
c6ec59b9234b41b7121e2c4433b6957eafea8df5
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
