Re: [Haskell-cafe] Can't build Gtk2hs on Windows
Ryan, thanks for adopting party. Daniel 2011/5/5 Ryan Yates : > Daniel, > > Nice summery. I think one of the difficult issues is my "patch" in > http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is something worthy > of scare quotes. I'm not a Cabal developer and I have no clue what > the implications of that change are. For all I know things would > cease working on Linux with the patch applied. I think it is sane, > but to verify that would require me to know a lot more about Cabal's > workings then I have time to do. Cabal-dev addresses this nicely in > that it isolates the unknowns. The global workaround is bad because > it is even less isolated but has the benefit that you do not have to > patch the setups. > > Another issue is that the gtk2hs Trac makes you login as guest. As > such, I can't add myself to the CC list and this makes it is hard to > tell how many people are running into this issue. Similarly the > gtk2hs website being down makes it look like gtk2hs is dead. I know > that it is in all likelihood down due to the server switch > (http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html). > The Trac issue is probably due to an updated version of Trac changing > how CC field is set. > > All of these little (very understandable) things compound the issue > and frustrate people. It is a good sign that people are expecting > things to work and the issues in the way are small. There are just > too few people with the means to fix those small issues, but I'm glad > they do the work they do. > > I'm also sending this to the gtk2hs list to see if it can get some > traction there. > > Ryan > > On Thu, May 5, 2011 at 4:25 AM, Daniel Kahlenberg > wrote: >> Hi, >> >> I have no spaces in my GTK installation path (h:\gtk+ there is no >> other gtk+, zlib1.dll etc. in my search path). The "patch" >> http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled >> when using the cab/cabal-dev combination as I described here: >> http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although >> this is no long-term solution, I agree. >> >> (I don't agree to let users require to install more or less arbitrary >> packages globally as long as a separation of permissions is reasonable >> for complex systems. Don't get me wrong: I would respect the advice if >> I had other information but I'm even not convinced.) >> >> The problem persists anyhow - with all backend gtk versions I tried - >> that building certain packages depending on the bundled cairo package, >> fail with a "unknown symbol `_cairo_image_surface_get_data'" error >> message >> The full description and bug tracing so far I described here: >> http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7 >> (also here >> http://osdir.com/ml/glasgow-haskell-us...@haskell.org/2011-04/msg7.html). >> >> All in all I even thought about replacing/augmenting the gtk+ calls in >> e. g. timeplot code by wx calls or something like that to have a >> chance to use these nice tools on windows too, to circumvent >> regression on parallel installs of legacy ghc versions, have no idea >> either ;) Maybe an API comparison table in the WIKI might help here. >> >> GTK versions I sampled (all three with ghc-7.0.3, the first one also >> with ghc-7.0.2), yielding overall the same results: >> >> http://ftp.acc.umu.se/pub/GNOME/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32 >> >> http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe >> >> http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the >> bundled tools manually installed using the components.lst file from >> the -2.22.1-* bundle as a reference. >> >> The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid >> for older gtk versions (until around 2.16) only and can be bypassed by >> adding -f-have-gio, enabling the non-gio build at least. >> >> I agree that it is possibly a windows only specific issue. Might even >> relate to my mingw+msys setup, although I explicitly used the >> mingw-get tool to install the whole build environment. Possibly the >> patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is >> an issue factor itself if it lead to incompatible situation. >> >> Greets >> Daniel >> >> 2011/5/5 Albert Y. C. Lai : >>> Just 5 weeks ago, >>> >>> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456 >>> >>> Did anyone see it? >>> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Gtk2hs on Windows
Hi, I have no spaces in my GTK installation path (h:\gtk+ there is no other gtk+, zlib1.dll etc. in my search path). The "patch" http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled when using the cab/cabal-dev combination as I described here: http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although this is no long-term solution, I agree. (I don't agree to let users require to install more or less arbitrary packages globally as long as a separation of permissions is reasonable for complex systems. Don't get me wrong: I would respect the advice if I had other information but I'm even not convinced.) The problem persists anyhow - with all backend gtk versions I tried - that building certain packages depending on the bundled cairo package, fail with a "unknown symbol `_cairo_image_surface_get_data'" error message The full description and bug tracing so far I described here: http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7 (also here http://osdir.com/ml/glasgow-haskell-us...@haskell.org/2011-04/msg7.html). All in all I even thought about replacing/augmenting the gtk+ calls in e. g. timeplot code by wx calls or something like that to have a chance to use these nice tools on windows too, to circumvent regression on parallel installs of legacy ghc versions, have no idea either ;) Maybe an API comparison table in the WIKI might help here. GTK versions I sampled (all three with ghc-7.0.3, the first one also with ghc-7.0.2), yielding overall the same results: http://ftp.acc.umu.se/pub/GNOME/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32 http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the bundled tools manually installed using the components.lst file from the -2.22.1-* bundle as a reference. The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid for older gtk versions (until around 2.16) only and can be bypassed by adding -f-have-gio, enabling the non-gio build at least. I agree that it is possibly a windows only specific issue. Might even relate to my mingw+msys setup, although I explicitly used the mingw-get tool to install the whole build environment. Possibly the patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is an issue factor itself if it lead to incompatible situation. Greets Daniel 2011/5/5 Albert Y. C. Lai : > Just 5 weeks ago, > > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456 > > Did anyone see it? > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to update the RNG per call (State monad) when generating QuickCheck arbitraries?
Hello, > the final RNG state from the first execution of your code and passing it as > the initial > state to the second original intention of my question: How can I change the runOneRandom function (with RNG updates) to return [ThingK True...] samples instead of Int? My solution so far: > import Random > import Control.Monad > import qualified Control.Monad.State as S > import Test.QuickCheck.Gen > import Test.QuickCheck.Arbitrary Each thing can have one of three types: > data Ontology = Thing1 Bool > | ThingK Bool > deriving (Show, Eq) > instance Arbitrary Ontology where >arbitrary = >oneof [ return $ Thing1 True > , return $ ThingK True > , return $ Thing1 False > , return $ ThingK False ] Liked to have a state monad runner for my arbitrary things as in "Real World Haskell", "Chapter 14. Monads" ("Random values in the state monad"). [RWH]: > -- file: ch14/Random.hs > type RandomState a = S.State StdGen a [RWH]: > -- file: ch14/Random.hs > getRandom :: Random a => RandomState a > getRandom = > S.get >>= \gen -> > let (val, gen') = random gen in > S.put gen' >> > return val [RWH]: > getOneRandom :: Random a => RandomState a > getOneRandom = getRandom [RWH]: < runOneRandom :: IO Int < runOneRandom = do < oldState <- getStdGen < let (result, newState) = S.runState getOneRandom oldState < setStdGen newState < return result Updated RNG is used. TODO How to sort out empty lists. > runOneRandom2 :: IO [Ontology] > runOneRandom2 = do > oldState <- getStdGen > let (result, newState) = S.runState (getOneRandom :: RandomState Int) > oldState > setStdGen newState > let result2 = unGen arbitrary newState 12 :: [Ontology] > return result2 To compare the behaviour: But the Random Number Generator isn't updated... I liked to have different [Ontology] occasions per call: > genArray :: [Ontology] > genArray = unGen arbitrary (mkStdGen 42) 12 :: [Ontology] On more question remains though: Is there a more haskellish way of doing this, especially having behaviour more like the arbitrary function with no empty samples allowed? Cheers Daniel 2011/4/26 Daniel Kahlenberg : > Oh thanks, > > hold on I'd like to have the genArray call generating distinctive > results in one IO execution (meaning when > I load the .lhs file in ghci): > > Prelude> genArray > [ThingK True,Thing1 False] > > and when calling immediately again e. g. > > Prelude> genArray > [Thing1 True] > > By now I only get one and the same again, i. e.: > > Prelude> genArray > [ThingK True] > > Prelude> genArray > [ThingK True] > > ... > > so I thought an adaptation of the `runTwoRandoms` approach as described > in the RWH book could help. > > In other words the genArray should have similar behaviour as e. g. a > `runOneRandom` function defined like: > >> getOneRandom :: Random a => RandomState a >> getOneRandom = getRandom > >> runOneRandom :: IO Int >> runOneRandom = do >> oldState <- getStdGen >> let (result, newState) = S.runState getOneRandom oldState >> setStdGen newState >> return result > > ... the rest of the code as in my first post... > > Testing it, different numbers expected as the RNG is updated each call: > > Prelude> runOneRandom > 2033303743 > > Prelude> runOneRandom > -566930973 > > ... > > Cheers > Daniel > > 2011/4/26 Bryan O'Sullivan : >> On Tue, Apr 26, 2011 at 3:04 AM, Daniel Kahlenberg >> wrote: >>> >>> Thought getRandom function would be the best place to inject my unGen >>> function >>> call, but cannot get it to type-check: >> >> You haven't described what it is you're actually trying to do, and I'm >> afraid your code doesn't help to understand that. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to update the RNG per call (State monad) when generating QuickCheck arbitraries?
Oh thanks, hold on I'd like to have the genArray call generating distinctive results in one IO execution (meaning when I load the .lhs file in ghci): Prelude> genArray [ThingK True,Thing1 False] and when calling immediately again e. g. Prelude> genArray [Thing1 True] By now I only get one and the same again, i. e.: Prelude> genArray [ThingK True] Prelude> genArray [ThingK True] ... so I thought an adaptation of the `runTwoRandoms` approach as described in the RWH book could help. In other words the genArray should have similar behaviour as e. g. a `runOneRandom` function defined like: > getOneRandom :: Random a => RandomState a > getOneRandom = getRandom > runOneRandom :: IO Int > runOneRandom = do > oldState <- getStdGen > let (result, newState) = S.runState getOneRandom oldState > setStdGen newState > return result ... the rest of the code as in my first post... Testing it, different numbers expected as the RNG is updated each call: Prelude> runOneRandom 2033303743 Prelude> runOneRandom -566930973 ... Cheers Daniel 2011/4/26 Bryan O'Sullivan : > On Tue, Apr 26, 2011 at 3:04 AM, Daniel Kahlenberg > wrote: >> >> Thought getRandom function would be the best place to inject my unGen >> function >> call, but cannot get it to type-check: > > You haven't described what it is you're actually trying to do, and I'm > afraid your code doesn't help to understand that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to update the RNG per call (State monad) when generating QuickCheck arbitraries?
Maybe this is a beginners question... But here my problems description: > import Random > import Control.Monad > import qualified Control.Monad.State as S > import Test.QuickCheck.Gen > import Test.QuickCheck.Arbitrary Each thing can have one of three types: > data Ontology = Thing1 Bool > | ThingK Bool > deriving (Show, Eq) > instance Arbitrary Ontology where >arbitrary = >oneof [ return $ Thing1 True > , return $ ThingK True > , return $ Thing1 False > , return $ ThingK False ] Liked to have a state monad runner for my arbitrary things as in "Real World Haskell", "Chapter 14. Monads" ("Random values in the state monad"). [RWH]: > -- file: ch14/Random.hs > type RandomState a = S.State StdGen a [RWH]: < -- file: ch14/Random.hs < getRandom :: Random a => RandomState a < getRandom = < S.get >>= \gen -> < let (val, gen') = random gen in < S.put gen' >> < return val [RWH]: < -- file: ch14/Random.hs < getTwoRandoms :: Random a => RandomState (a, a) < getTwoRandoms = liftM2 (,) getRandom getRandom [RWH]: < -- file: ch14/Random.hs < runTwoRandoms :: IO (Int, Int) < runTwoRandoms = do < oldState <- getStdGen < let (result, newState) = S.runState getTwoRandoms oldState < setStdGen newState < return result Thought getRandom function would be the best place to inject my unGen function call, but cannot get it to type-check: > getRandom :: Random a => RandomState [a] > getRandom = > S.get >>= \gen -> > let (val, gen') = liftM2 (,) (unGen arbitrary gen 12) (random gen) in > S.put gen' >> > return val A function not almost fulfilling my needs but the Random Number Generator isn't updated... I liked to have different [Ontology] occasions per call: > genArray :: [Ontology] > genArray = unGen arbitrary (mkStdGen 42) 12 :: [Ontology] Does anyone have the patience to help me out at least one step further? Cheers Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] already installed packages alerted as not being installed
Ingenious, finally it is possible at least with the help of those two tools cabal-dev and cab to build the threadscope executable on Windows linked against gtk+-bundle_2.22.1-20101227_win32 version, thanks again to their developers. [Note to myself] How I did, 1) as described in http://hackage.haskell.org/trac/gtk2hs/ticket/1203#comment:2 edited each Gtk2HsSetup.hs file 2) In a mingw+msys shell (tar is needed, how to install -> I strongly recommend using mingw-get-inst: http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/ to mention at a first place, you can easily add things then with the bundled mingw-get command) did pushd /h/.homedir cabal-dev add-source /h/.homedir/gtk2hs-buildtools-0.12.0/ /h/.homedir/glib-0.12.0/ /h/.homedir/cairo-0.12.0/ /h/.homedir/gio-0.12.0/ /h/.homedir/glade-0.12.0/ /h/.homedir/pango-0.12.0/ /h/.homedir/gtk-0.12.0/ cab install threadscope --sandbox=/h/.homedir/cabal-dev To be honest the last command I even run at the Windows cmd.exe prompt. This all means h:/.homedir/cabal-dev contains the formerly broken dependencies sources patched by my edits in the .cabal files. It is used (--sandbox parameter) as a first repository for building threadscope later on, the other dependencies are loaded remotely by demand. The reason for breaking with cabal I could see as mentioned above by Kazu, with: cab install threadscope -n threadscope needed different versions than the dependencies pre-installed with my former gtk2hs installation trial had. Cheers Daniel 2011/4/11 Kazu Yamamoto : > Hello, > >> thanks I wanted to mention that the "unknown symbol" error is very >> likely not related to the cab tool as the same error appears, when >> using the cabal - tool. I guess we can ignore it even in the context >> of my main question, sorry for being to verbose. What I found more >> interesting is, that cab doesn't try to re-install an installed >> package - already in the database too, as ghc-pkg output pretends - >> which is expected behaviour. The cabal system frontend obviously does >> trying to reinstall the package though. This seems like different >> model of reality... > > This is not true. > > cab install re-installs some packages if necessary, unfortunately. > That's why I recommend to use "cab install -n". > > --Kazu > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] already installed packages alerted as not being installed
Kazu, thanks I wanted to mention that the "unknown symbol" error is very likely not related to the cab tool as the same error appears, when using the cabal - tool. I guess we can ignore it even in the context of my main question, sorry for being to verbose. What I found more interesting is, that cab doesn't try to re-install an installed package - already in the database too, as ghc-pkg output pretends - which is expected behaviour. The cabal system frontend obviously does trying to reinstall the package though. This seems like different model of reality... Cheers Daniel 2011/4/11 Kazu Yamamoto : > Hello, > >> When I install cabal-dev and cab first and then re-install everything >> with cab instead of cabal the issue with re-installing already >> installed packages described above disappears and only an "unknown >> symbol" message related to the correctly found installed cairo package >> remains. So is there an error in package database handling somewhere >> or changed semantics in cabal | ghc-pkg | (even) pkg-config flags I >> missed? > > "cab" is just a wrapper for "cabal" and "cabal-dev" for installation. > So, I have no idea about what's going on. > > Please try "cab install -n" to see what will happen before > typing "cab install ". If you find the word "reinstall", you > should not install the package because the installation operation will > break your package environment. > > You can analyze package dependency with: > cab deps -r > cab revdeps -r > cab list -r > > Adding the "-a" option displays global packages also. > > I recommend to use a sandbox when you try to resolve a dependency > problem. > > --Kazu > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] already installed packages alerted as not being installed
Hello cafe-readers, does anyone of you observe similar problems e. g. on a Windows with ghc-7.0.2 setup: When I'm trying cabal install threadscope (as an example package depending on gtk2hs, latter which I've installed using the stepwise approach of cabal unpack first, then cabal configure --user etc.) it complains about cairo etc. not being installed and tries to re-install it on-the-fly, failing due to whats described her: http://hackage.haskell.org/trac/gtk2hs/ticket/1203! When I install cabal-dev and cab first and then re-install everything with cab instead of cabal the issue with re-installing already installed packages described above disappears and only an "unknown symbol" message related to the correctly found installed cairo package remains. So is there an error in package database handling somewhere or changed semantics in cabal | ghc-pkg | (even) pkg-config flags I missed? Cheers Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Glade problem solved Was: Compile Glade apps (MS Windows system) Was: Re: Trying to compile Glade Gtk2Hs demo / cabal install glade problem
Hi list again, I'm happy to tell you the solution at least to my install problem: ??? is synonym for D:/Programme/Gtk+ on my example setup. Download glade3-3.6.7-with-GTK+.exe (http://ftp.gnome.org/pub/GNOME/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe) Install. Download libxml2_2.7.7-1_win32.zip and libxml2-dev_2.7.7-1_win32.zip (http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/libxml2_2.7.7-1_win32.zip http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/libxml2-dev_2.7.7-1_win32.zip): Install and you get libxml-2.0.pc (in ???/lib/pkgconfig). My PKG_CONFIG_PATH variables first entry is D:/Programme/Gtk+/lib/pkgconfig (note forward slash char.), to prefer new copied libxml2 files over others I had. Using bash... $ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin:/etc:/usr/local/bin:/usr/bin/X11:/h/gvimportable:/d/Programme/Gtk+/bin:/c/Users/daniel/Appdata/Roaming/cabal/bin:/c/PROGRA~2/HASKEL~1/201020~1.0/lib/extralibs/bin:/c/PROGRA~2/HASKEL~1/201020~1.0/bin:/c/PROGRA~2/HASKEL~1/201020~1.0/mingw/bin:/h/MinGW32/bin Nothing more needed for sucessful cabal install, assuming gtk2hs installation succeeded as happened. Pitfall was: Most likely a wrong libxml version taken from those other pkgconfig places I had. Cool, now I can install threadscope and do learn effects of different parallelisation strategies as pointed out in those nice papers. Cheers Daniel On 10.09.2010 20:00, Daniel Kahlenberg wrote: >> Great help! > That's sounds very promising. Lucky you! Would you share the information > with the list - at least I'm really interested in how getting exactly > this done. >> New "cabal install glade" after libglade-2.0.pc edit: > Would you share information about that?? See my comment above... > > Thanks for reading > Daniel > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compile Glade apps (MS Windows system) Was: Re: Trying to compile Glade Gtk2Hs demo / cabal install glade problem
Hello, I'm searching for information on a solution that must have been found earlier on the list and somehow must have got lost, but have a look now please... On 14.08.2010 00:47, Peter Schmitz wrote: > Thanks so very much Axel and Ivan. > You were both absolutely correct and I can compile Glade apps now fine. > Great help! That's sounds very promising. Lucky you! Would you share the information with the list - at least I'm really interested in how getting exactly this done. > The tricky part (for me) would have been looking at the error from > cabal install glade: > "setup.exe: The pkg-config package libglade-2.0 version >=2.0.0 > is required but it could not be found." > and determining that the problem was that libglade-2.0.pc needed the > edit you described, > but I made the edit and it all works now. > > -- Peter > ... > New "cabal install glade" after libglade-2.0.pc edit: Would you share information about that?? See my comment above... Thanks for reading Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Did anyone manage to build glade hackage-package on Windows
Hi list again, if there is anyone who managed to build the glade package on the Windows platform, could you please tell me the installer package for glade you used, possibly the version and download source too? Installing gtk2hs now seems made really simply by the guys providing it and I installed and tested it successfully on a Windows machine. Where I'm stucking is the glade/libglade thing. I took the version from http://ftp.gnome.org/pub/GNOME/binaries/win32/libglade/2.6/ for a start and installed some http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/too, but when running the cabal-configure step it halts with the oh so familiar: * Missing C libraries: glade-2.0, gtk-win32-2.0, xml2, gdk-win32-2.0, atk-1.0, gio-2.0, gdk_pixbuf-2.0, pangowin32-1.0, gdi32, pangocairo-1.0, pango-1.0, cairo, gobject-2.0, gmodule-2.0, glib-2.0, intl This is my user ghc-pkg cache list: ...APPDATA...\ghc\i386-mingw32-6.12.3\package.conf.d: SDL-0.6.2 base64-bytestring-0.1.0.0 cairo-0.11.1 gio-0.11.1 glib-0.11.2 gtk-0.11.2 pango-0.11.2 random-1.0.0.2 And my pkg-config output: cmd> pkg-config --cflags --libs gtk+-2.0 libglade-2.0" -mms-bitfields -IH:/takeoffgw/i686-pc-mingw32/sys-root/mingw/include/libxml2 -IH :/takeoffgw/usr/local/include/gtk-2.0 -IH:/takeoffgw/usr/local/lib/gtk-2.0/inclu de -IH:/takeoffgw/usr/local/include/atk-1.0 -IH:/takeoffgw/usr/local/include/cai ro -IH:/takeoffgw/usr/local/include/pango-1.0 -IH:/takeoffgw/usr/local/include/g lib-2.0 -IH:/takeoffgw/usr/local/lib/glib-2.0/include -IH:/takeoffgw/usr/local/i nclude/freetype2 -IH:/takeoffgw/usr/local/include -IH:/takeoffgw/usr/local/inclu de/libpng14 -IH:/takeoffgw/usr/local/include/libglade-2.0 -LH:/takeoffgw/i686-p c-mingw32/sys-root/mingw/lib -LH:/takeoffgw/usr/local/lib -lglade-2.0 -lgtk-win3 2-2.0 -lxml2 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangowin32-1 .0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgt hread-2.0 -lglib-2.0 -lintl ExitSuccess ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Slightly humorous: Headhunters toolbox (example for Germany)
Hi list, stumbled across that: http://www.google.com/insights/search/?hl=de#q=haskell&geo=DE&cmpt=q Greetz Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] zlib or digest package installation
Hi, when installing pandoc package, which has digest somewhere in dependencies the usual cabal install stucks because zlib.h is missing, so I explicitly installed zlib package first, then installing digest (can also replace that directly with pandoc here) with the --extra-include-dirs parameter set: Prelude System.Cmd> > rawSystem "cabal" ["install", "digest", "-v3", "--user", "-- > build-log=d:/temp/log/build-$$pkgid-$$compiler-msys.log", "--reinstall", > "--data > dir=$$prefix/haskell-pkgdata", > "--extra-include-dirs=C:\\Users\\daniel\\AppData\ > \Roaming\\cabal\\zlib-0.5.2.0\\ghc-6.12.1\\include"] Is there something to improve in one of the packages cabal file to overcome the need to explicitly specify the header file locations of already installed packages or is that a consequence of not installing them as developer packages simply, so i. e. to have the header file zlib.h at the specified location is more a bonus to have in that situation? Greetz Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)
On 18.06.2010 17:07, JP Moresmau wrote: > got around by making sure every thing was installed with --global I forgot using the --global flag to be complete, so here is the full command in a ghci session (account with full access rights, msys tools on path) again: Prelude System.Cmd> > rawSystem "cabal" ["upgrade", "directory", "-v3", "--build-log=d:/temp/ > log/build-$$pkgid-$$compiler-msys.log", "--extra-include-dirs=C:\\Progra > m Files (x86)\\Haskell Platform\\2010.1.0.0\\lib\\include", "--global"] Otherwise things will be installed in privileged users package file. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)
On 18.06.2010 17:07, JP Moresmau wrote: > > > On Fri, Jun 18, 2010 at 4:48 PM, Daniel Kahlenberg > mailto:d.kahlenb...@googlemail.com>> wrote: > Prelude System.Cmd> > > rawSystem "cabal" ["upgrade", "--constraint=base==4.*", "directory", > > "-v3", "--user", > > "--build-log=d:/temp/log/build-$$pkgid-$$compiler.log"] > > I see on the gcc command line: > > -IC:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0/include So, is it a bug in the cabal file?? Proposing > include-dirs: include had to be something like: > if os(windows) { > include-dirs: lib/include > } else { > include-dirs: include > } > > On my machine, HsFFI.h is in lib/include, so maybe try with > --extra-include-dirs=-IC:\\Program Files (x86)\\Haskell > Platform\\2010.1.0.0\\lib\\include Cool! To be more exact in my case it was: --extra-include-dirs=C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\lib\\include > > I also ran into problems with the directory package on windows, that I > got around by making sure every thing was installed with --global You're right. I guess, this is intended and won't be changed? Because directory is kind of core package, right? Installing it in the user package data file would complicate things more than it would help to keep things on different access levels? As a general question this means, certain packages won't ever be installable without special access rights on a standard system, on the other side one could simply install the HP and global packages to a writable folder (against the proposed one on a Windows system), although my experiences didn't left me very optimistic about non-standard solutions in this case. On the other hand, one could upgrade GHC manually or wait for the next HP, where the above mentioned objections counted too, though seem weaker. Cheers Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)
Hello, I recently installed HP 2010.1.0.0 within Windows 7 and wanted to upgrade the Cabal package to 1.8.0.6 today, sadly I got stuck on a failure building the "directory" package. So I tried to isolate the messages a bit and gave the following a try in a ghci session (1st time only with path to cygwin binaries/2nd time only with path to msys binaries added on my path variable, for both times I append the logging output): Prelude System.Cmd> > rawSystem "cabal" ["upgrade", "--constraint=base==4.*", "directory", > "-v3", "--user", > "--build-log=d:/temp/log/build-$$pkgid-$$compiler.log"] Maybe we can find the cause?! Greetz Daniel Configuring directory-1.0.1.1... Creating dist (and its parents) searching for ghc in path. found ghc at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\ghc.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc.exe",["--numeric-version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\ghc.exe is version 6.12.1 looking for package tool: ghc-pkg near compiler in C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin found package tool in C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc-pkg.exe",["--version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe is version 6.12.1 ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc-pkg.exe",["dump","--global","-v2"]) ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc-pkg.exe",["dump","--user","-v2"]) Dependency Win32 ==2.2.0.2: using Win32-2.2.0.2 Dependency base ==4.2.0.0: using base-4.2.0.0 Dependency filepath ==1.1.0.4: using filepath-1.1.0.4 Dependency old-time ==1.0.0.5: using old-time-1.0.0.5 searching for alex in path. found alex at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\lib\extralibs\bin\alex.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\lib\\extralibs\\bin\\alex.exe",["--version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\lib\extralibs\bin\alex.exe is version 2.3.2 searching for ar in path. found ar at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\bin\ar.exe searching for c2hs in path. Cannot find c2hs on the path searching for cpphs in path. Cannot find cpphs on the path searching for ffihugs in path. Cannot find ffihugs on the path ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\mingw\\bin\\gcc.exe",["-dumpversion"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\bin\gcc.exe is version 3.4.5 searching for greencard in path. Cannot find greencard on the path searching for haddock in path. found haddock at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\haddock.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\haddock.exe",["--version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\haddock.exe is version 2.7.2 searching for happy in path. found happy at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\lib\extralibs\bin\happy.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\lib\\extralibs\\bin\\happy.exe",["--version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\lib\extralibs\bin\happy.exe is version 1.18.4 searching for hmake in path. Cannot find hmake on the path searching for hsc2hs in path. found hsc2hs at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\hsc2hs.exe ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\hsc2hs.exe",["--version"]) C:\Program Files (x86)\Haskell Platform\2010.1.0.0\bin\hsc2hs.exe is version 0.67 searching for HsColour in path. Cannot find HsColour on the path searching for hugs in path. Cannot find hugs on the path searching for jhc in path. Cannot find jhc on the path ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\bin\\ghc.exe",["-c","C:\\Users\\daniel\\AppData\\Local\\Temp\\3272.c","-o","C:\\Users\\daniel\\AppData\\Local\\Temp\\3272.o"]) ("C:\\Program Files (x86)\\Haskell Platform\\2010.1.0.0\\mingw\\mingw32\\bin\\ld.exe",["-x","-r","C:\\Users\\daniel\\AppData\\Local\\Temp\\3272.o","-o","C:\\Users\\daniel\\AppData\\Local\\Temp\\3273.o"]) searching for lhc in path. Cannot find lhc on the path searching for lhc-pkg in path. Cannot find lhc-pkg on the path searching for nhc98 in path. Cannot find nhc98 on the path searching for pkg-config in path. Cannot find pkg-config on the path searching for ranlib in path. found ranlib at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\bin\ranlib.exe searching for strip in path. found strip at C:\Program Files (x86)\Haskell Platform\2010.1.0.0\mingw\bin\strip.exe searching for tar in path. found tar at H:\zsh\bin\tar.exe Using Cabal-1.8.0.2 compiled by ghc-6.12 Using compiler: ghc-6.12.1 Using install prefix: C:\Users\daniel\AppData\Roaming\cabal Binaries installed in: C:\Users\daniel\AppData\Roaming\cabal
Re: [Haskell-cafe] Re: Cabal update problem
Hello, I guess I did the follwoing to bypass this problems. With the platform provided* cabal.exe at first place in the PATH variable, I run: - cabal update - cabal install cabal-install-0.6.4 The only thing remaining was, I had the Cabal-1.8.0.2 and related entries in my local package.conf file then, from the former installation of cabal-install-0.8.0 - which failed when doing `cabal update` as you described. I decided to remove those entries/packages, although they seemed to cause no issues, when blindly testing some package installations with cabal-install-0.6.4. Cheers Daniel * folder %HASKELL_PLATFORM%\extralibs\bin Am 19.02.2010 17:15, schrieb Maciej Podgurski: But the platform only includes cabal-install-0.6.2. My intention was getting the merge-all-package-documentation-into-single-html feature :-) Best wishes, Maciej Am 19.02.2010 16:50 schrieb Bas van Gijzel: I had the same problem on Windows XP when doing cabal install cabal-install. I fixed it by just replacing the cabal-install executable by the old one used in the haskell platform. Cheers, Bas On 19 February 2010 16:11, Maciej Podgurski wrote: Am 19.02.2010 15:29 schrieb Christian Maeder: Sorry, I've got no further idea (except reinstalling everything). http://hackage.haskell.org/trac/hackage/ticket/562 may be related. Did your installation of cabal-install-0.8.0 also reinstall HTTP and zlib packages? Yes, I installed the latest versions of that packages. Now I tried to gradually go back to the versions before (HTTP-4000.0.9 to 4000.0.7 and zlib-0.5.2.0 to 0.5.0.0), without any success. Finally cabal-install made it at version 0.6.2, so the problem really seems to be at cabal-install-0.8.0. Good luck Christian Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: (Solved) cabal install with external gcc tool chain not the ghc-bundled one
to answer this question myself how the use of another gcc is specified with effect, I used the following options with the 'cabal install' call: --ghc-options="-pgmc e:/programme/ghc/mingw-gcc4/bin/gcc.exe -pgml e:/programme/ghc/mingw-gcc4/bin/gcc.exe" See http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#replacing-phases (searched in the wrong direction, too many trees...). Slightly tuned, this should be the way to go in all similar cases. One thing I haven't considered yet is if the '--with-ld' and '--with-gcc' options (if curious too, see logs in my previous mail - Subject "[Haskell-cafe] caba install with external gcc toolchain not the ghc-bundled one") only effect what gets written into the setup-config/package.conf file or what other effects these have. Greets Daniel --- Begin Message --- Hello friends, I have a question regarding one thing I can't get my head around: First my problem is, that wanted to install 'bindings-common' here on my Windows machine. Usually that is no problem with the help of the glorious cabal. Now, 'bindings-common' needs a higher version of gcc than the one bundled with ghc-6.10.4 to build as the developer told me, so I install the gcc version 4.4.0 by mingw and try to give the needed options to 'cabal install bindings-common...' - '--with-gcc=... --with-ld=...' etc. - At the same time I log everything cabal is putting to the outside world when doing the tasks for building the 'binding-commons': For this sake I use the '--build-log=...' option of 'cabal install' and at the same time pipe what gets shown on the terminal with 'tee' as well as verbosity level 3 for 'cabal install'. So far nothing new... But the package isn't built, so I wonder what the transcript is saying and have a look at the two generated log files, stating that the one generated by 'tee' tells me another linker (the one coming with the ghc-6.10.4 bundle) than I thought to have specified is actually used. An excerpt from the tee built log file: *** Linker: E:\programme\ghc\ghc-6.10.4\gcc -BE:\programme\ghc\ghc-6.10.4\gcc-lib/ ... Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc ... Thread model: win32 gcc version 3.4.5 (mingw-vista special r3) (Sorry if I'm mis-interpreting something here) While the log file resulting from the '--build-log' cabal install option has nothing suspicious in it telling me to (plan to?) use exactly what I specified by options. A little excerpt from that log file: ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\hsc2hs.exe",["--cc=e:/programme/ghc/mingw-gcc4/bin/gcc.exe","--ld=e:/programme/ghc/mingw-gcc4/bin/gcc.exe","--cflag=-Be:/programme/ghc/mingw-gcc4/lib/","--cflag=-Ie:/programme/ghc/mingw4-gcc/include","--cflag=-Le:/programme/ghc/mingw-gcc4/lib","--lflag=-Be:/programme/ghc/mingw-gcc4/lib/","--lflag=-Ie:/programme/ghc/mingw4-gcc/include","--lflag=-Le:/programme/ghc/mingw-gcc4/lib","--cflag=-D__GLASGOW_HASKELL__=610","--cflag=-Isrc","--cflag=-Ie:/programme/ghc/mingw-gcc4/include","--cflag=-D_ISOC99_SOURCE","--lflag=-Le:/programme/ghc/mingw-gcc4/lib","--cflag=-Ie:\\programme\\ghc\\ghc-6.10.4\\base-4.1.0.0\\include","--cflag=-Ie:\\programme\\ghc\\ghc-6.10.4/include","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\base-3.0.3.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\syb-0.1.0.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\base-4.1.0.0","--lflag=-lwsock32","--lflag=-luser32","--lflag=-lshell32","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\integer-0 .1.0.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\ghc-prim-0.1.0.0","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4/gcc-lib","--lflag=-lm","--lflag=-lffi","--lflag=-lgmp","--lflag=-lwsock32","-o","H:\\.homedir\\hugsdata\\build\\Bindings\\C\\Ctype.hs","src\\Bindings\\C\\Ctype.hsc"]) ... Using ld given by user at: e:/programme/ghc/mingw-gcc4/bin/ld.exe So now my question is: Can anybody give me a good hint or tell me how I would, aside from using hard links or other file system related tasks, specify the external compiler, linker or gcc-toolchain to be used by 'cabal install' (or in consequence by 'ghc')? Cheers and thanks for your Daniel searching for ghc in path. found ghc at e:\programme\ghc\ghc-6.10.4\bin\ghc.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--numeric-version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in e:\programme\ghc\ghc-6.10.4\bin found package tool in e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["--version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe is version 6.10.4 ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--global"]) ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--package-conf=h:\\.homedir\\ghc\\i386-mingw32-6.10.4\\package.conf"]) Reading available packa
[Haskell-cafe] caba install with external gcc toolchain not the ghc-bundled one
Hello friends, I have a question regarding one thing I can't get my head around: First my problem is, that wanted to install 'bindings-common' here on my Windows machine. Usually that is no problem with the help of the glorious cabal. Now, 'bindings-common' needs a higher version of gcc than the one bundled with ghc-6.10.4 to build as the developer told me, so I install the gcc version 4.4.0 by mingw and try to give the needed options to 'cabal install bindings-common...' - '--with-gcc=... --with-ld=...' etc. - At the same time I log everything cabal is putting to the outside world when doing the tasks for building the 'binding-commons': For this sake I use the '--build-log=...' option of 'cabal install' and at the same time pipe what gets shown on the terminal with 'tee' as well as verbosity level 3 for 'cabal install'. So far nothing new... But the package isn't built, so I wonder what the transcript is saying and have a look at the two generated log files, stating that the one generated by 'tee' tells me another linker (the one coming with the ghc-6.10.4 bundle) than I thought to have specified is actually used. An excerpt from the tee built log file: *** Linker: E:\programme\ghc\ghc-6.10.4\gcc -BE:\programme\ghc\ghc-6.10.4\gcc-lib/ ... Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc ... Thread model: win32 gcc version 3.4.5 (mingw-vista special r3) (Sorry if I'm mis-interpreting something here) While the log file resulting from the '--build-log' cabal install option has nothing suspicious in it telling me to (plan to?) use exactly what I specified by options. A little excerpt from that log file: ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\hsc2hs.exe",["--cc=e:/programme/ghc/mingw-gcc4/bin/gcc.exe","--ld=e:/programme/ghc/mingw-gcc4/bin/gcc.exe","--cflag=-Be:/programme/ghc/mingw-gcc4/lib/","--cflag=-Ie:/programme/ghc/mingw4-gcc/include","--cflag=-Le:/programme/ghc/mingw-gcc4/lib","--lflag=-Be:/programme/ghc/mingw-gcc4/lib/","--lflag=-Ie:/programme/ghc/mingw4-gcc/include","--lflag=-Le:/programme/ghc/mingw-gcc4/lib","--cflag=-D__GLASGOW_HASKELL__=610","--cflag=-Isrc","--cflag=-Ie:/programme/ghc/mingw-gcc4/include","--cflag=-D_ISOC99_SOURCE","--lflag=-Le:/programme/ghc/mingw-gcc4/lib","--cflag=-Ie:\\programme\\ghc\\ghc-6.10.4\\base-4.1.0.0\\include","--cflag=-Ie:\\programme\\ghc\\ghc-6.10.4/include","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\base-3.0.3.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\syb-0.1.0.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\base-4.1.0.0","--lflag=-lwsock32","--lflag=-luser32","--lflag=-lshell32","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\integer-0 .1.0.1","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4\\ghc-prim-0.1.0.0","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4","--lflag=-Le:\\programme\\ghc\\ghc-6.10.4/gcc-lib","--lflag=-lm","--lflag=-lffi","--lflag=-lgmp","--lflag=-lwsock32","-o","H:\\.homedir\\hugsdata\\build\\Bindings\\C\\Ctype.hs","src\\Bindings\\C\\Ctype.hsc"]) ... Using ld given by user at: e:/programme/ghc/mingw-gcc4/bin/ld.exe So now my question is: Can anybody give me a good hint or tell me how I would, aside from using hard links or other file system related tasks, specify the external compiler, linker or gcc-toolchain to be used by 'cabal install' (or in consequence by 'ghc')? Cheers and thanks for your Daniel searching for ghc in path. found ghc at e:\programme\ghc\ghc-6.10.4\bin\ghc.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--numeric-version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in e:\programme\ghc\ghc-6.10.4\bin found package tool in e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["--version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe is version 6.10.4 ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--global"]) ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--package-conf=h:\\.homedir\\ghc\\i386-mingw32-6.10.4\\package.conf"]) Reading available packages... Resolving dependencies... selecting bindings-common-1.3.3 (hackage) and discarding bindings-common-0.1, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.2, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 1.0, 1.1, 1.2, 1.3, 1.3.1 and 1.3.2 selecting base-3.0.3.1 (installed) and 4.1.0.0 (installed) and discarding syb-0.1.0.0 and 0.1.0.1 selecting ghc-prim-0.1.0.0 (installed) selecting integer-0.1.0.1 (installed) selecting rts-1.0 (installed) selecting syb-0.1.0.1 (installed) In order, the following would be installed: bindings-common-1.3.3 (new package) bindings-common-1.3.3 has already been downloaded. Extracting C:\Dokumente und Einstellungen\Zyx\Anwendungsdaten\cabal\packages\hackage.haskell.org\bindings-common\1.3.3\bindings-common-1.3.3.tar.gz to c:\DOKUME~1\Zyx\LOKALE~1\Temp\bindings-common-1.3.31176... Using external setup method with b
[Haskell-cafe] cabal with non-default cc1
Hello friends, I want a package which can't be built with the version of gcc coming with the current release of ghc, so I installed a sufficient version of gcc and called cabal with the parameters that should override it's default settings (see the failure.log, line 112). But I have the impression(*) that the remaining process doesn't use my settings related to the version of cc1 to use but still uses the one coming with ghc (6.10.4). Can you help further? Cheers Daniel * See: "*** Assembler:", "*** Linker:" searching for ghc in path. found ghc at e:\programme\ghc\ghc-6.10.4\bin\ghc.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--numeric-version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc.exe is version 6.10.4 looking for package tool: ghc-pkg near compiler in e:\programme\ghc\ghc-6.10.4\bin found package tool in e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["--version"]) e:\programme\ghc\ghc-6.10.4\bin\ghc-pkg.exe is version 6.10.4 ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["--supported-languages"]) Reading installed packages... ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--global"]) ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc-pkg.exe",["dump","--package-conf=h:\\.homedir\\ghc\\i386-mingw32-6.10.4\\package.conf"]) Reading available packages... Resolving dependencies... selecting bindings-common-1.3.3 (hackage) and discarding bindings-common-0.1, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.2, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 1.0, 1.1, 1.2, 1.3, 1.3.1 and 1.3.2 selecting base-3.0.3.1 (installed) and 4.1.0.0 (installed) and discarding syb-0.1.0.0 and 0.1.0.1 selecting ghc-prim-0.1.0.0 (installed) selecting integer-0.1.0.1 (installed) selecting rts-1.0 (installed) selecting syb-0.1.0.1 (installed) In order, the following would be installed: bindings-common-1.3.3 (new package) bindings-common-1.3.3 has already been downloaded. Extracting C:\Dokumente und Einstellungen\Zyx\Anwendungsdaten\cabal\packages\hackage.haskell.org\bindings-common\1.3.3\bindings-common-1.3.3.tar.gz to c:\DOKUME~1\Zyx\LOKALE~1\Temp\bindings-common-1.3.31176... Using external setup method with build-type Simple Creating h:\.homedir\hugsdata\setup (and its parents) Using Cabal library version 1.6.0.3 Using h:\.homedir\hugsdata\setup\setup.hs as setup script. Setup script is out of date, compiling... ("e:\\programme\\ghc\\ghc-6.10.4\\bin\\ghc.exe",["-v","--make","h:\\.homedir\\hugsdata\\setup\\setup.hs","-o","h:\\.homedir\\hugsdata\\setup\\setup.exe","-odir","h:\\.homedir\\hugsdata\\setup","-hidir","h:\\.homedir\\hugsdata\\setup","-i","-ic:\\DOKUME~1\\Zyx\\LOKALE~1\\Temp\\bindings-common-1.3.31176\\bindings-common-1.3.3","-no-user-package-conf","-package-conf","h:\\.homedir\\ghc\\i386-mingw32-6.10.4\\package.conf","-package","Cabal-1.6.0.3"]) Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.1 Using package config file: E:\programme\ghc\ghc-6.10.4\package.conf Using package config file: h:\.homedir\ghc\i386-mingw32-6.10.4\package.conf Using package config file: h:\.homedir\ghc\i386-mingw32-6.10.4\package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1 hiding package parsec-2.1.0.1 to avoid conflict with later version parsec-3.0.1 hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.2 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *H:\.homedir\hugsdata\setup\setup.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Mon Nov 9 14:45:34 Westeuropäische Normalzeit 2009 ms_mod = main:Main, ms_imps = [Distribution.Simple] ms_srcimps = [] }] compile: input file H:\.homedir\hugsdata\setup\setup.hs Created temporary directory: C:\DOKUME~1\Zyx\LOKALE~1\Temp\/ghc2388_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( H:\.homedir\hugsdata\setup\setup.hs, H:\.homedir\hugsdata\setup\Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 8 *** Simplify: Result size = 6 Result size = 6 *** Tidy Core: Result size = 6 writeBinIface: 1 Names writeBinIface: 28 dict entries *** CorePrep: Result size = 6 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: E:\programme\ghc\ghc-6.10.4\gcc -BE:\programme\ghc\ghc-6.10.4\gcc-lib/ -IE:\programme\ghc\ghc-6.10.4\include/
[Haskell-cafe] [Haskell Beginner] Compiling wxhaskell fails for me
Hi, I try to build the current wxhaskell stuff from the darcs repository on the sh provided by msys with mingw32 (`uname -a' : MINGW32_NT-5.1 ... 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys), but it fails with the message `wx/graphics.h' isn't found, when it comes to build the wxc part. On the wxhaskell site they advice to use the 2.6.x version of the wxWidgets distribution, which I followed so far. The tool call which sets the wxversion variable (`wx-config --version') is executed and returns 2.6.4. The searched hosted graphics.h as I determined seems available as part of the 2.8.x version of wxwidgets at first. Now my question: Why does the build process search for it, especially how do I get it to succeed. Would I have to use the 2.8.x version against the recommendation? Has anyone of you successfully built the recommended version of the bindings, if yes - how? Could you share? Did I forget to build something on the wxwidgets side? Thank you so far Daniel. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: System.Console.Readline stifleHistory Question
OK, I detected it was my own fail: I was misleaded by the creation of the persistence file, which doesn't result from Readline.hs but simply from the rlwrap utility I earlier piped in before the ghci call. For those interested, the answer to the original question as usual from the man page: option --histsize N for rlwrap does the job. Maybe for a later discussion of using readline or some compatibility library instead of the rlwrap tool on ms windows systems I will post an extra message with a link. Bye. -- Forwarded message -- From: Daniel Kahlenberg <[EMAIL PROTECTED]> Date: 2008/6/27 Subject: System.Console.Readline stifleHistory Question To: haskell-cafe@haskell.org Hello all, I'm learning Haskell and so very likely will have advantages from the history persistence feature added to the ghci haskell interpreter. It drives very well in my setup (the history file is growing and used), but I wanted to increase the number of saved history entries and now my question concerning ghci: In the ticket (http://hackage.haskell.org/trac/ghc/ticket/2050) associated with the feature, there's written that one can call stifleHistory in its dotghci file. Have done it like: :m +System.Console.Readline stifleHistory 300 :m -System.Console.Readline but now my ghci.exe says: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. :1:0: Not in scope: `stifleHistory' `uname -r`: MINGW32_NT-5.1 CLE10 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys Do you have an idea, where I'm wrong? I'm starting my ghci session from zsh shell, provided by cygwin, wrapped in a tty emulator: $Drive\puttycyg\putty.exe -cygterm $Drive\zsh\bin\zsh.exe -p -c 'PATH=/cygdrive/h/zsh/bin:$PATH HOME=/cygdrive/h/.homedir rlwrap $(which ghcii.sh) -package-conf $Drive/.homedir/ghc/i386-mingw32-6.8.3/package.conf -read-dot-ghci' So I did not expect Readline not to work, but maybe the ghc system only sees the result from `uname -r` above?? Bye, Daniel. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Console.Readline stifleHistory Question
Hello all, I'm learning Haskell and so very likely will have advantages from the history persistence feature added to the ghci haskell interpreter. It drives very well in my setup (the history file is growing and used), but I wanted to increase the number of saved history entries and now my question concerning ghci: In the ticket (http://hackage.haskell.org/trac/ghc/ticket/2050) associated with the feature, there's written that one can call stifleHistory in its dotghci file. Have done it like: :m +System.Console.Readline stifleHistory 300 :m -System.Console.Readline but now my ghci.exe says: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. :1:0: Not in scope: `stifleHistory' `uname -r`: MINGW32_NT-5.1 CLE10 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys Do you have an idea, where I'm wrong? I'm starting my ghci session from zsh shell, provided by cygwin, wrapped in a tty emulator: $Drive\puttycyg\putty.exe -cygterm $Drive\zsh\bin\zsh.exe -p -c 'PATH=/cygdrive/h/zsh/bin:$PATH HOME=/cygdrive/h/.homedir rlwrap $(which ghcii.sh) -package-conf $Drive/.homedir/ghc/i386-mingw32-6.8.3/package.conf -read-dot-ghci' So I did not expect Readline not to work, but maybe the ghc system only sees the result from `uname -r` above?? Bye, Daniel. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe