> > insert :: Char -> Set t Char -> Set t Char
> > insert c (Set tinfo cs) = case c of
> > 'A' -> Set (InsA tinfo) (c:cs)
> > _ -> error "not a label"
>
> gives me the error:
> >Occurs check: cannot construct the infinite type: t = A t
assuming that ghc 6.8.2 is not too far away, is there
any chance of cabal becoming a bit friendlier wrt old
.cabal and Setup files, before that release?
you've heard me say before that i'd have preferred
a backwards compatibility module, but if that isn't
possible, couldn't cabal at least detect t
Sorry if I'm talking to myself, but I found a solution and thought it could
be interesting for other people who need to call GHC created DLLs from
Excel.
The solution is based on the information found in :
http://haskell.org/haskellwiki/GHC/Using_the_FFI#Debugging_Haskell_DLLs.
As suggested, I ad
Am Freitag, 30. November 2007 15:23 schrieb Daniel Fischer:
> Question 2: When I build a package via Cabal, is there a way to merge the
> documentation into the installed library docs (and if yes, how do I do it)?
I think, if you do
runhaskell Setup.[l]hs haddock
before
runhaskell Setup
On Fri, 2007-11-30 at 13:37 +1100, Manuel M T Chakravarty wrote:
[...]
>
> In other words, first you need to decide what properties you want to
> enforce and what information you need to decide those properties.
> Coming back to your set example, what properties do you want to
> enforce/che
Yesterday, doing runghc ./Setup.hs haddock in zlib.0.4.0.1, I noticed that no
Haddock docs have been built for my 6.8.1.
I followed the usual building steps, which worked with previous GHCs, set
XMLDocWays=html, then
./configure
make
make install
make install-docs
No library docs (users guide an
Just a short addition to my previous e-mail:
I just found an old thread which looks very similar to the problem I just
described:
http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs:-Bug-in-shutdownHaskell--t1206938.html
I also tried to prevent the RTS from installing signal handers (it was
mentionned
Lemmih wrote:
On Nov 30, 2007 12:36 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
Alex Jacobson wrote:
$ darcs get http://happs.org/HAppS-Begin
$ cd HAppS-Begin
$ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs
$ ghc --make SearchPath.hs -o sp
$ sp ghci -ihaskell haskell/Main.
Simon Marlow <[EMAIL PROTECTED]> schrieb:
>
> Perhaps you compiled mkDerivedConstants as a 32-bit executable?
Yes. I was not attentive enough.
But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is
interested, I shall prepare a package of the installed binaries.
The compiler i
On Nov 30, 2007 12:36 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
> Alex Jacobson wrote:
> >
> > $ darcs get http://happs.org/HAppS-Begin
> > $ cd HAppS-Begin
> > $ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs
> > $ ghc --make SearchPath.hs -o sp
> > $ sp ghci -ihaskell haske
Alex Jacobson wrote:
$ darcs get http://happs.org/HAppS-Begin
$ cd HAppS-Begin
$ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs
$ ghc --make SearchPath.hs -o sp
$ sp ghci -ihaskell haskell/Main.hs
Prelude> :r
I don't see any unnecessary reloading here:
Ok, modules loade
W.B. Kloke wrote:
In my effort to produce a working FreeBSD-amd64 compiler I made some
progress. Now I have a working stage1/ghc-inplace (which is a 32bit
executable producing 64bit code). But the compilation of rts fails in
file Apply.cmm with the following message:
== gmake all -r;
in /.amd_m
12 matches
Mail list logo
