GHC confused by hi-boot files
With both ghc6.2 and 6.2.20040915 on Linux, ghc --make cannot compile
the attached files and produces a confusing error message.
# ghc --make View.hs
Chasing modules from: View.hs
Compiling ViewType ( ./ViewType.hs, ./ViewType.o )
Compiling VersionGraphClient ( ./VersionGraphClient.hs, ./VersionGraphClient.o
)Compiling View ( View.hs, View.o )
View.hs:14:
Couldn't match `VersionGraphClient' against `VersionGraphClient'
Expected type: VersionGraphClient
Inferred type: VersionGraphClient
In the `graphClient1' field of a record
In the record construction: View {graphClient1 = graphClient}
However ghc without make has no problems.
# ghc -c ViewType.hs
# ghc -c VersionGraphClient.hs
# ghc -c View.hs
best wishes to all Simons!
module VersionGraphClient where
data VersionGraphClient
module VersionGraphClient(
VersionGraphClient,
) where
import ViewType
newtype VersionGraphClient = VersionGraphClient Int
-- | This module defines the fundamental structure of the (untyped)
-- objects in a repository.
--
-- We depend circularly on CodedValue.hs. This module is compiled
-- first and uses CodedValue.hi-boot.
module View(
) where
import ViewType
import VersionGraphClient
createView :: VersionGraphClient - IO View
createView graphClient =
do
return (View {
graphClient1 = graphClient
})
module ViewType(
View(..),
) where
import {-# SOURCE #-} VersionGraphClient
data View = View {
graphClient1 :: VersionGraphClient
}
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Template Haskell and boot files
Hello GHC bug fixers,
I just sent a program which ghc --make couldn't compile but
individual ghc -c commands could.
Now I have just tried to work around this, using Template Haskell
to use a data rather than newtype declaration for ghc6.2
Unfortunately the new code has the opposite problem! It breaks
ghc -c, but ghc --make works. This is also for both ghc6.2
and ghc6.2.20040915
with -c it doesn't work:
# ghc -c -fglasgow-exts ViewType.hs
# ghc -c -fglasgow-exts VersionGraphClient.hs
tcLookup: `VersionGraphClient.VersionGraphClient' is not in scope
In the data type declaration for `View'
with --make it does work:
# ghc --make -fglasgow-exts VersionGraphClient.hs
Chasing modules from: VersionGraphClient.hs
Compiling ViewType ( ./ViewType.hs, ./ViewType.o )
Compiling VersionGraphClient ( VersionGraphClient.hs, VersionGr
Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
module VersionGraphClient where
data VersionGraphClient
module ViewType(
View(..),
) where
import {-# SOURCE #-} VersionGraphClient
data View = View {
graphClient1 :: VersionGraphClient
}
module VersionGraphClient(
VersionGraphClient,
) where
import ViewType
data Foo = Foo View
$(if False
then
[d|
newtype VersionGraphClient = VersionGraphClient [Foo]
|]
else
[d|
data VersionGraphClient = VersionGraphClient [Foo]
|]
)___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-fwarn-unused-imports confused by hi-boot files
# ghc -fwarn-unused-imports C.hs
C.hs:1:
Warning: Module `A' is imported, but nothing from it is used
(except perhaps instances visible in `A')
However if I comment out the import of A I get
./B.hi-boot:3:
tcLookup: `A.A' is not in scope
In the type synonym declaration for `AS'
C.hs:1:
Failed to load interface for `A':
Bad interface file: ./A.hi
./A.hi: openBinaryFile: does not exist (No such file or directory)
C.hs:1:
Failed to find interface decl for `A.A'
from module `A'
C.hs:1:
Failed to find interface decl for `A.A'
from module `A'
module A where
data Amodule B where
type AS = [A.A]module C where
import {-# SOURCE #-} A
import {-# SOURCE #-} B
type ASS = [AS]___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text.ParserCombinators.Parsec requires -package text.
Axel Simon wrote (snipped): But if I have two layers over gtk 1.2 and 2.0 and both use the hierarchical module system and are therefore marked as auto you would have the same problem of linking in two versions of gtk which doesn't work. Did I miss something? I presume that Simon meant that only *some* of the libraries in the hierarchy should be marked as auto. I would be in favour of making this subset small, leaving out everything apart from the Prelude modules + those with qualified names beginning Control, Data, Foreign, System and Text. This would leave lots of namespace free for the user. However there's no reason why implementations should not implement extra modules and mark them as auto so long as they begin with one of these five names. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text.ParserCombinators.Parsec requires -package text.
Simon Peyton-Jones wrote: It's documented behaviour. * import Text.ParserCombinators.Parsec will work without any -package flags, if any installed package has a module Text.ParserCombinators.Parsec. It's very tiresome adding -package flags all the time. * The link step needs -package flags, because it only gets .o files, and we didn't want it to start hunting through .hi files (though that would be possible) * ghc Main.hs is by definition equivalent to ghc -c Main.hs; ghc Main.o, and the latter step needs the package flag. If you say ghc --make Main.hs you'll get what you want. Even though it is documented behaviour I think it is wrong. It looks as if we now have the rather complicated situation that import Text.ParserCombinators.Parsec will work during compilation without loading the package parsec *unless* one of the other modules being compile imports this module and uses Template Haskell. It will work during linking *if* you used --make, but otherwise you get some very user-unfriendly messages about undefined symbols. GHC's package system is good because it makes libraries available in a uniform way. The above complex rules just make things more complicated. People who have trouble typing --package parsec should learn to use Make. The solution someone else proposed of stashing extra information in the object file to help the linker just seems to me a recipe for more complexity, and in any case wouldn't work when packages only contain non-GHC object files. (Like some of mine.) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text.ParserCombinators.Parsec requires -package text.
Alastair Reid wrote (snipped): Why is it necessary to provide -package options at all? ghc-pkg knows about all the packages in your system so it could just implicitly add -package $x for every package when compiling or linking. My current need at least is to disable the lang, text, data packages and so on so I can see if my code compiles even when GHC nukes FiniteMap and only allows me to call it Data.FiniteMap. As I expect it will one of these days. One reason I think it might still be necessary to retain -package options is that otherwise code will stop working if a package is added to the package.conf file which has modules with the same name as those the user is working with. The trouble is that the analogy with the standard Prelude does not work; compiler writers are not supposed to add names to the standard prelude, but they definitely do need to be able to add packages to the package.conf files they distribute. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Text.ParserCombinators.Parsec requires -package text.
With ghc ParsecTest.hs -o pt you get a link-time failure, because it looks as if the base package Text.ParserCombinators.Parsec depends somehow on the package text. module Main where import Text.ParserCombinators.Parsec ch = char 'C' main = do seq ch (return ())___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text.ParserCombinators.Parsec requires -package text.
Ross Paterson wrote: On Mon, Sep 06, 2004 at 12:10:09PM +0200, George Russell wrote: With ghc ParsecTest.hs -o pt you get a link-time failure, because it looks as if the base package Text.ParserCombinators.Parsec depends somehow on the package text. Try -package parsec OK, I have. But if parsec is required for linking, I think it should also be required for compilation! ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-fwarn-misc
According to http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html there is a GHC option -fwarn-misc. But ghc-6.2.1 doesn't seem to have it. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Template Haskell, Haddock, -fwarn-missing-signatures don't mix
Not so much a bug this as a whinge: # ghc -c TH2.hs -fwarn-missing-signatures -fglasgow-exts Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. TH2.hs:6: Warning: Definition but no type signature for `a' TH2.hs:8: Warning: Definition but no type signature for `a' The problem here is that the type signature for 'a' is outside the splice while the definition is inside. This is a useful idiom for me, since for Haddock I preprocess files to strip out Template Haskell splices, but still want Haddock to see a type signature. module TH2 where $( if True then [d| a = 2 |] else [d| a = 4 |] ) a :: Int ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-fwarn-unused-binds misses a use
# ghc Unused.hs -fwarn-unused-binds -fglasgow-exts Unused.hs:10: Warning: Defined but not used: Dummy module Unused(Foo(..),ff) where class Foo (v :: (* - *) - *) where f :: v a - Int ff :: Foo v = v a - Int ff (_ :: (v :: (* - *) - *) a) = (f (error bar :: v Dummy)) data Dummy x = Dummy x___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-6.2.1 incorrectly reporting duplicate instance declarations
When I have a collection of files to compile and
(1) I use --make to compile them together;
(2) they are recursive
it works the first time, but when I try to compile them the
second time I get messages about bogus duplicate instance
declarations, for example:
Skipping GlobalRegistry ( GlobalRegistry.hs, GlobalRegistry.o )
Duplicate instance declarations:
In module CodedValue: Control.Monad.Trans.MonadIO CodedValue.CodingMonad
In module CodedValue: Control.Monad.Trans.MonadIO CodedValue.CodingMonad
Duplicate instance declarations:
In module CodedValue: GHC.Base.Monad CodedValue.CodingMonad
In module CodedValue: GHC.Base.Monad CodedValue.CodingMonad
Duplicate instance declarations:
In module CodedValue: CodedValue.HasCodedValue ty
In module CodedValue: CodedValue.HasCodedValue ty
It looks as if GHC 6.2.1 includes a new clever feature by which when a
module is imported using import {-# SOURCE #-}, it looks at the
corresponding .hi file (if one is available). I would guess that it is
somehow importing the instances from this .hi file; however this gets
it muddled so that it thinks instances are really being duplicated when
they are not.
Unfortunately I have given up (after about half an hour of trying) in my
attempts to reduce this to a small test case. If the Glasgow Haskell
people can't guess what is going on from the above description, I'll
happily explain to them how to obtain and compile the current workbench
sources (it's not as painful as it used to be) and hopefully it'll
be possible to demonstrate the problem.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Possible instances problem with ghc-6.2.1
With ghc-6.2.1 compiled from source tar -xzf instances2.tar.gz cd instances2 gmake produces the message: AttributesType.hs:15: Could not deduce (Show value) from the context (AttributeValue (Radio value), HasConfigRadioButton value, Bounded value, Enum value, FormLabel label) arising from use of `newFormEntry' at AttributesType.hs:15 However: (1) this does not seem to happen with ghc-6.2. (2) why does newFormEntry need Show anyway? It would only be relevant in deducing HasConfigRadioButton, but in fact it has that in the context anyway. Sorry I didn't report this earlier. instances2.tar.gz Description: GNU Zip compressed data ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Mysterious error from ghc6.2
# ghc -c FunnyError.hs
FunnyError.hs:7:
Couldn't match `Bool' against `[Char]'
Expected type: Bool
Inferred type: [Char]
In the definition of `b': b x Foo = ()
In the definition for method `b'
FunnyError.hs:9:
tcLookup: `FunnyError.$dmb' is not in scope
In the definition of `b': b = FunnyError.$dmb
In the definition for method `b'
In the instance declaration for `A Int'
The first error is correct, but the second error message is most peculiar,
is it not?
{- ghc6.2 -}
module FunnyError where
class A x where
a :: x - ()
b :: x - Bool - ()
b x Foo = () -- deliberate type error
instance A Int where
a _ = ()
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Package with no dependencies causes GHC to mislay standard prelude
Unpacking the attached bundle and running the following with ghc=GHC6.2 (Linux, compiled from the ghc-6.2 tag), produces the following: # cd packagesbug /home/ger/test/packagesbug # CompileBug /home/ger/test/packagesbug/package1 Chasing modules from: CompileFlags.hs Compiling CompileFlags ( CompileFlags.hs, CompileFlags.o ) Reading package info from stdin... done. Expanding embedded variables... done. building GHCi library `/home/ger/test/packagesbug/package1/package1.o'... done. Saving old package config file... done. Writing new package config file... done. Chasing modules from: UseCompileFlags.hs Compiling UseCompileFlags ( UseCompileFlags.hs, UseCompileFlags.o ) /home/ger/test/packagesbug/package1/package1.o: unknown symbol `__stginit_Prelude_' Loading package package1 ... linking ... ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): can't load package `package1' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. packagesbug.tar.bz2 Description: BZip2 compressed data ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-pkg makes unnecessary assumptions on Solaris
How do you install ghc so that ghc-pkg doesn't use the Solaris linker, but instead the GNU linker which is called (here) gnu-ld? Obviously it doesn't want to use the Solaris linker since that doesn't have the --whole-archive option ghc-pkg needs. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
Simon Marlow wrote (snipped): BTW George: there are plenty of 6.1.xxx snapshots available - these are the 6.2 prereleases. There are, but no recent ones. What I would like to have had is a 6.2-epsilon version, not 6.1 and a bit. We don't snapshot along the STABLE branch at the moment; no real deep reason, we'd just have to figure out a version numbering scheme, and this might upset various scripts that expect to parse the GHC version number. Since you have to build from source anyway, why not download the sources from CVS? The problem with downloading things direct from CVS is that I don't expect people to run substantial tests before checking things into CVS. (We don't on our CVS server.) Of course I don't expect a snapshot release to have the same reliability as a real release, but at least snapshot releases seem to compile and succeed in compiling themselves. Anyway Simon, is there a workaround to the sockets problem I posted or not? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
hGetBuf (or something related) broken for 6.2 with sockets
I have just installed ghc6.2 on Linux. (I had to compile it from source because the binaries insist on a glibc version we don't have.) The attached module contains two functions (serverMain) and (clientMain). clientMain opens a connection (to localhost) and sends some data along it, then executes hFlush. serverMain receives this data. They should display identical data. This should be run by (1) compiling the code using ghc Server.hs -c (2) starting up ghci in this directory, twice, in separate terminal windows. (3) in both ghci's doing :module Server (4) in one ghci doing serverMain (5) in the other ghci doing clientMain What happens is (a) the serverMain ghci displays Iterating several times. This is because hGetBuf appears to be terminating prematurely when there is still data to come on the socket. This is a pain (especially as I took several hours finding this was why my program didn't work), but at least it can be worked around, and the code in the module does this. (b) The server module only gets part of the data. In fact for me it comes to a stop with [239][240][241][242][243Iterating despite there being more data to come. (And despite the fact that the client has done hFlush). I don't know any way of working around (b), so I suspect that means ghc6.2 is unusable for us. What a pity no development snapshot was made for 6.2 shortly before its release, as it might have been possible for me to discover this bug in time for it to be fixed in 6.2.(I did try to test the 6.3 development snapshot but was grounded by the instances bug I've reported elsewhere.) module Server where import Char import IO import Random import Monad import Network import GHC.IO(hPutBuf,hGetBuf) import Foreign.C.Types import Foreign.ForeignPtr import Foreign.Marshal.Array import Foreign.Marshal.Alloc import Foreign.Ptr maxLen = (2000 :: Int) port = PortNumber 11394 host = localhost writeInt :: Handle - Int - IO () writeInt handle i = hPutStrLn handle (show i) readInt :: Handle - IO Int readInt handle = do l - hGetLine handle return (read l) runClient :: Ptr CChar - Handle - IO () runClient ptr handle = do mapM_ (\ _ - writeOut ptr maxLen handle mapM_ (\ toWrite - writeOut ptr toWrite handle ) [1..255] ) [1..4] hFlush handle writeOut :: Ptr CChar - Int - Handle - IO () writeOut ptr toWrite handle = do putStr ([++show toWrite) hFlush stdout writeInt handle toWrite hPutBuf handle ptr toWrite putStr (]) hFlush stdout getChars :: Handle - Ptr CChar - Int - IO () getChars handle ptr 0 = return () getChars handle ptr toRead = do read - hGetBuf handle ptr toRead if (read == 0) then error (Unexpected EOF) else return () if read toRead then putStrLn Iterating hFlush stdout getChars handle (plusPtr ptr read) (toRead - read) else return () readIn :: Ptr CChar - Handle - IO () readIn ptr handle = do toRead - readInt handle putStr ([++show toRead) hFlush stdout getChars handle ptr toRead putStr ] hFlush stdout runServer :: Ptr CChar - Handle - IO () runServer ptr handle = do readIn ptr handle runServer ptr handle clientMain = do ptr - mallocBytes maxLen handle - connectTo host port runClient ptr handle serverMain = do ptr - mallocBytes maxLen socket - listenOn port (handle,hostName,_) - accept socket runServer ptr handle ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Instances which worked in ghc6.0.1 don't work for developmentsnapshot 6.3.20031201
For ghc6.0.1 on Linux # ghc Test1.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances # ghc Test2.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances works. But for ghc6.3.20031201 the second compilation produces the message: Test2.hs:6: No instance for (FormValue (Maybe [Char])) arising from use of `isFormValue' at Test2.hs:6 In the definition of `is': is = isFormValue (Just ) Oddly enough the compilation works if you do it in one step using # ghc --make Test2.hs -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances module Test1 where class FormValue value where isFormValue :: value - () isFormValue _ = () class FormTextField value instance FormTextField String instance FormTextField value = FormTextFieldIO value class FormTextFieldIO value instance FormTextFieldIO value = FormValue value instance FormTextFieldIO value = FormTextFieldIO (Maybe value)module Test2 where import Test1 is :: () is = isFormValue (Just )___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Template Haskell panic
The attached file causes a panic when compiled with ghc6.0 on Linux.
# ghc -fglasgow-exts TH.hs -c
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
nameModule newLen0 {- v a35 -}
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
module T where
bp :: Int - IO Int
bp newLen0 =
do
let
newLen =
$(
-- work around GHC6 bug
if True
then
[| max 1 newLen0 |]
else
[| newLen0 |]
)
return newLen___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Problems with Template Haskell
Template Haskell seems to be type-checking some quasi-quotes, even when they are not going to be used. This is of course a terrible nuisance, since it means it can't be used to work around interface incompatibilities between libraries for different versions of GHC (such as the recent change in RegexString.matchRegexAll's type). Maybe I will have to go back to using cpp ... For example, the attached file fails to compile. # ghc TestSplice.hs -c -fglasgow-exts TestSplice.hs:7: Couldn't match `f a' against `Bool' Expected type: f a Inferred type: Bool In the second argument of `fmap', namely `True' In the definition of `TestSplice.p': TestSplice.p = fmap id True This occurs for both ghc 6.0.1 and the recent snapshot 6.3.20031201 Another problem is that Template Haskell objects to undefined variables in unused splices. Thus if I replace p = fmap id True in the attached file by foo = bar, I get TestSplice2.hs:7: Variable not in scope: `bar' module TestSplice where $( if False then [d| p = fmap id True |] else [d| d = 2 |] )module TestSplice where $( if False then [d| foo = bar |] else [d| d = 2 |] )___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Problems with Template Haskell
Simon Peyton-Jones wrote (snipped): Still, in your cpp-like application, I guess your story is that the condition might evaluate to True only if the system configuration was such that bar was in scope. If the condition evaluates to False, then bar really might not be available. OK, in TH (version 2 -- CVS HEAD) you want dynamic binding. You can say $(if ... then [|d foo = $(dyn bar) |] .. ) Now you won't get any type complaint, and bar will get looked up at the splice site of x. This is a bit cumbersome. Could there be some way of wrapping the whole quasi-quotation to stop it from being looked at in any way, except what is strictly necessary for converting it to a Q Dec or Q Exp, unless and until it is actually spliced? In fact, I for one would prefer that to be the default ... I appreciate that there are workarounds like $(dyn ...), and I've also come up with the solution of declaring idVar = [| id |] and then using $idVar in quasi-quotations, as a way of obfuscating the type so GHC doesn't complain. This is what is known as fighting the compiler ... Does that help? With dyn there's the problem that the module name and name of dyn have changed from ghc6 to ghc6.3. Meaning (a) without CPP I can't import Language.Haskell.THSyntax (6.0) / Language.Haskell.TH (6.3); (b) I can't refer to dyn in the first place anyway. While with CPP it all seems so easy. Of course (a) is an instance of a more general problem -- that we can't use Template Haskell to select between import declarations. It would be nice if we could. Of course there's the obvious problem that Template Haskell itself expects to be able to use the variables in imported modules. Would it be possible to allow a splice in the import list, but restrict its environment to previously imported modules? Am I doing the wrong thing here? Should I simply give up on the idea of replacing cpp with Template Haskell? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Incompatibilities between RPM .tar.gz versions of ghc-6.0.1
It seems as if the RPM and .tar.gz versions of ghc-6.0.1 are binary incompatible. That is, a library built for one will not necessarily work on the other. For example, libHSbase.a defines the symbol GHCziRead_lvl18_closure in the .tar.gz version, which can be externally called; however in the RPM version it is not defined. Many thanks for Walter Guttmann for discovering this. I hope he won't mind if I quote from his original message: No, I have another version of that file, also from a binary release, which explains the problem. The download homepage of ghc 6.0.1 http://www.haskell.org/ghc/download_ghc_601.html offers several binaries, even for x86/Linux. I found out that your libHSbase.a comes from Binary tar for Linux/x86 with glibc 2.2 and mine comes from base RPM (even though I do not use RedHat Linux). Note that the RPM's name is ghc-6.0.1-1.i386.rpm where the -1 might indicate something. The creation date of your libHSbase.a is 2003-07-29 and that of mine is 2003-07-30. I don't know if there have been some changes between the two builds, if they just forgot to update the other build or if the differences necessarily arise for the two builds (which would be very sad). Anyway, I installed the other build and was able to compile, link and run MainhsMines.hs. So I'm happy now, but you might want to contact the ghc-builders and ask them about the difference. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
LD_LIBRARY_PATH, ghc and Solaris
It looks like I am going to have to hack the shell script that calls ghc, because it needs to set LD_LIBRARY_PATH so that the executables can find libreadline. Would it be possible to have an option to ./configure that set a library path to be used by these scripts? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
hClose non-terminating
I have a problem with a handle for which hClose does not terminate. Unfortunately it's too much work for me to narrow it down now, but perhaps it can be worked out from these facts? (1) it's a socket connection. (2) it has BlockBuffering (Just 4096) set. (3) it is possible that another thread is simultaneously trying to read from it. (4) hFlush on the same handle terminates. (5) if I remove the hClose the program terminates (presumably closing the connection) successfully. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: peekCString stack overflow
Actually what I really need is peekCStringLen. This function can surely avoid stack overflow by building up the result from right to left? I think for peekCString the solution might be to get the length using the C function strlen (which is more optimised than a Haskell alternative) and then call peekCStringLen. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
peekCString stack overflow
The following program gives me a stack overflow for a file big.tex 15 bytes long. -- Cut here -- module Main where import Foreign.C.String import Foreign.Ptr import qualified GHC.IO main = do (ptr,len) - GHC.IO.slurpFile big.tex peekCStringLen (castPtr ptr,len) return () -- Cut here -- The message is Stack space overflow: current size 1048576 bytes. Could peekCStringLen be changed so it does not expect stack space proportionate to the input string? I use this method quite a lot for slurping strings in and out, so as it is the situation is inconvenient. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Segmentation fault with GHCi 6.0
What is going on here? Is it already fixed in 6.1?
# uname -a
Linux denebola 2.4.19-4GB #2 Mon Mar 31 10:57:24 CEST 2003 i686 unknown
# ghc DynExcep.hs -c -fglasgow-exts
# ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
GHC.Err.error :: forall a. [Char] - a
Prelude :module + DynExcep
Prelude DynExcep dynExcep
Segmentation fault
module DynExcep where
import Data.Dynamic
import Control.Exception
data FallOutExcep = FallOutExcep {
fallOutId :: Int,
mess :: String
} deriving (Typeable)
type BreakFn = (forall other . String - other)
mkBreakFn :: Int - BreakFn
mkBreakFn id mess = throwDyn (FallOutExcep {fallOutId = id,mess = mess})
dynExcep = mkBreakFn 1
GHC running out of memory, surprisingly.
Yes, I know functional languages are memory hogs, but really! The following is on linux # ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0, for Hask / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude :module + Foreign.Marshal.Alloc Prelude Foreign.Marshal.Alloc b1 - mallocBytes 1000 Prelude Foreign.Marshal.Alloc b2 - reallocBytes b1 0 *** Exception: resource exhausted Action: realloc Reason: out of memory ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Strange ghci :def failure
What is wrong here?
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude :def code (\ - do { let {getCode acc = do { next - getLine ; if next ==
:edoc then return . unwords . reverse $ acc else getCode (next : acc)}} ; getCode [] } )
ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
getLinkDeps No iface for [pkg]GHCziErr
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc --make and missing interface files
Hello all, I have a file BinaryIO. This used to import a module HGetCharHack to work around an annoying problem with ghc5.04 which meant that hGetChar was blocking unexpectedly. However I see that this problem has now been fixed in ghc6 (ta very much, Simon) so I deleted the files HGetCharHack.*, modified BinaryIO to stop importing it, and then tried to compile it using ghc --make. However the thing fell over, as follows: Skipping ... (lots of files) ... Skipping UnionFind Could not find interface file for `HGetCharHack' (use -v to see a list of the files searched for) What I think is happening is that ghc --make is picking up BinaryIO.hi somehow, discovering that it refers to HGetCharHack, and complaining when it can't find HGetCharHack. At any rate, deleting BinaryIO.hi fixed the problem. What I think it should do is not look at BinaryIO.hi when BinaryIO.hs is newer, or at least not be so surprised when an obsolete BinaryIO.hi refers to non-existent modules. Oh, by the way, I don't think I've said thank you very much for ghc6, which in general is very good, and mostly works fine, so please take that as read now. Alas there isn't a [EMAIL PROTECTED] list, so -bugs will have to do ... ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Can't install ghc-6.0 on Solaris
# uname -a SunOS leo 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Fire-280R # ./ghci ./ghci: /nfs/moussor/hdaume/lib/ghc-6.0/ghc-6.0: not found Also the install process failed as follows: ./mkdirhier /usr/local/pub-bkb/ghc/ghc-6.0/share/ghc-6.0/html if test -d share/html ; then cp -r share/html/* /usr/local/pub-bkb/ghc/ghc-6.0/share/ghc-6.0/html ; fi for i in share/*.ps; do \ cp $i /usr/local/pub-bkb/ghc/ghc-6.0/share/ghc-6.0 ; \ done cp: cannot access share/*.ps gmake: *** [install-docs] Error 2 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc installation on Linux doesn't like CDPATH
The cd command on Linux considerately prints out the name of the new directory, which it gets from the CDPATH. This has the unfortunate side-effect of breaking gmake install for ghc6.0, which uses some shell hackery of the form something like: for i in `(cd share ; find .)` where i's first value will of course be the new directory printed out by cd. The workaround is to set CDPATH to null. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Posix.getFileStatus
(1) I think Posix.getFileStatus should respond to a file which isn't there with something rather more helpful than system error. For example, a No such file or directory message. (2) The logical way of spotting whether a file is actually there is the queryFile function, documented for example here: http://haskell.cs.yale.edu/ghc/docs/latest/html/hslibs/files-and-directories.html But sadly the queryFile function does not appear to be in the Posix module! At least not for ghc5.04.2. Good thing there's a Directory.doesFileExist function! Of course that's not quite the same, since it only checks if there is a normal file of that name (it returns False for a directory). ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc5.04.1 deriving Read/Show broken
Manuel M T Chakravarty wrote: [snip] Luckily, there is a workaround (discovered by Tom Moertel on #haskell). If you include field names in the data definition for which you derive Show and Read, it seems to work fine. [snip] Thanks. I may try this, if I get time. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Division by 0 exits ghci
On Solaris: # /home/ger/ghc-5.04.1.install/bin/ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude 1 `div` 0 Arithmetic Exception # (no more ghci) Isn't this a little drastic? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Division by 0 exits ghci
In fact the problem is more drastic than I mentioned in my last message; division by 0 doesn't seem to be catchable at all. From this program --- cut here --- import Exception main = do excep - Exception.try (seq (1 `div` 0) (return ())) putStrLn Survived --- cut here -- I get the output Arithmetic Exception on Solaris and Floating point exception on Linux, while I think I ought to get Survived. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: FFI: passing 6 FD arguments doesn't work
Simon Marlow wrote: This was a bug in GHC's native code generator for SPARC, which sometimes misaligned the stack pointer. This has already been fixed in CVS (HEAD and branch), but it didn't make it into 5.04, see: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/nativeGen /MachCode.lhs.diff?r1=1.100r2=1.101 I was just getting around to having a look at this one. George, can you verify that your test case works fine if you use -fvia-C? If so, I'll assume it's this NCG bug. The fix has been merged into the forthcoming 5.04.1. Yes, it works with -fvia-C. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
FFI: passing 6 FD arguments doesn't work
uname -a: SunOS titania 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-1 ghc --version: The Glorious Glasgow Haskell Compilation System, version 5.04 gcc --version: 2.95.3 With the files in the attached archive unpacked: ghc hw5.c TestHW5.hs -ffi -package posix -o hw5 -Wall ./hw5 produces output Hello World (it works). ghc hw.c TestHW.hs -ffi -package posix -o hw -Wall ./hw produces output Illegal Instruction (it doesn't work). However the only difference between the two is that the C function called by TestHW.hs has 6 arguments of type Fd, while that called by TestHW5.hs has only 5. I hope this gets fixed soon; I have just spent an embarassing amount of time tracking down this bug, and I wouldn't like it to bit anyone else. hw.tar.gz Description: Binary data
Posix.executeFile having problems with unevaluated argumnets
Sorry, I haven't got time to narrow this down to a test case, but here are what I hope are the key factors: (1) We start up applications in a child process (forked with Posix.forkProcess) by calling Posix.executeFile, wrapped in an Exception.catch handler (to detect errors). (2) Both the third (arguments) and fourth argument (environment) of Posix.executeFile are non-empty. The environment at least requires some computation, being obtained by prepending another setting to the result of Posix.getEnvironment. (3) The second argument of Posix.executeFile is True. (4) The executable of the whole compiled Haskell program is pretty big (13.6MB). This may be relevant because the problem I am about to describe developed quite suddenly yesterday afternoon, after I'd made some small changes to completely unrelated areas of the program, and the only explanation I can think of is that in some way the slightly increased size of the executable triggered the problem. What happens is that the arguments and environment are somehow garbled. This is surprising, but I have good evidence for it, obtained by putting a small proxy binary between Haskell and the environment. For example it does echo indefectible $* | mail ger [the real application] $* and although the argument should actually be -pipe, what I get mailed is my current PATH, or something of the sort. Yes I know it's hard to believe. Fortunately I have discovered a fix. If I insert the commands deepSeq (args parms) done deepSeq (env parms) done just before doing executeFile (actually they are also outside the exception handler) everything works swimmingly. deepSeq is just that helpful utility which forces full evaluation of its argument, and so this forces full evaluation of the arguments and parameters. As I have a fix, and not much spare time, I'm afraid I can't do much to fix this. But could someone eyeball the code for Posix.executeFile and see if there's something obviously wrong? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Loading packages into ghci doesn't set options.
For example, with the attached test-package.conf file, we see that -fglasgow-exts in the first case works (because the package is loaded in the beginning), but in the second case it doesn't (because the package is loaded during GHCi). This also applies to -fallow-overlapping-instances and friends, it appears. ghci -package-conf test-package.conf -package uni-options ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package uni-options ... linking ... done. Prelude let (a :: Int) = 2 Prelude :quit Leaving GHCi. # ghci -package-conf test-package.conf ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude :set -package uni-options Loading package uni-options ... linking ... done. Prelude let (a :: Int) = 2 interactive:1: Illegal signature in pattern: Int Use -fglasgow-exts to permit it Prelude test-package.conf Description: Binary data
IOExts.slurpFile fails on zero-length files
Specifically I get
*** Exception: invalid argument
Action: hGetBuf
Handle: {loc=/tmp/d,type=readable,binary=False,buffering=block (8192)}
Reason: illegal buffer size 0
whether using 5.03.2 on Solaris or 5.03.20020410 on Linux.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Private package files don't work on Linux with ghc5.03.20020204
I have a private package file (attached). However, specifying this via -f to the new ghc-pkg has the following unpleasant consequences: (1) -l only knows about the packages in my private file, not in the GHC one. (2) When I try to add a new package to this file that depends on one of the GHC packages, it fails with the message dependency `concurrent' doesn't exist uni-package.conf Description: Binary data
Panic loading objects with big strings in Windows
With ghc-5.02.3 on Windows starting with a package containing an object with a large String I get the following message. Note the last line. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package text ... linking ... done. Loading package uni-options ... linking ... done. Loading package uni-util ... linking ... done. Loading package uni-events ... linking ... done. Loading package uni-reactor ... linking ... done. Loading package uni-htk ... ghc.exe: panic! (the `impossible' happened, GHC version 5.02.3): loadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. PEi386 object has suspiciously large string table; 64k relocs? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
panic in ghc5.02.3
(This is on sparc-solaris) # /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc --make resources/GUIValue.hs resources/Colour.hs -fglasgow-exts ghc-5.02.3: chasing modules from: resources/GUIValue.hs,resources/Colour.hs Compiling GUIValue ( resources/GUIValue.hs, resources/GUIValue.o ) Compiling Colour ( resources/Colour.hs, resources/Colour.o ) ghc-5.02.3: panic! (the `impossible' happened, GHC version 5.02.3): Maybe.fromJust: Nothing Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Is there a workaround, or am I going to have to go back to ghc5.02.2? Personally I suspect multi-parameter type-classes bug.tar.gz Description: Binary data
Re: panic in ghc5.02.3
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 where the .hi file is, since it knows where GUIValue.hs is.) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: panic in ghc5.02.3
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 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 where the .hi file is, since it knows where GUIValue.hs is.) That's still a bad error message. Precisely what files were where, and what files were missing to make it fall over like that? untgz the archive I sent. You will get a directory called resources. (It may be contained in a directory called bug; I can't remember). With current directory the directory containing resources, execute the command I gave. If you can reproduce the bug, then it's over to you. If not, ask for more details . . . ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Does ghc have daemon threads again?
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? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Dynamic types/multiparameter type classes
Something is rotten in the state of dynamic types and multiparameter type classes. I'd be grateful if you'd fix it soon, this is causing me big difficulties. I'm sorry if this is complicated, but I've already spent two hours narrowing this bug down and the security are about to throw me out of the building . . . uname -a SunOS bob 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-280R ghc --version The Glorious Glasgow Haskell Compilation System, version 5.02.2 mkdir bug cd bug tar -xvzf [attachment] ghc -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -package lang FoldersTest.hs TestFT.hs -o testFT ./testFT Fail: loop [ OK, so main function isn't working] ghci -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -package lang [GHCi startup screen] Prelude :load FoldersTest Compiling FoldersTest ( FoldersTest.hs, interpreted ) Ok, modules loaded: FoldersTest. FoldersTest Prelude.putStrLn (Prelude.show (Dynamic.typeOf (Prelude.undefined :: Folder))) Folders.Folder [So this DOES terminate. However it is exactly the same as the main function called by testFT. So what is going on] bug.tar.gz Description: Binary data
The Handle returned by connectTo and accept is unbuffered by default.; oh yeah?
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 hPutStrLn it works. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
The signature contexts in a mutually recursive group should all be identical; why?
The attached file doesn't compile (ghc -fglasgow-exts), with the message RecContext.hs:12: Mismatched contexts When matching the contexts of the signatures for g :: forall a b. (Silly a b) = a - b - SillyType a - [String] f :: forall a. SillyType a - [String] The signature contexts in a mutually recursive group should all be identical When generalising the type(s) for g, f This seems strange. f can't have the context Silly a b, as b doesn't occur in its signature and is introduced later as part of an existential constructor . . . I know this code looks pretty pointless. If you want to see the Real World 450 line module which provoked the message, do ask, but only if you like having your brain curdled by mixtures of dependent types, existential types and overlapping multi-parameter type classes . . . RecContext.hs Description: Binary data
Confusing GHC error message
(Yes, I know that's not very impressive, but you must all have been wondering what's happened to me.) The attached file, when compiled with ghc5.02.1, -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances produces the error message Haskell.hs:11: Illegal left hand side in data/newtype declaration This is rather confusing, as the error comes not from the data declaration in the file, but because on the next line class was accidentally typed, rather than instance. Haskell.hs Description: Binary data
Re: whitespace in strings (was ghc misreports the error line)
Malcolm Wallace wrote, answering me: On the contrary I'm glad to see that the Haskell standard is so sensible. I edit Haskell using XEmacs, and I don't want to have to do an octal or hexadecimal dump of my source code to determine whether a string contains a tab, newline, return, line feed, Unicode en-space (there are several funny Unicode space characters available) or whatever. Syntax colouring, or indeed careful visual inspection, is good enough to reveal the extent of a string literal. I don't see why a hex dump is required. It reveals the extent, but not the contents. It is an unfortunate fact that the layout system means that invisible spaces of various types can transform one valid program into another inequivalent valid program, Both tabs and newlines are visible to me. Adding _any_ character, whitespace or not, to a string literal changes a valid program to another valid program. I'm afraid I don't know what point you are trying to make here. Can you elucidate? I cannot distinguish between tabs and sequences of spaces just by their appearances. And adding vertical tabs, returns, linefeed and miscellaneous unicode spaces would make things even worse. Allowing newline in string literals is also a bad idea if you want any kind of intelligent error-recovery (admittedly lacking in GHC and Hugs), since if you miss out a character the lexer has no way of recovering until it hits EOF. It really isn't difficult to give a sensible error message when the close quote is missing. It is however difficult to do error-recovery. Possible perhaps, but writing error-correcting parsers is hard enough as it is without us making it more difficult. Personally, I quite like being able to embed newlines in string literals because it reduces the meta-character clutter in long sections of text (e.g. help messages). I don't really find it very hard typing main = putStrLn hello,\n\ \world This style also has the advantage of preserving indentation, as well as making it clear exactly what of the various end-of-line characters (return, linefeed, formfeed, newline or whatever) is being printed. And note that no compiler/interpreter currently rejects a string containing a literal tab character.`` No Haskell compiler that I know of does error-recovery on lexing or parsing. But they should, in my opinion. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc misreports the error line
Malcolm Wallace wrote:
[snip]
No he isn't. At least, I can't find anything in the Report which
disallows literal newline characters in a string literal.
Oh, hold on. The production
string - { graphic_|` | space | escape | gap }
does seem to disallow newline characters. But it also disallows
literal tab characters! I submit that this is a bug in the Haskell'98
Report, and it should really say
string - { graphic_|` | whitechar | escape | gap }
[snip]
On the contrary I'm glad to see that the Haskell standard is so sensible.
I edit Haskell using XEmacs, and I don't want to have to do an octal
or hexadecimal dump of my source code to determine whether a string
contains a tab, newline, return, line feed, Unicode en-space (there are
several funny Unicode space characters available) or whatever. If you
want a tab (and mostly they are a total pain in the neck, if not lower
down) you can jolly well write \t.
It is an unfortunate fact that the layout system means that invisible
spaces of various types can transform one valid program into another
inequivalent valid program, but I see no reason to make things even worse.
Allowing newline in string literals is also a bad idea if you want any
kind of intelligent error-recovery (admittedly lacking in GHC and Hugs),
since if you miss out a character the lexer has no way of recovering
until it hits EOF.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc5.02 can't read its own interface file.
The attached interface file SimpleForm.hi provokes the following error from ghc5.02: MainsimpleFormEx.hs:6: failed to load interface for `SimpleForm': Bad interface file: /home/ger/uni/htk/toolkit/SimpleForm.hi /home/ger/uni/htk/toolkit/SimpleForm.hi:155 Interface file parse error; on input ` label ' when read in later, although it is generated by ghc5.02 itself from the attached file SimpleForm.hs with command line /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c toolkit/SimpleForm.hs -package concurrent -package data -package net -package posix -package text -package util -package lang -i.:packer:resources:canvasitems:kernel:containers:menuitems:toolkit:components:toplevel:widgets:devices:textitems:tix:/home/ger/uni/util:/home/ger/uni/events:/home/ger/uni/reactor:/home/ger/uni/server:/home/ger/uni/htk:/home/ger/uni/davinci:/home/ger/uni/graphs:/home/ger/uni/tools:/home/ger/uni/cvs:/home/ger/uni/types -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -ddump-hi-diffs -H25M -recomp -fwarn-deprecations -Onot -DDEBUG -Onot -H30M -fasm What is going on? I can send the complete .hi files for this project, but I'm not doing so here as it would bust haskell.org's 40k limit so delaying this extremely irritating bug from being reported and hopefully fixed. Is there a workaround? SimpleForm.hs Description: Binary data SimpleForm.hi Description: Binary data
import with hiding
DaVinciTypes defines the types DaVinciAnswer and the constructor Context. (.hi file attached.) So I would expect import DaVinciTypes hiding (Context) import qualified DaVinciTypes to make DaVinciAnswer in scope, but DaVinciTypes.Context only available when so qualified. This doesn't appear to be the case with the following command line on Sparc/Solaris: /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c DaVinciBasicTest.hs -package concurrent -package data -package net -package posix -package text -package util -package lang -i.:/home/ger/uni/util:/home/ger/uni/events:/home/ger/uni/reactor:/home/ger/uni/server:/home/ger/uni/htk:/home/ger/uni/davinci:/home/ger/uni/graphs:/home/ger/uni/tools:/home/ger/uni/cvs:/home/ger/uni/types -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -ddump-hi-diffs -H25M -recomp -fwarn-deprecations -Onot -DDEBUG -fasm and attached file DaVinciBasicTest.hs, for I get the error DaVinciBasicTest.hs:7: Type constructor or class not in scope: `DaVinciAnswer' What's going on please? DaVinciTypes.hi DaVinciBasic.hs
ghci panic on unloadObj
ghci -iutil:events -syslib lang -syslib data -syslibconcurrent util/object.o [ lots of stuff skipped ] Events :load GuardedEvents unloadObj: can't find `events/Events.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Events was previously loaded. Indeed ghci displayed the messages: Skipping Events ( events/Events.hs, events/Events.o ) Ok, modules loaded: Events, Toggle, Computation, Spawn, Object, Maybes, Debug. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc panic (this time due to openFile error):
In trying out a particularly large set of files (circa 450) with ghc --make I get ghc-5.00: panic! (the `impossible' happened, GHC version 5.00): resource exhausted Action: openFile Reason: process file table full File: /tmp/ghc14562.hspp Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. I presume that this is due to some system limitation. But it is a pity really, since it would save a lot of time if I could compile all these files in one go. Can you explain what is going on and how I avoid it? Also I think ghc is overreacting when it panics . . . ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Another bug I think
I'm trying to get UniForM through ghc 5.00 (limping at the moment, as I have to turn on -fasm -Onot to work around bugs previously reported) and I get ghc-5.00: panic! (the `impossible' happened, GHC version 5.00): ERROR: Native code generator can't handle casm Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Which is what I'm now doing. Actually I think in this case the bug is that this is an error message rather than a panic . . . ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc5.00 misreads a comment . . .
This is ghc5.00/Sparc, running with the following command line
/usr/local/pub-bkb/ghc/ghc-5.00/bin/ghc -c CVSHigh.hs -package concurrent -package
data -package net -package posix -package text -package util -package lang
-i.:/home/ger/uni/util:/home/ger/uni/concurrency:/home/ger/uni/reactor:/home/ger/uni/server:/home/ger/uni/htk:/home/ger/uni/davinci:/home/ger/uni/graphs:/home/ger/uni/tools:/home/ger/uni/cvs:/home/ger/uni/types
-fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp
-ddump-hi-diffs -H25M -recomp -fwarn-deprecations -Onot -DDEBUG -fasm
The first lines of CVSHigh.hs are:
{-# This module encapsulates the basic CVS functionality we need,
calling CVSBasic to issue the commands, looking at the output,
and returning what we need to know in a Haskell-friendly form.
#-}
module CVSHigh(
(The complete module is attached)
The file compiles OK, but to my surprise, I cannot find CVSHigh.hi.
Further investigation reveals that instead I have "encapsulates.hi"
(also attached). It looks as if GHC chooses the name "encapsulates"
from the comment. Indeed if I change "encapsulates" to "wraps"
I get wraps.hi. However if I replace "This module e" by "E", sanity
returns.
So er what exactly is going on please? I thought that unless a comment
began with something like OPTIONS or INLINE it would be treated as
a "real" comment.
CVSHigh.hs
encapsulates.hi
Mysterious file reference in ghc distribution
I was just trying to compile the new ghc 5.00 on Sparc/Solaris and got this: ==fptools== gmake boot --no-print-directory -r; in /home/ger/ghc-5.00/ghc/lib/std/cbits ../../../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -Wall -DCOMPILING_STDLIB -I../../../includes -I../../../rts-- closeFile.c echoAux.c errno.c fileEOF.c fileGetc.c fileLookAhead.c fileObject.c filePosn.c filePutc.c fileSize.c flushFile.c freeFile.c getBufferMode.c getCPUTime.c getLock.c inputReady.c openFile.c progargs.c readFile.c seekFile.c setBinaryMode.c setBuffering.c system.c tcSetAttr.c writeError.c writeFile.c ===fptools== Finished making `boot' in cbits ... PWD = /home/ger/ghc-5.00/ghc/lib/std ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc ../../../ghc/utils/hsc2hs/hsc2hs-inplace: /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin: not found Er, that filename don't look very unix-standard to me . . . ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
panic in 4.08.2.
Compiling the above Haskell file with ghc4.08.2 (Sparc-Solaris) and the hi files in the attached archive, options: -c -package concurrent -package data -package net -package posix -package text -package util -package lang -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -hi-diffs -H25M -K5M -recomp -fwarn-deprecations -O -O2-for-C I get the following message: panic! (the `impossible' happened): IdInfo parse failed zdwzdfHasSendGuardedChannel ./GuardedChannels.hi:58 Interface file parse error; on input ` :: ' Please report it as a compiler bug to [EMAIL PROTECTED] SIGH. This is inconvenient. How do I work around it until ghc4.08.3 comes out? WrapIO.hs hifiles.tar.gz
Re: panic in 4.08.2.
Simon Peyton-Jones wrote: [snip] There's a simple workaround: - don't export unfoldings for the offending module (GuardedChannels). - or edit the .hi file by hand to remove the offending kind signature. (I did this and it worked fine) Drat. [snip] Well the first workaround (hacking my Makefiles to compile GuardedChannels with -funfolding-interface-threshold0) works. Many thanks for the quick service, George Russell ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop when running hsc
Simon Marlow wrote: Ok, we'll need to investigate but this is going to be a tricky one to track down. Is there any way you can try to narrow down the problem? sigh Oh alright then. It's taken me some time but attached is a version narrowed down to just two files. When you've unpacked it, go into the directory and do gmake GHC=... BUG where "..." is your ghc command (for Linux, 4.08.1). At the end of the second compilation I get a message: hsc: no threads to run: infinite loop or deadlock? ghcbug.tar.gz
Re: Why is variable out of scope?
Simon Peyton-Jones wrote: It's a bug all right, and a bizarre one at that. It's fixed in the before-ghci-branch. I'm not quite certain when it got fixed, mind you! Hmm. Maybe we're going to need 4.08.2. The trouble with all this wondrous new GHC code is that one suspects that it has fixed many of the old bugs by introducing lots of NEW ones. Have you tried compiling UniForM (now up to 48000 lines of Haskell) with GHC lately? I stopped trying to compile GHC from CVS ages ago when I was getting unexplained core dumps which apparently could only be fixed by reinstalling gcc/binutils . . . I would appreciate it if the two bugs I've reported in the last two days were fixed, but I wonder where on earth this is going. Is the idea to keep on producing 4.08.* patches until you're finally confident enough with the head branch of the CVS repository to turn it into a proper release? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Why is variable out of scope?
Simon Peyton-Jones wrote: Send us details about how to get access to your CVS archive, plus instructions on how to build it, and we'll set it up. Well you can read http://www.informatik.uni-bremen.de/~ger/cvs/CVS.html but (touch wood) the following should work (bash is assumed) (1) export CVSROOT=:pserver:[EMAIL PROTECTED]:/repository (2) cvs login and type "cvsread" when it asks for a password. (3) cvs checkout uni (4) cd uni (5) you need to manually edit (sorry, I'm just about to work on the configuration business, honest . . .) the file mk/machinedep.mk to set the variables HCHOME (where is GHC) and SOCKETLIB (depends on Linux/Solaris); see comments in file. (6) ./CONFIG (If it produces warnings about not being able to find Wish etcetera, that means you won't be able to run the programs until it can, but you should be able to compile them.) (7) gmake depend (8) gmake clean If you're freshing the sources: (1) cd uni (2) cvs update -Pd (3) ./CONFIG (4) gmake depend (5) gmake should work. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Why is variable out of scope?
Simon Marlow wrote: [snip] I stopped trying to compile GHC from CVS ages ago when I was getting unexplained core dumps which apparently could only be fixed by reinstalling gcc/binutils . . . And that's our fault? [snip] I've no idea whose fault it is. I think there are various complications about whether or not one should use the system ld/ar utilities with gcc which _may_ be to blame, but i think I gave up on investigating this. In any case ghc4.08 is a pretty good release which has everything I need and does indeed seem to be comparatively free of bugs, so there's little temptation to upgrade. It's also good that other people can compile UniForM without going through the hassle of getting a CVS release of GHC compiled. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
loop when running hsc
With ghc-4.08.1, running on Linux with -0 -O2-for-C, I get: loop With ghc-4.08, running on Solaris, with -O -O2-for-C, I get: hsc: no threads to run: infinite loop or deadlock? With ghc-4.08, running on Solaris, with -Onot, the compilation works. For the sources you will need the whole of UniForM again, instructions on request. What is going on? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False duplicate or overlapping instances message
Marcin 'Qrczak' Kowalczyk wrote: [snip] I am worried if the following scenario is possible: There are two modules. Everything is OK. Now one of them adds an innocent instance. It is perfectly correct in its context, but it happens that it triggers an ambiguity in the second module. Still neither module itself is at fault. [snip] I don't have a concrete case in mind... [snip] I do though. I mentioned it before. I don't see how you can get a worse example in principle than this. Module 1: class Integral number where [ operations on numbers ] instance Integral number = Show number where [ extract digits in obvious way ] Module 2: class String string where [ operations on strings ] class String string = Show string where [ extract canonical ASCII string representation ] As a matter of fact GHC would not have a problem with these modules (unless perhaps someone imports both of them - I don't know if it checks that). In any case I would rather it didn't have a problem with them. I suspect some of my code already relies on it not having a problem. Now suppose J. Random User comes along three years later and adds something that's an instance of both Integral and String. S/he tries to show this hybrid. Then we DO have a problem. But not until then. I personally think it's quite alright to print out a message at this stage along the lines of "I'm sorry, I can't work out which instance of Show to use, because it could come from Integral (see Module 1) or from String (see Module 2)." Compare the case when Modules 1 2 give the same symbol different definitions. Haskell doesn't have a problem. It doesn't even have a problem if you import the two modules in the same file. It only has a problem if you try and use that symbol in that file. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
False duplicate or overlapping instances message
When I compile the attached file on Linux with 4.08.1: /home/ger/ghc-4.08.1-binary/bin/ghc -c Instances.hs -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances I get the message: Instances.hs:1: Duplicate or overlapping instance declarations for `HasConfig (arcTypeConfig value) (arcTypeParms value)' defined at Instances.hs:19 and defined at Instances.hs:11 This is not fair, because while the instances for HasConfig have the potential to conflict in the future, they will only do so should the classes NodeTypeConfigParms and ArcTypeConfigParms overlap. Instances.hs
Re: False duplicate or overlapping instances message
Keith Wansbrough wrote:
Instances.hs:1:
Duplicate or overlapping instance declarations
for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
defined at Instances.hs:19 and defined at Instances.hs:11
This is not fair, because while the instances for HasConfig have the
potential to conflict in the future, they will only do so should the classes
NodeTypeConfigParms and ArcTypeConfigParms overlap.
It is fair. Let's rename your type variables to make what's going on a little
clearer:
main = return ()
class HasConfig a b where
($$) :: a - b - b
class NodeTypeConfigParms a b where
nodeTypeConfig :: a c - b c - b c
instance (NodeTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = nodeTypeConfig
class ArcTypeConfigParms a b where
arcTypeConfig :: a c - b c - b c
instance (ArcTypeConfigParms a b) = HasConfig (a c) (b c) where
($$) = arcTypeConfig
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
and ArcTypeConfigParms a b. Which there aint.
If you do -fallow-undecidable-instances, I think your program will
work (in the Prolog-ish backtracking way), but note that if
NodeTypeConfigParms and ArcTypeConfigParms are ever given instances at
the same pair of types, the value of ($$) will be undefined.
As a matter of fact I DID use -fallow-undecidable-instances, as you can see
from my original contribution . . .
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False duplicate or overlapping instances message
Keith Wansbrough wrote:
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
and ArcTypeConfigParms a b. Which there aint.
Haskell makes the "open world" assumption... there may be new
instances added later, and the behaviour of a well-typed program
should not change if this occurs.
I'll defer further discussion of this to the experts (Mark Jones?).
I think I've worked out what's going on now. But I don't like it.
When I use -fallow-undecidable-instances and -fallow-overlapping-instances
(as I did) I was assuming (like Keith Wansbrough did) that GHC would do a
Prolog-style backtracking search when it was time to resolve an overloading,
and would only complain if there were more or fewer than one chain of inferences.
Instead Haskell eagerly tries to anticipate possible conflicts, which is a nuisance
when it is obvious (as it is to me in this case) that such conflicts are unlikely
to arise. For a simpler example, imagine that we have two classes
Integral a (things corresponding to integers) and String a (things corresponding to
strings). It is a pity that we cannot write
instance Integral a = Show a
and
instance String a = Show a
just because someone may come along later on and try to show something which is an
instance of both Integral and String. (Though obviously if they do, we DO need an
error message.)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Program won't go away!
Marcin 'Qrczak' Kowalczyk wrote:
Wed, 18 Oct 2000 16:32:21 +0200, George Russell [EMAIL PROTECTED] pisze:
In a standalone GHC program, only the main thread is required to
terminate in order for the process to terminate.
I have a program (which does some fairly complex things with forking processes,
The above fact applies to threads (module Concurrent), not processes
(module Posix).
In some sense it does apply to processes, but the interface of
forkProcess allows to "continue execution" with the child process,
while the main process (parent) waits somewhere.
I don't understand what you mean. However I don't think that it's that simple.
NB:
(1) all the child processes do executeFile almost immediately after being forked.
(2) the main program is still hanging, after printing "Test completed", even
though according to ps the main program is the only process (apart
from the enclosing shells) running on that terminal.
the very last line of the "main" action is:
putStrLn "Test completed"
The program prints "Test completed", but then hangs.
Quite possible. For example (untested):
I don't see what this example has got to do with mine, since it prints
"Test completed" in the new process, while waiting in the old one.
main = do
pid - forkProcess
case pid of
Nothing - return () -- This is the new process.
Just _ - do
-- This is the old process.
sleep 100; exitWith ExitSuccess
-- This is the new process.
putStrLn "Test completed"
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Program won't go away!
Marcin 'Qrczak' Kowalczyk wrote: On Thu, 19 Oct 2000, George Russell wrote: I don't see what this example has got to do with mine, since it prints "Test completed" in the new process, while waiting in the old one. I suspect that your program does the same thing. I.e. that the rest of main is not executed by the main process. This is not correct. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Program won't go away!
I think I've narrowed the problem down a bit further. It looks as if the reason GHC is hanging after the end of the main action is that there's a handle still open to a socket (to another process). If I hClose the handle explicitly before the end of the main action, the hClose action returns (I get a message printed afterwards to prove it) and then the following happens: select: Bad file descriptor test1: fatal error: select failed I don't use the Posix.select function or whatever it's called anywhere explicitly, so it looks as if it's a bug in GHC (maybe the socket handle is somehow in a bad state). Still at least the program crashes at the end of the main action, rather than hanging, which is an improvement. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Program won't go away!
In the GHC document, section "GHC-specific concurrency issues", it says: In a standalone GHC program, only the main thread is required to terminate in order for the process to terminate. I have a program (which does some fairly complex things with forking processes, calling sockets etcetera) for which this doesn't appear to be true. Specifically, the very last line of the "main" action is: putStrLn "Test completed" The program prints "Test completed", but then hangs. I am using the ghc-4.08.1 binary release on Linux. What is going on. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Depend: fatal error: stg_update_PAP: strange activation record
"Julian Seward (Intl Vendor)" wrote: Sounds like some kind of rts/code generation bug. We fixed a few in 4.08, so the recently released 4.08.1 might work better. As usual the best thing you can do is send us a test case showing the problem; can you do that? Sadly not because this was at the top of a huge mountain of code which I have changed too much since reporting the bug. I managed to remove the bug anyway in the end by removing a duplicate multi-parameter class definition. File 1 defined class A x, class B y, and class (A x,B y) = C x y. It also declared instance (A x,B y) = C x y. File 2 declared (wrongly I suppose) a duplicate instance (A x,B y) = C x y, plus a specific instance C P Q. File 3 used a function on C x Q, assuming C x Q as context. Removing the first instance of (A x,B y) = C x y solved the problem. If you want code that actually reproduces the bug I MAY be able to get back to the situation of several days ago, but don't count on it.
Re: openFile, process file table full
Simon Marlow wrote: I'm of the opinion that readFile/hGetContents are useful for small programs, Personally I think Haskell would be a better language without them. But maybe it's too late now . . .
Re: Blocking I/O FIFOs
Simon Marlow wrote: Grrr. This works: module Main (main) where import IO import Posix import PosixUtil import Concurrent main = do h - openFile "/tmp/fifo" ReadMode fd - handleToFd h threadWaitRead (fdToInt fd) line - hGetLine h putStrLn line Are you sure? With the latest version of GHC (CVS as of yesterday evening) I am getting hGetLine failing with code 0 even when I put in all the palavar about threadWaitRead before. Or is this a bug?
Re: Blocking I/O FIFOs
Simon Marlow wrote: I can't repeat this problem; on both Linux/x86 and Solaris/Sparc here the Haskell process will block until another process opens the FIFO for writing, and will return EOF after the writing process closes the FIFO. This appears to be correct according to the POSIX spec. If you get an EOF on a FIFO handle, and you want to wait for more data, I guess the right thing to do is close and re-open the FIFO. However I think I am getting exactly the same problem. (On Solaris/Sparc, using CVS GHC compiled by itself.) However instead of using pipes I am using sockets. Even worse, if the party of the second part closes the handle attached to the socket, and the Haskell process to which the socket is attached subsequently attempts to read, the result seems to be an immediate exit from the entire Haskell process, though so far I haven't reported this since I presume it's for the same reason that threadWaitRead causes a crash when the Fd disappears.
ghc can't make DrIFT
Er what is going on here? CVS sources from this morning, building with GHC binary release. ==fptools== gmake all --no-print-directory -r; in /usr/local/pub-bkb/ghc/fptools/hslibs/tools/DrIFT ../../../ghc/driver/ghc-inplace -o DrIFT -cpp -fglasgow-exts -package text DataP.o DrIFT.o Literate.o Pretty.o StandardRules.o ChaseImports.o CommandP.o DigitToInt.o ParseLib2.o PreludData.o RuleUtils.o UserRuleBinary.o UserRuleXml.o UserRules.o ld: fatal: file DrIFT: cannot open file: Is a directory collect2: ld returned 1 exit status gmake[3]: *** [DrIFT] Error 1
Unhelpful Haskell error messages
I think test9: fatal error: resurrectThreads: thread blocked in a strange way qualifies.
The impossible has happened again
This is with a version of GHC downloaded and compiled in the morning of 31st March. I'm attaching the HtmlFrame.hi/ HtmlFrame.hs; let me know if you want more. The .hi file would have been generated with the same compiler options you see here. /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c Html.hs -syslib concurrent -syslib data -syslib net -syslib posix -syslib text -syslib util -syslib lang -i.:top/util:top/concurrency:top/reactor:top/htk:top/htk/resources:top/htk/canvasitems:top/htk/kernel:top/htk/containers:top/htk/menuitems:top/htk/toolkit:top/htk/components:top/htk/toplevel:top/htk/widgets:top/htk/devices:top/htk/textitems:top/davinci:top/www:top/tools -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -hi-diffs -fvia-C -I/usr/local/pub-bkb/ghc/ghc-latest/lib/includes -H25M -K5M -recomp -O -O2-for-C panic! (the `impossible' happened): IdInfo parse failed zdwtpl ./HtmlFrame.hi:153 Interface file parse error; on input ` 0 ' Please report it as a compiler bug to [EMAIL PROTECTED] HtmlFrame.hs HtmlFrame.hi
Re: ghc/rts/RtsUtils.c
George Russell wrote: George Russell wrote: I'm sure I've had problems with Sun's systime functions before . . . ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2 -optc-fomit-frame-pointer-c RtsUtils.c -o RtsUtils.o RtsUtils.c:232: warning: no previous prototype for `msTime' RtsUtils.c:243: storage size of `tv' isn't known RtsUtils.c:245: warning: implicit declaration of function `gettimeofday' RtsUtils.c:243: warning: unused variable `tv' gmake[2]: *** [RtsUtils.o] Error 1 gmake[1]: *** [all] Error 1 gmake: *** [all] Error 1 I am still getting this bug. Any progress? OK, this is why I think it's happening. Stg.h (#include'd via Rts.h) sets the macro _POSIX_C_SOURCE. This prevents Sparc/Solaris' sys/time.h defining "struct timeval" and gettimeofday. (Indeed if I add the line #undef _POSIX_C_SOURCE to RtsUtils.c just before include sys/time.h it works again). I presume your configure script does not include Stg.h so it gets HAVE_GETTIMEOFDAY wrong.
Re: ghc/rts/RtsUtils.c
George Russell wrote: I'm sure I've had problems with Sun's systime functions before . . . ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2 -optc-fomit-frame-pointer-c RtsUtils.c -o RtsUtils.o RtsUtils.c:232: warning: no previous prototype for `msTime' RtsUtils.c:243: storage size of `tv' isn't known RtsUtils.c:245: warning: implicit declaration of function `gettimeofday' RtsUtils.c:243: warning: unused variable `tv' gmake[2]: *** [RtsUtils.o] Error 1 gmake[1]: *** [all] Error 1 gmake: *** [all] Error 1 I am still getting this bug. Any progress?
Profiling.h in the attic
==fptools== gmake boot --no-print-directory -r; in /usr/local/pub-bkb/ghc/fptools/ghc/includes gmake[2]: *** No rule to make target `Profiling.h', needed by `mkNativeHdr.o'. Stop. gmake[1]: *** [boot] Error 1 gmake: *** [boot] Error 1 /usr/local/pub-bkb/ghc/fptools cd ghc/includes /usr/local/pub-bkb/ghc/fptools/ghc/includes cvs status Profiling.h === File: no file Profiling.h Status: Up-to-date Working revision:No entry for Profiling.h Repository revision: 1.10/cvs/fptools/ghc/includes/Attic/Profiling.h,v
Re: Profiling.h in the attic
Simon Marlow wrote: Yes, I removed Profiling.h from ghc/includes and added it to ghc/rts. You might need to 'make boot' Actually it was gmake boot that was falling over. However I seem to have fixed that by doing "gmake depend" in ghc/includes (the .depend file contained the obsolete reference to Profiling.h), though I don't yet understand exactly what's going on. (Surely regenerating .depend is gmake boot's job??)
ghc/rts/RtsUtils.c
I'm sure I've had problems with Sun's systime functions before . . . ../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2 -optc-fomit-frame-pointer-c RtsUtils.c -o RtsUtils.o RtsUtils.c:232: warning: no previous prototype for `msTime' RtsUtils.c:243: storage size of `tv' isn't known RtsUtils.c:245: warning: implicit declaration of function `gettimeofday' RtsUtils.c:243: warning: unused variable `tv' gmake[2]: *** [RtsUtils.o] Error 1 gmake[1]: *** [all] Error 1 gmake: *** [all] Error 1
rename/ParseIface doesn't compile with -O
With GHC compiled from the night-before-last's CVS, compiling last-night's CVS, I get ==fptools== gmake all --no-print-directory -r; in /usr/local/pub-bkb/ghc/fptools/ghc/compiler /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -K5m -H80m -optCrts-M90m -Onot -H45m -K2m -fno-warn-incomplete-patterns -H40m -O -c rename/ParseIface.hs -o rename/ParseIface.o -osuf o hsc: fatal error: scavenge gmake[2]: *** [rename/ParseIface.o] Error 1
Re: system.c doesn't compile
I had this bug on Monday, but it's been fixed. Download the binary release (4.06) and try again with the latest sources.
ghc/lib/cbits/system.c doesn't compile
==fptools== gmake all --no-print-directory -r; in /usr/local/pub-bkb/ghc/fptools/ghc/lib/std/cbits ../../../driver/ghc-inplace -O -I../../../includes -I../../../rts -Wall -static-c system.c -o system.o system.c:71: warning: implicit declaration of function `vfork' system.c:83: variable `tv_null' has initializer but incomplete type system.c:83: warning: excess elements in struct initializer system.c:83: warning: (near initialization for `tv_null') system.c:83: warning: excess elements in struct initializer system.c:83: warning: (near initialization for `tv_null') system.c:83: storage size of `tv_null' isn't known system.c:84: storage size of `itv' isn't known system.c:87: warning: implicit declaration of function `setitimer' system.c:87: `ITIMER_REAL' undeclared (first use in this function) system.c:87: (Each undeclared identifier is reported only once system.c:87: for each function it appears in.) system.c:88: `ITIMER_VIRTUAL' undeclared (first use in this function) system.c:89: `ITIMER_PROF' undeclared (first use in this function) gmake[4]: *** [system.o] Error 1 gmake[3]: *** [all] Error 1 gmake[2]: *** [all] Error 1 gmake[1]: *** [all] Error 1 gmake: *** [all] Error 1
Re: ghc/compiler/utils/FastString.lhs won't compile (suspect version skew)
Er, has this bug report been lost? It doesn't seem to have been dealt with . . . George Russell wrote: ==fptools== gmake all --no-print-directory -r; in /usr/local/pub-bkb/ghc/fptools/ghc/compiler /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -H40m -Onot -c utils/FastString.lhs -o utils/FastString.o -osuf o FastString.lhs:93: Module `PrelArr' does not export `STArray(..)' FastString.lhs:93: Module `PrelArr' does not export `newSTArray' FastString.lhs:94: Module `IOExts' does not export `hPutBuf' FastString.lhs:94: Module `IOExts' does not export `hPutBufBA' Compilation had errors
Re: ghc/compiler/utils/FastString.lhs won't compile (suspect version skew)
Sven Panne wrote: What GHC version are you using for compilation? Due to some library reorganization you have to build 4.07 with 4.06, most of the 4.07 versions from CVS won't compile the current sources. Ah I see. I was indeed building it from 4.07. I'll try going back to 4.06.
Re: ghc/compiler/utils/FastString.lhs won't compile (suspect version skew)
Oh, I forgot to say. This is compiling the latest (as of the weekend) GHC with GHC compiled from CVS on 10th March.
Re: gmp configure (fwd)
Reuben Thomas wrote: I already came across this, and Sigbjørn sent me a fix, which should soon be in CVS. Just in case it's not, it follows below. I found that I also needed to change rts/gmp/configure.in so that the first call to AC_INIT occurred after the setting of the three variables just below it. anoncvs version still doesn't work, though at least it doesn't loop forever. After regenerating the new gmp configure file I get: gmake[1]: Entering directory `/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp' /bin/sh ./config.status configure: error: --norecursion: invalid option; use --help to show usage
Re: gmp configure (fwd)
Simon Marlow wrote: What version of autoconf is this, just out of interest? autoconf --version Autoconf version 2.13 Oh no, don't tell me I've got to install a private copy of yet another bit of software to compile GHC . . .
Re: gmp configure (fwd)
Simon Marlow wrote: It builds fine for me here with autoconf 2.13 on Solaris. Perhaps you have some old configure files lying around in ghc/rts/gmp/*. Try blowing away your gmp subtree and starting again. After deleting the whole of ghc, rerunning autoconf several times (why isn't this done by gmake -f Makefile.config?), and ./configure several more times I can now do gmake clean again.
Re: gmp configure (fwd)
Reuben Thomas wrote:
I already came across this, and Sigbjørn sent me a fix, which should soon
be in CVS. Just in case it's not, it follows below. I found that I also
needed to change rts/gmp/configure.in so that the first call to AC_INIT
occurred after the setting of the three variables just below it.
Thanks.
On the subject of bugs for which fixes are found which don't seem to make
it into the CVS repository for a while, why exactly does RtsUtil.h
still contain the line
extern StgStablePtr errorHandler;
when "errorHandler" isn't actually defined anywhere? ("extern" of course doesn't
define a symbol, it just promises that a definition can be found somewhere else.)
Last time I tried this resulted in linking falling over for me.
threadWaitRead on a closed Fd - - -
causes the entire program to crash. (Not just the thread that is doing the threadWaitRead.) Is this not a little drastic? To run the attached code use ghc -syslib posix -syslib concurrent -cpp ThreadWaitFail.hs -o TWF ./TWF ThreadWaitFail.hs
Re: FastString.lhs:629: parse error on input `#'
Marc van Dongen wrote: Hi again, When trying to build ghc from cvs (cvs update, make clean, etc) I got: ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/compiler /usr/local/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -c utils/FastString.lhs -o utils/FastString.o -osuf o FastString.lhs:629: parse error on input `#' Compilation had errors make[2]: *** [utils/FastString.o] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 Odd, because I get (from the anon-cvs repository) /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -H40m -Onot -c utils/FastString.lhs -o utils/FastString.o -osuf o FastString.lhs:632: Couldn't match `ByteArray Int' against `MutableByteArray RealWorld Int' Expected type: ByteArray Int Inferred type: MutableByteArray RealWorld Int In the second argument of `hPutBufBA', namely `mba' In a do statement: hPutBufBA handle mba (I# l#) Compilation had errors "cvs status" tells me that my copy of FastString.lhs is up-to-date.
