Hi everyone,
When evaluating an IO monad in GHCi from the 6.6.1 distribution, the
REPL tries to be a bit too smart about printing out the returned
value. For example, () values are not printed:
Prelude System.Directory setCurrentDirectory work
Prelude System.Directory
...but String,
Hi,
I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6,
because I've also installed stuff depending on 6.4.2, like wxHaskell,
for instance. Now I see a new version of mtl, which I also have
installed, depends on 6.6.1, while all of the rest of the stuff is
lagging behind with
On 6/20/07, Isaac Dupree [EMAIL PROTECTED] wrote:
yes, binutils written in Haskell! Will never happen! :))
It's crossed my mind as well, once or twice -- maybe it's not such a bad idea.
Cheers,
Dinko
___
Glasgow-haskell-users mailing list
On 4/16/07, Isaac Dupree [EMAIL PROTECTED] wrote:
The code generated by Alex is perfectly good Haskell98+cpp, except:
#if __GLASGOW_HASKELL__ = 603
#include ghcconfig.h
#else
#include config.h
#endif
If that else is modified to only trigger if we're using GHC at all[1],
then plain C
FWIW, I used to employ a combination of environment vars and registry
entries (for file associations) on Windows in order to be able to work with
multiple GHC versions. The environment vars (e.g. for PATH or LIB
inclusion) would all depend on a GHC_HOME var, which could be redefined to
point to
On 2/18/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello glasgow-haskell-users,
i'm tried to download newer snapshot of 6.6 and found that now it's
74 mb! why it is so large and why it's so enlarged after 6.6 release?
isn't it possible to reduce size of this package?
Does this include
On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
GHC doesn't normally do CSE. CSE can cause space leaks, so you can't
do it willy-nilly.
I'm sure there are some strict contexts where it could be done
safely, but I don't think ghc uses that information (yet).
-- Lennart
My
On 11/28/06, Bertram Felgenhauer [EMAIL PROTECTED] wrote:
Dinko Tenev wrote:
On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
GHC doesn't normally do CSE. CSE can cause space leaks, so you can't
do it willy-nilly.
I'm sure there are some strict contexts where it could be done
Something to do with Parsec, maybe?
For what it's worth, the darcs repo version of genprimopcodes compiled
with GHC 6.4 does parse the attached vore-primops.txt.
On 3/1/06, Ian Lynagh [EMAIL PROTECTED] wrote:
[ ... ]
../utils/genprimopcode/genprimopcode --data-decl
Yes, last night's build worked for me, thanks.On 11/21/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
I believe I have fixed this.(It was my fault, late last week.)I'm compiling now to test.Meanwhile it'd be worth your having another
go.Simon
___
I updated from HEAD recently, and got some strange error messages
while building the stuff under libraries/X11:
../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches
-fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include
-ignore-package X11 -O -dcore-lint -W
It looks odd to me, because the service is not particularly meaningful to the transport, and thus not a crucial piece of
information. Unless I am missing something, this could be a
bug in the Network module.
You may want to try the lower-level stuff from Network.Socket instead.
Cheers,
Dinko
On
On 7/18/05, Simon Marlow [EMAIL PROTECTED] wrote:
The GHC command-line isn't declarative, it's imperative. Options are
processed left-to-right.
I don't have any doubts about whether GHC can make sense of
conflicting options or not, be it the one way or the other. What's
causing the trouble is
On 7/15/05, Simon Marlow [EMAIL PROTECTED] wrote:
As a workaround you can disable object splitting. Add the line
SplitObjs=NO to mk/build.mk before building.
I did that, and it got me a bit further. Now ghc-inplace dumps core
compiling Language/Haskell/Syntax.hs:
BTW, I tried to compile the file with the installed ghc, and I am kind
of puzzled by the error message I get:
ghc -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports
-ignore-package haskell-src -package base -fgenerics -hisuf p_hi
-hcsuf p_hc -osuf p_o -prof -c
I did a devel build this time, which produced some verbose output
for the last line.
One thing that troubles me is that gcc still manages to kick-in - what
exactly is going on???
==fptools== make all -wr;
in
It turns out, ar couldn't quite handle building the symbol table for
the archive. I tried ar qS, then ranlib the archive, but ranlib turns
out to be exactly the same kind of brittle crap...
I am currently looking for more robust binutils - I'll appreciate any
siggestions.
Cheers,
D. Tenev
Hi,
I am trying to build from the current GHC source tree on a Debian
sarge box, and the build dies trying to compile
/home/shinobi/build/fptools/ghc/parser/Parser.hs, with the following
output:
/usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes
-istage1/types -istage1/hsSyn
On 5/31/05, Daniel Fischer [EMAIL PROTECTED] wrote:
Why is ghc unable the determine the type of the Literal 0 in the
definition of g?
Answer: Since somewhere an instance e.g. New [(a,Double)] (Map a Int)
could be defined, leading to problems when threating 0 as (0::Int).
There could
On 5/31/05, Seth Kurtzberg [EMAIL PROTECTED] wrote:
Because I'm not smart enough to understand it?
;-)
OK, sorry about the notation (I just didn't feel like doing so much
typing, you know :)
Here goes...
First we observe that, g = new . flip zip [0..], so, without the type
specification, it
On 5/31/05, robert dockins [EMAIL PROTECTED] wrote:
Dinko Tenev wrote:
First we observe that, g = new . flip zip [0..], so, without the type
specification, it has the general type (New [(a, b1)] b, Num b1, Enum
b1) = [a] - b, as reported by GHC.
Then we infer from
(1) g
*Main :type fromList
fromList :: (Ord k) = [(k, a)] - Map k a
*Main :type new
new :: (New a b) = a - b
The type of new probably accounts for the difference (even though it
still makes me wonder what the big deal is :)
Using functional dependencies seems to fix it, i.e.:
class New a b | a - b
22 matches
Mail list logo
