> I had to kill ghci-5.02 for the following expression and
> ghci-5.04 is not
> much better:
>
> ~/source/gtk2hs/gtk:$ ghci
>___ ___ _
> / _ \ /\ /\/ __(_)
> / /_\// /_/ / / | | GHC Interactive, version 5.02.2,
> for Haskell
> 98.
> / /_\\/ __ / /___| | http://www.
> on http://haskell.org/ghc/docs/latest/set/book-hslibs.html
>
> The requested URL /ghc/docs/latest/set/book-hslibs.html was
> not found on
> this server.
Where did you find this link? I grepped through the HTML for the whole
of the GHC site and can't find it anywhere.
Cheers,
Simon
_
> our C-compiler complains with a syntax error about "DLL_IMPORT"
> delarations in file lib/ghc-5.04/include/RtsAPI.h, lines 125 and 126.
>
> Deleting "DLL_IMPORT" enables creation of a running interface between
> Haskell and C, but I'm not sure whether it is OK to do so.
>
> We are using gcc
> ghc-pkg has become a lot pickier about directories and files
> which are not
> there (which is probably the Right Thing, except that it
> becomes annoying when using things like "pkg-config gtk+-2.0 --cflags
> --libs").
>
> However, if I add a package that depends on, say, data to a
> loc
> db2html -d
> /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/docs/fptools
> -both.dsl hslibs.sgml
> output is hslibs
> Using catalogs: /etc/sgml/catalog
> Using stylesheet:
> /opt/src/build/debian/ghc5/ghc5-5.04/build-stage1/docs/fptools
> -both.dsl
> Working on:
> /opt/src/build/debian/g
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/posix
> /doc/posix.sgml?rev=1.14&content-type=text/x-cvsweb-markup
>
> it has
>
> See for details on how to
> communicate between threads.
>
> but the HTML doesn't have a link here. Looking at
Fixed, thanks.
Simon
__
> The merge routine is not stable (in
> fptools/libraries/base/Data/List.hs).
> Fix: replace
>
> merge :: (a -> a -> Ordering) -> [a] -> [a] -> [a]
> merge cmp xs [] = xs
> merge cmp [] ys = ys
> merge cmp (x:xs) (y:ys)
> = case x `cmp` y of
> LT -> x : merge cmpxs (y:ys)
>
It's a real bug. A foreign-exported function is supposed to be
registered as a stable pointer by the initialisation function for a
module (ie. when you call startupHaskell()), but this isn't happening in
5.04. The result is that eventually the garbage collector collects the
foreign-exported func
> I then upgraded my version to
> 5.02.3 and now ObjectIO doesn't work anywhere anymore. The linker
> complains in literally thousands of errors like the ones shown below.
> This is a shame because we did like the ObjectIO library. Ah, my
> colleague has just installed 5.02.1 and now it works on h
> I had thought of having the signal handler reap as many
> terminated child
> processes as possible, but had been concerned about a possible race
> condition. After you suggested that approach, I thought some more and
> decided that no race problem should exist. So I've
> implemented multipl
> The fine points of Unix signal semantics have always been somewhat
> mysterious to me. However, after digging around in man pages
> for a while,
> I have a theory as to what's going "wrong"...
Yes, your diagnosis looks very plausible.
The right way, I believe, to handle this in your signal h
> After much study I have a new theory. It appears that the
> pipe machinery
> is working fine, but that sometimes my program fails to
> "reap" all of its
> terminated child processes. I'm using a `sigCHLD` signal handler that
> does `getAnyProcessStatus True False` each time it's invoked.
>
> I have some GHC-compiled programs that run OK under Sparc/Solaris but
> hang under x86/Linux. I'm using GHC 5.02.3 on both systems (although
> I've tried GHC 5.03.20020410 on Linux with the same failures). I'm
> debugging to narrow the problem down. My current suspicion is that
> closing the
> Exploring the idea that the problem might be some bugs in GreenCard
> which have been fixed recently, I tried compiling an up to date
> version of the Win32 library - which brings me to my reports of
> apparent non-conformance of GHC to the ffi (release candidate 4) spec.
Yes, GHC 5.02 predates
> ghci does not find GHC.Prim, but ghc does:
>
> ::
> A.lhs
> ::
> > module A
> > where
> > import GHC.Prim
>
> > a# i# j# = i# +# j#
>
> ralf/tmp> ghc -c -fglasgow-exts A.lhs
> ralf/tmp> ghci -fglasgow-exts A.lhs
>___ ___ _
> / _ \ /
> Send us improved testsuites and we'll happily add them to our suites.
>
> The most relevant Hugs testsuites are:
>
> intTest.{hs,input,output}
This one appears to have a common ancestry with arith011 in
fptools/testsuite/tests/ghc-regress/numeric/should_run. However
arith011 has grown a bi
> > I'm shocked that non of the three Haskell implementations had a test
> > suite that caught this problem.
>
> Take a look at
> fptools/testsuite/tests/ghc-regress/numeric/should_run/arith0011.hs.
> There may be one or two wrong answers lurking in there, but
> that's a lot
> of results to che
> GHC (5.03.20020410) wrongly accepts the following:
>
> ::
> C.lhs
> ::
> > module C
> > where
>
> > class A a where
> > a :: a -> Int
> ::
> X.lhs
> ::
> > module X
> > where
> > import qualified C
>
> > instance C.A Int where
> > C.a = id
> After a looking a little more, there seem to be other problems
> (including errors in my proposed solution). I don't know where the
> code for quotRem is, but it is also buggy. For instance,
>
> Prelude> 9 `quotRem` (-5)
> (-1,4)
>
> (The correct answer is (-1,-4).) I'm frankly astonished:
And try tweaking the GC options to keep the residency down (preferably
within the limits of real memory on your machine). Use '+RTS -c' to
enable the compacting collector, and possibly use a -M switch to set the
maximum heap size to the amount of real memory - unless you need more
than that, of c
> This doesn't seem right:
>
>echo -n "no-newline" > /tmp/no-newline
>
> so /tmp/no-newline has no newline before the end of file.
>
>let f h = do p <- hIsEOF h
> if p then putStrLn "done"
>else do l <- hGetLine h
> f h
>
> and then
>
> I have a program that hangs. When I interrupt it (^C) it elicits the
> following error message.
>
> CCTest: fatal error: resurrectThreads: thread blocked in a strange way
> CCTest: no threads to run: infinite loop or deadlock?
I believe this bug was fixed between 5.02.2 and 5.02.3. Could yo
> The documentation http://www.haskell.org/ghc/docs/latest/set/finitemap.html >
> doesn't say whether fmToList et al are /defined/ to return a
> list in Ord order of the keys.
>
> I think it should.
Agreed. The docs for this library are now in Haddock format in the
source itself: see fptools
> Hi,
> I'm trying to compile the latest version of GHC (snarfed from
> CVS today),
> and I got the following errors:
>
>
> ../../ghc/compiler/ghc-inplace -ldl -fglasgow-exts -cpp
> -Iinclude -funbox-strict-fields -package-name base -O
> -Rghc-timing -spli\t-objs-c GHC/IOBase.lhs -o GHC/
> >>>
> 7.2. Binary Dependencies - `Depends', `Recommends', `Suggests',
> `Enhances', `Pre-Depends'
> --
> --
> [...]
> The meaning of the five dependency fields is as follows:
>
> `Depends'
> [...]
>
> I have tried installing the binary package of
> GHC 5.02.3 for solaris.
> we do have libcurses.so.1 installed but in some other directory than
> /usr/lib. The ghc complaint that the libcurses cannot be found.
You probably need to set LD_LIBRARY_PATH to point to the location of
libncurses.so (yo
> > maybe you need to rebuild the compiler you are compiling *with*?
>
> That's exactly what I'm trying to do with the latest CVS
> Head, so I assume
> you mean to try switching back to the Glasgow team's 5.02 or
> 5.03 releases
> to build. As the compiler I am using was built with the GHC te
> Simon Marlow wrote:
> >
> > > George Russell wrote:
> > > [snip]
> > > > Personally I suspect multi-parameter type-classes
> > > [snip]
> > > I've changed my mind and now think it's because GHC was upset
> > > it c
> compiling the example "ModuleTest.hs" from the
> Gtk+HS distribution produces the following
> error message:
>
> 84> ghc `gtkhs-config --cflags --libs` ModuleTest.hs
> ghc-5.02.3: panic! (the `impossible' happened, GHC version 5.02.3):
> AbsCStixGen.gencode typedef void ( *_ccall_fun_t
> in our (latest) installation (ghc-5.02.3 on solaris) the module Pretty
> (from the package text) did not export Style-related
> functions due to an
> (old/wrong) interface file ../imports/text/Pretty.hi (with
> size 10909).
>
> When translating Pretty.lhs ourselves it seems to work correctly
> I think this is a bug in ghc 5.03 (whatever is in the CVS).
> Please excuse me if I'm wrong.
>
> file:ghc/rts/Stable.c
>
> symptom: seg faults sometimes (tricky to reproduce, but occurs when
> you have more than one live stable pointer to the same value,
> and a bunch of
> | Is rejecting Haskell 98 modules when -fglasgow-exts is on
> | also a bug? (i.e. does GHC Haskell aim to be a conservative
> | extension of H98?)
>
> Yes, we do so aim, but this seems to be an occasion where
> there's no obvious way to make the extension 100% conservative
> without making t
> Wolfgang Thaller wrote:
>
> > [...] Can anyone with sparc experience think of a reason
> why cache flushing
>
> > should _not_ be necessary here?
>
>
> Synchronizing the data/instruction caches *and* the caches of
> different
> processors (most people forget the latter) is necessary for
>
> > Sounds bad. I'm getting it under ghc-5.03.20020208 on WinXP.
> > My program uses stable names but is otherwise fairly tame.
> > Any pointers on what this message means and what causes
> it? - Conal
>
> It indicates a bug, possibly related to garbage collection. Could you
> send us
> I'm using memoized copying functions to maximize sharing in a
> tree/dag. It works under Hugs but not GHCi 5.03 on Windows
> XP. I'm stuck here and so would sure appreciate some help.
> I've attached a simple demo module with examples that
> illustrate the problem.
There are some differe
> Sounds bad. I'm getting it under ghc-5.03.20020208 on WinXP.
> My program uses stable names but is otherwise fairly tame.
> Any pointers on what this message means and what causes it? - Conal
It indicates a bug, possibly related to garbage collection. Could you
send us the code?
Che
> ghci doesn't seem to be picking up the .ghci settings in the
> current directory, though it does in my $HOME directory. I'm
> using 5.03 under Windows XP. Is this known behavior?
Looking at the code, there appears to be a bug in the Windows
implementation of .ghci file loading that would c
Conal,
Could you remind us what you're using unsafePtrEq for? Perhaps there's
another way to do what you want, or we could maybe reinstate
unsafePtrEq.
Cheers,
Simon
> -Original Message-
> From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]]
> Sent: 17 April 2002 04:09
> To: Conal
> I should have followed your suggestion to to rebuild gcc for
> Solaris 2.7
> right away. After rebuilding gcc, the source build and
> install of 5.02.2 had no problems.
It looks from your earlier message as if Perl was dumping core when
running the script ghc-split.prl. The rebuilt gcc mig
> The INSTALL file of the GHC 5.02.2 Linux Binary Dist contains a note
> that the compiler has been linked against Readline 3 and that this
> might cause problems on newer Linux distributions, which use
> Readline 4.
>
> Let me first remark that the same problem occurs with NCurses: GHC ist
> li
> the following instance declaration doesn't work any
> more with ghc-5.02.3, it worked before.
>
> > newtype ST state a = ST { unST :: state -> (a,state) }
> >
> > instance Monad (ST c) where
> > return x = ST (\state -> (x,state))
> > (m >>= f) = ST (\state -> let (x,state1) = unST m stat
> > I've just finished building 5.02.3 on sparc-solaris, and
> didn't get any
> > core dumps, so there must be something different about your
> setup. What
> > version of
> > gcc are you using? What version of GHC are you bootstrapping with?
>
> $ gcc -v
> Reading specs from .../gcc-lib/sparc
> [Everything on Linux-x86]
>
> Maybe you're heading in the wrong direction:
>
> stolz@kastor:~/test/resources > $HC5 --make -fglasgow-exts *.hs
> ghc-5.03: chasing modules from: Colour.hs,GUIValue.hs
> Compiling GUIValue ( GUIValue.hs, ./GUIValue.o )
> Compiling Colour ( Colo
> George Russell wrote:
> [snip]
> > Personally I suspect multi-parameter type-classes
> [snip]
> I've changed my mind and now think it's because GHC was upset
> it couldn't find the
> .hi file for GUIValue.hs in a directory on the import list.
> (Of course it shouldn't
> be, it should know whe
> Simon Marlow wrote:
>
> > > If I do the following ...
> >
> > I think these bugs (the illegal -x option to ld, and the messed up
> > installation directories) were fixed in 5.02.2. Could you
> try building
> > that version instead?
> >
> &g
> If I do the following ...
I think these bugs (the illegal -x option to ld, and the messed up
installation directories) were fixed in 5.02.2. Could you try building
that version instead?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EM
> I think it is probably due to the ancient version 2.7.2 of gcc we
> have by default on Solaris 2.6 here. The sigset_t type is guarded
> by #ifdefs as follows:
>
> #if defined(__EXTENSIONS__) || (__STDC__ - 0 == 0) || \
> defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) || \
>
> The binary package of ghc-5.02.2 for sparc-sun-solaris2.7
> seems to have
> a small problem on my Solaris 2.6 machine. The compiler works fine
> on most source modules, but it has trouble with one using the FFI.
> A previous version of the compiler (4.08.2) worked fine on the same
> module, a
> > I don't think mmap() provides exactly the right behaviour.
> It lets you
> > specify that modifications made by the current process
> aren't committed
> > to the file, but what we want is to snapshot the file so
> that subsequent
> > modifications by *other* processes aren't seen by the lo
> * When we fork(), we lose sharing. *Any* lazy computation which
> passes to both children is going to penalize you, sometimes in very
> surprising ways.
I'm not sure I understand why loss of sharing is the problem - losing
sharing for pure computations is by no means a disaster, it just me
> On Mon, 2002-03-18 at 18:30, Simon Marlow wrote:
> > The spec could perhaps *require* that it was a pure value,
> so that the
> > file contents is snapshotted at the time of the hGetContents and you
> > always get the same result regardless of subsequent or
> co
> On Mon, 2002-03-18 at 13:51, Simon Marlow wrote:
> > Ok, here's my explanation. [...]
>
> I see...
>
> Yet, it doesn't explain why the problem disappears if you close stdin
> before calling executeFile, like this:
>
> callIO :: (ProcessStatus -&g
> > Yes, it's a NOP (just to be sure). The difference is in child.hs:
> >
> > callIO (\ps -> "Kommando fehlgeschlagen mit " ++ show ps
> > ++ ":\n" ++ kommando prog par)
> >(executeFile' prog True par Nothing)
> > -- instead, to avoid bug:
> > -- (hClose stdin >> exec
> On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
> > Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
> > > - If instead the child's child (echo.c) closes stdin
> immediately after
> > > being executed, some data is lost.
> >
> > Where's the use in closing stdin when you're passing arguments
> > We're groping around in the dark here
>
> Sorry, yes we are. It is a bit cheeky of me to always punt and say
> "I'll bet it is a GHC problem" when I haven't even seen the bug myself
> on a machine whose configuration I know. Sorry about that.
No problem :)
> In fact, it turns out that y
> In local.glasgow-haskell-bugs, you wrote:
> > I've stripped down my program to produce an example. In the
> process, the
> > problem disappeard a few times. I hope it shows up on your
> machine. The
> > attached files reproduce it on my machine, but the exact
> results vary
> > from run to r
> Briefly, GreenCard has always marshalled Word8 as a Word32 (and so has
> Hugs). I'm wondering if a recent change in GHC or in how Win32 is
> compiled might have changed the way that Word32 is being marshalled.
>
> Possibilities:
>
> Maybe GHC has started marshalling word32 differently?
>
[ redirected to [EMAIL PROTECTED] ]
> Good day everyone, I was fiddling around with this tiny echo
> client/server haskell program from 'The Great Language Shootout'
> site (http://www.bagley.org/~doug/shootout/) and got stuck.
>
> The code (attached) has been reformatted with minimal API tweak
> There seems to be a bug in the IO libraries. I'm using the following
> procedure to call an external program and send it data through a pipe.
Could you send us a complete example that we can run to reproduce the
problem?
Cheers,
Simon
___
Gl
> When I compile a HEAD version from this morning with GHC
> 5.02.2, there is
> a "deprecated" warning for the use of 'tryAllIO' by
> compiler/rename/RnHiFiles.lhs.
>
> But when I compile it with a HEAD version, it gives an error
> and says that
> Exception doesn't export 'tryAllIO' any more.
> It seems to me that the -i command line argument is ignored when used
> together with --make. GHC reports that the modules can't be found.
> Is there any way to use a library (lib*.a + *.hi files) that
> is not compiled
> as a package with ghc --make?
Not at the moment, no. If you have a lib
> Ah no, I've changed my mind. This is problematic. You
> probably weren't hitting the right bit of code in your tests
> to show up the problem.
>
> In -monly-3-regs, the mangler must insert code to re-load
> the contents of %edi before doing a jump, and if the jump
> involves %edi itself
> I'm running in to a problem using ghc -M to generate
> dependencies when
> there are embedded spaces in the path name to a dependency.
>
> If I run ghc -M using something like:
>
> $ ghc -M -optdep-f -optdep.hs_dependences
>-i"C:/Program Files/GreenCard"/lib/ghc JNI.hs
>
> it correc
> I had a "Pretty.hs" from the CTK, a version that comes with
> hugs and the ghc
> text package one. I was including the CTK directory and that
> version was being
> used in preference to the text package one.
>
> This I presume is the intended behaviour.
>
> The other thing that bit me was
> I commented out this block at line 1312:
>
> #if ($StolenX86Regs <= 3 ) { # spurious uses of edi?
> # s/^\tmovl\s+(.*),\s*\%edi\n\tjmp\s+\*%edi\n/\tmovl
> $1,\%eax\n\tjmp
> \*\%e
> ax\n/g;
> # s/^\tjmp\s+\*(-?\d*\(.*\%edi.*\))\n/\tmovl $1,\%eax\n\tjmp
> \*\%eax\n/g;
> # s
> | srRN_ret:
> | movl%esi, %eax
> | andl8(%ebp), %eax
> | cmpl4(%ebp), %eax
> | setne %al # al = eax==4(ebp) ? 1 :
> 0
> | movzbl %al, %edi # edi is 0 or 1
> | addl$12, %ebp
> | mo
> Not sure whether this is a documentation bug or not, but I
> got tripped over by the syntax of the -pgm options this
> week.
>
> In the user-guide
> http://haskell.org/ghc/docs/latest/set/flag-reference.html#AEN5804
> there clearly seem to be spaces between -pgmX and cmd,
> however looking at t
> There is a difference between hugs and ghc in how they treat
> imports with the
> '(..)' notation. Here's my example:
>
> module CTree(
> --other stuff
> Const(..)
>) where
>
> import ATree (Const)
>
> --const has constructors CInt, CChar, CStr
>
> under hugs this module ex
> What does it mean when you get the fatal error "PAP_Entry:
> CATCH_FRAME". I
> am using ghc version 5.03.20020204. I looked in the ghc
> source code and the
> comment next to this error message says that it cannot happen.
Well, you must be imagining it then :-)
Seriously, I've seen this erro
> used to read "-H14m ... (might make the faster, especially on
> large...)"
> fixed to "-H14m ... (might make the compilation faster,
> especially...)"
Fixed; thanks.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.o
I'll just add that we added a test to the configure script to check whether the local
ld supports -x after the 5.02 tree was branched, and it looks like it got overlooked
in the merge, sorry about that.
To work around the problem, you can either just remove the -x's from invocations of ld
in f
> I have a program which comes to the end of the main action,
> but nevertheless won't go away. Is this
> a bug? When I give up and interrupt it, I get a message
> "fatal error: resurrectThreads: thread blocked in a strange
> way"; could this be connected?
The behaviour hasn't changed: when
> On a slightly related topic: I was a bit surprised to notice that
> 5.02.2 appears to produce binaries that are incompatible with 5.02.1,
> given that it was only a minor version number change. It's
> not a huge
> deal (since this at least produced link errors), but it was a bit
> surpri
> Funny, I've been meaning to write in on this.
>
> I hit this problem hard too. I was linking the GHC compiler to a C
> library. I compiled the whole compiler with -prof, but whenever it
> called into the C library it would core dump. For a long time
> (years!) I assumed it was something stra
> Certainly.
>
> We've just spent lots of time trying to get this stuff to be utterly
> painless to compile, so please let us know if the instructions below
> give you any trouble.
The problem is that you didn't compile the whole program with -prof: the
BareBonesArrows library was compiled th
> I tried this under Linux (debian, using ghc 5.02.2). It compiled OK,
> but produced an executable that dumped core immediately on
> startup. :-(
>
> For what it's worth, here is as much info. as I could glean from gdb:
>
> Starting program: /home/frp/afrp/src/testST
>
> Program received si
> I realize that my use of the API was incredibly naïve and
> that I should
> have been using h* methods with the handle returned from
> connectTo. But
> it is connectTo that is failing as described.
>
> It fails interactively too with ghci, and regardless of using Server
> "http" or PortNumber
> Henrik Nilsson and I have both (independently) noticed two
> critical bugs
> in dependency generation in ghc 5.02.1. If memory serves me
> correctly,
> this actually worked OK in ghc 5.02; I believe the bugs were only
> introduced in 5.02.1. The bugs appear to be platform independent; we
> According to the GHC libraries manual, 6.2.1: "The Handle
> returned by connectTo and
> accept is unbuffered by default." However, with such a
> handle and hPutStrLn,
> I am getting buffering, even when use IO.hSetBuffering to
> NoBuffering. When I
> put in an explicit hFlush after the
> This is a bug which has been in GHCi from the beginning.
This is actually the defined behaviour (see Section 3.3 of the User's
Guide: a newly compiled object will only be noticed on a :load, not
:reload). But your message made us wonder whether the restriction can
be relaxed slightly, and in
> This program crashes on ghc 5.02, on my RH7.1
>
> module Main where
>
> import MVar
>
> main =
> do { mVar <- newMVar True
> ; tryTakeMVar mVar
> ; return ()
> }
Darn. tryTakeMVar is busted in 5.02 I'm afraid. I've just fixed it in
the HEAD, maybe 5.02.3 will have it fixed i
> --with-hc only configures what's used to compile 'generic' Haskell
> code (i.e., not the contens of ghc/compiler). (As Simon suggests),
> use --with-ghc to control what GHC to to use to compile the
> compiler bits, i.e.,
>
> ./configure --with-ghc=/usr/local/bin/ghc-5.02.2 \
>
> Dear ghc-5.02.2 (linux-i386-unknown, binary snapshot for libc-2.1),
>
> For the program main = putStr $ show $ (2+3 :: Int)
>
> ghc --make Main
> `makes' it all right.
> And ghci -package docon Main
> also works.
> docon is my user package
> On Thu, Jan 03, 2002 at 05:27:43PM -0000, Simon Marlow wrote:
> >
> > '(' exp(i+1) op(a,i) ')'
> > '(' op(a,i) exp(i+1) ')'
> >
> > '(' lexp(i) op(l,i) ')'
> > '(' op
> This program:
>
> module Main where
> f = map (++"a"++"b")
> g = map ("a"++"b"++)
> main = do print (f ["x","y","z"])
> print (g ["x","y","z"])
>
> gives the following error messages with ghc (versions 4.08.2
> and 5.02):
>
> plusplus.hs:3:
> The op
> HsParser miscalculates column-positions if qualified names are used.
> The problem seems to be the lexer forgetting to count the '.' in the
> qualified name when deciding how much to move forward. In this
> function, for instance,
>
> f M.A M.B M.C = 0
>^
>
> HsParser repo
> With the module
>
> data Foo = Foo {}
>
> ghc tells me
>
> tt.lhs:2: parse error on input `}'
>
> while the report allows this.
Fixed; thanks.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/
> Hi GHC people,
>
> I think there is a bug in hslibs/hssource/HsLexer.lhs
>
> For the following code:
>
> foo = 1 Prelude.: []
>
> The lexer mistakes the qualified constructor "Prelude.:" as a
> variable.
>
> The problem is due to the use of the variable 'c' instead of the
> variable 'c
> Given a file "test" of size 2342.
>
> The program "Bug.hs" behaves correctly (the result is
> "(2048,384)"), but when uncommenting the seemingly innocent
> line, the program behaves incorrectly (result is
> "(2048,2048)"), and the buffer is filled with garbage.
>
> main =
> do han <- openFi
> Mon, 3 Dec 2001 12:54:01 -0000, Simon Marlow
> <[EMAIL PROTECTED]> pisze:
>
> > That will likely hurt performance quite a bit (I don't have figures,
> > but I guess 10-20%).
>
> I've heard that guessing about performance means nothing compared t
> My machine is running OpenBSD. Since there seems to be no
> binary distribution
> for this environment, I tried the source distribution (file
> ghc-5.02.1-src-1.tar.bz2).
>
> I proceeded according to the instructions in Sec. 7 of the
> installation guide.
Unfortunately we have some problem
> Thu, 22 Nov 2001 10:09:17 -0000, Simon Marlow
> <[EMAIL PROTECTED]> pisze:
>
> > This is an error from the C compiler telling you it ran out
> of registers
> > while compiling the intermediate C. Try adding the -monly-3-regs
> > option, and failing tha
> I have a very basic (and naive, probably) question:
>
> What does one use to unpack a *.bz2 file?
>
> I tried to find this information in the on-line installation
> guide, but
> could not find it. Might be a good idea to put it there.
>
> A quick response would be much appreciated.
bzi
> While trying to compile qforeign cvs with ghc-5.02.1, I get
> the following error.
>
>
> /usr/bin/ghc -c -O -Wall -fglasgow-exts -package lang
> -package data -package concurrent -package posix -iexamples
> -ilib -Iexamples -Ilib examples/Libgr_hsc.c
> programs/hsc2hs-inplace --cc=/usr/b
> If `installHandler' is called more than a few times in a row, the
> run-time system terminates with an error message.
>
> The program:
>
> main =
> sequence_ $
> replicate 33 $
> installHandler sigINT (Catch (return ())) Nothing
>
> The shell output:
>
> Am 14. Nov 2001 um 12:46 MET schrieb Simon Marlow:
> > Thanks, but I think I've fixed this now. If you have a
> local GHC build,
> > could you try out the patch included and let me know if it
> fixed things?
>
> Looks like it works. Does your previous comme
> [If you are interested in reproducing the exact setup, please
> contact me]
> I did some hello-debugging in PrelHandle
> and found out the following:
Thanks, but I think I've fixed this now. If you have a local GHC build,
could you try out the patch included and let me know if it fixed things
> A small program (which I haven't been able to strip down to a
> minimal *failing* version ;) repeatedly opens sockets and does the
> following (I tested with all permutations of hSetBuffering):
>
> Socket.connectTo ...
> hPutStrLn h "Data"
> hPutStr h d
> debug Io "Reading..:"
> c <-
> HsParser does not allow method declarations to follow a default
> implementation of a method.
>
> class G a where
> f :: a -> a
> f x = x
> g :: a -> a
>
> Optional semicolons or empty statements are not permitted in
> do-expressions.
>
> f x = do ;; x ;
>
> T
> Using ghc-5.03, getArgs only returns the first command line argument.
>
> main = do putStrLn version
>args <- getArgs
>putStrLn (show args)
>...
I can't repeat this bug - it works for me with last night's sources both
in batch mode and in GHCi.
Cheers,
601 - 700 of 1401 matches
Mail list logo
