Re: [Haskell-cafe] Can't build Gtk2hs on Windows

[Daniel Kahlenberg]

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 tre...@vex.net:
 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] Can't build Gtk2hs on Windows

[Daniel Kahlenberg]

Ryan,

thanks for adopting party.

Daniel

2011/5/5 Ryan Yates fryguy...@gmail.com:
 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
 d.kahlenb...@googlemail.com 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 tre...@vex.net:
 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] How to update the RNG per call (State monad) when generating QuickCheck arbitraries?

[Daniel Kahlenberg]

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 d.kahlenb...@googlemail.com:
 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 b...@serpentine.com:
 On Tue, Apr 26, 2011 at 3:04 AM, Daniel Kahlenberg
 d.kahlenb...@googlemail.com 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?

[Daniel Kahlenberg]

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

[Haskell-cafe] already installed packages alerted as not being installed

[Daniel Kahlenberg]

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] already installed packages alerted as not being installed

[Daniel Kahlenberg]

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 k...@iij.ad.jp:
 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 package -n to see what will happen before
 typing cab install package. 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 package -r
 cab revdeps package -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

Re: [Haskell-cafe] already installed packages alerted as not being installed

[Daniel Kahlenberg]

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 k...@iij.ad.jp:
 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] Glade problem solved Was: Compile Glade apps (MS Windows system) Was: Re: Trying to compile Glade Gtk2Hs demo / cabal install glade problem

[Daniel Kahlenberg]

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

[Daniel Kahlenberg]

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

[Daniel Kahlenberg]

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)

[Daniel Kahlenberg]

Hi list,

stumbled across that:
http://www.google.com/insights/search/?hl=de#q=haskellgeo=DEcmpt=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

[Daniel Kahlenberg]

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

[Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)

[Daniel Kahlenberg]

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\bin
Libraries installed in:

Re: [Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)

[Daniel Kahlenberg]

On 18.06.2010 17:07, JP Moresmau wrote:
 
 
 On Fri, Jun 18, 2010 at 4:48 PM, Daniel Kahlenberg
 d.kahlenb...@googlemail.com 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

Re: [Haskell-cafe] Has anybody tried to upgrade Cabal on HP (Win 7)

[Daniel Kahlenberg]

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] Re: Cabal update problem

[Daniel Kahlenberg]

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
maciej.podgur...@googlemail.com

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

[Daniel Kahlenberg]

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
---BeginMessage---
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 

[Haskell-cafe] caba install with external gcc toolchain not the ghc-bundled one

[Daniel Kahlenberg]

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 build-type Simple
Creating h:\.homedir\hugsdata\setup (and its parents)
Using Cabal 

[Haskell-cafe] cabal with non-default cc1

[Daniel Kahlenberg]

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/mingw -IH:\.homedir\hugsdata\setup -c 

[Haskell-cafe] [Haskell Beginner] Compiling wxhaskell fails for me

[Daniel Kahlenberg]

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] System.Console.Readline stifleHistory Question

[Daniel Kahlenberg]

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.

interactive: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] Re: System.Console.Readline stifleHistory Question

[Daniel Kahlenberg]

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.

interactive: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