Re: thread blocked indefinitely
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> > I'm now `GHC.Conc.forkProcess`ing only from the initial
> > thread, and all
> > seems well. Thanks for the suggestion!
> >
> > Any idea when `forkProcess` might get fixed? Don't hurry on my
> > account; I'm just curious.
>
> There's a comment in the code from Sigbjorn who tried to fix it and was
> unsuccessful, so it's probably a non-trivial fix. I'll take a look next
> time I'm in the area, unless it's a complete show-stopper for anyone.
>
> Cheers,
> Simon
I was just reading through old e-mail and saw this. The state of
affairs described here sounds like a nasty bug waiting to bite.
Would it be better to change forkProcess to detect whether it's being
called from the initial thread, and give some sort of error ("GHC
internal error: forkProcess must only be called from the initial
thread") if not?
Carl Witty
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GetMBlock: misaligned block
"Simon Marlow" <[EMAIL PROTECTED]> writes: > The problem is that GHC is asking for memory at a particular address > (0x5000) and the kernel is returning memory elsewhere that doesn't > satisfy our aligment constraints (1M aligned). We don't particularly > care where we get memory from, but it must be properly aligned. Can you just mmap more memory than you need (an extra megabyte) and unmap the portions that aren't correctly aligned? (To avoid the overhead, you could do this only when a correctly-sized mmap gave you unaligned memory.) Carl Witty ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug in ghc, hugs, or green-card
Simon Marlow <[EMAIL PROTECTED]> writes: > > So, the question is, "Should readFile on a directory throw an IO > > error?" If so, then there is a bug in Hugs; if not, there is a bug > > (or at least a severe misfeature) in Green Card (and a bug in the ghc > > libraries, which do throw an IO error). > > I rather think that openning a directory fail, because attempting to perform > any other operations on that directory (such as reading from it) will fail > anyway, and we have the Directory module for dealing with directories. The function readFile takes a filename and returns the contents of that file; there's no seperate "open" to fail. Carl Witty
bug in ghc, hugs, or green-card
As you can tell from the title, I'm not sure exactly where the
responsibility for this bug lies.
The symptom: green-card (running under hugs, with runhugs) fails when
running in a project directory built with "ghc -split-objs".
The cause: Green Card does import chasing; that is, when processing a
file containing (say) "import GL_DIS", Green Card will try to find and
process a corresponding Green Card file. It searches first for a
file named "GL_DIS"; if that fails, it will search for "GL_DIS.gc".
If this is in a directory which is being built using ghc with the
"-split-objs" option, then there will be a directory named "GL_DIS".
Consider the following program:
> module Main where
>
> main = catch (do v <- readFile "/etc"; putStrLn ("Success: " ++ v))
> (\_ -> putStrLn "Failed!")
When run under Hugs, this prints "Success: ". When compiled with ghc,
this prints "Failed!".
This difference means that if Green Card is run under Hugs, and it
tries to load the Green Card file corresponding to "import GL_DIS",
and there is a directory named "GL_DIS", green-card will believe that
this is an empty Green Card file, process it (with no effect, because
it's empty; and with no warning or error, because it's present), and
subsequently fail.
So, the question is, "Should readFile on a directory throw an IO
error?" If so, then there is a bug in Hugs; if not, there is a bug
(or at least a severe misfeature) in Green Card (and a bug in the ghc
libraries, which do throw an IO error).
I couldn't find a definitive answer to this question in the Haskell 98
report or library report (although I didn't spend too much time
looking). My personal opinion is that it would be better if an IO
error were thrown, so that Hugs should be changed; but that Green Card
should not depend on this, so that the line:
default_suffixes = ["","gc"]
in GreenCard.lhs should be changed to
default_suffixes = ["gc"]
or
default_suffixes = ["gc",""]
In the meantime, a sufficient workaround is to add "--suffix=gc" to
the green-card command line.
Carl Witty
typo in CVS hslibs/lang/doc/IArray.sgml
The file IArray.sgml in the latest CVS says "additiona" instead of "addition". Carl Witty [EMAIL PROTECTED]
typo in CVS users_guide/4-07-notes.sgml
The file 4-07-notes.sgml in the latest CVS mentions http://www.cse.ogi.ed/~jlewis/implicit.ps.gz That should be .edu, not .ed . Carl Witty [EMAIL PROTECTED]
tiny bug in docs/libraries/Weak.sgml
Whoever did the global search-and-replace of "finalise" by "finalize" missed the word form "finalisation". Carl Witty [EMAIL PROTECTED]
Re: kind mismatch ($)
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> > One additional comment. I frequently use quotes (') as suffixes
> > for identifier and type names. As can be seen above ghc loves adding
> > quotes (` and ') around parts of its messages. This becomes *very*
> > confusing when the last part of the message consists of an
> > identifier suffixed by a one or more quote symbols.
>
> I've noticed this too, but the trouble is that if you leave the quotes
> out then identifiers tend to get lost in the text. Better ideas welcome.
Well, you could always use different quoting characters. Rather than
`Int'', you could use any of:
"Int'"
(Int')
[Int']
{Int'}
<< Int' >>
` Int' '
etc.
Carl Witty
[EMAIL PROTECTED]
Re: ghc-2.10 fails on Red Hat Linux 5.0?
Antony Bowers <[EMAIL PROTECTED]> writes: > Does ghc (any version) work on Linux with glibc-2 (libc6)? It works for me. I installed the 2.10 binary release and used it to compile 3.01 from source; both 2.10 (which is linked with libc5) and 3.01 (which is linked with libc6) can compile the following simple program: > main = putStr "Hello, world!\n" to get a result which is linked with libc6 and works correctly. I'm using gcc 2.7.2.3 and a version of libc6 which claims to be GNU libc 2.0.7pre1; I'm working on a Debian system which is running a fairly current version of the soon-to-be-released Debian 2.0. (I had a little bit of trouble getting GHC itself to compile under libc6; I'm working with Simon Marlow to get ghc-current to compile.) Carl Witty [EMAIL PROTECTED]
Re: problems compiling ghc 3.01 for linux
Simon Marlow <[EMAIL PROTECTED]> writes: > Thanks Carl. Several people have run into this before (check the list > archives), but we still don't have any recent Linux installations here > to test out a proper fix on. That's why I said: > Let me know if you have any questions, or want me to test patches. (I am keeping up with ghc-current, using anonymous CVS, so if you just check in a proposed fix and let me know I can tell you if it compiles.) Carl Witty [EMAIL PROTECTED]
problems compiling ghc 3.01 for linux
I ran into minor problems compiling GHC 3.01 on my up-to-date Debian Linux machine. I'm pretty sure that the problem is that I'm using Libc 6 (GNU libc 2). Basically, several BSD extensions (in particular, the types caddr_t and u_long, and the tm_zone and tm_gmtoff members of struct tm) are not available when _POSIX_SOURCE is defined; I also had to define _BSD_SOURCE to include them. (One problem is that configure tests for feature availability with no _*_SOURCE defines; defining _POSIX_SOURCE then disables features that configure detected as present.) Here's the patch I made: --- stgdefs.h~ Sun Oct 5 13:34:00 1997 +++ stgdefs.h Sun May 10 15:52:25 1998 @@ -53,10 +53,12 @@ #ifdef NON_POSIX_SOURCE #undef _POSIX_SOURCE #undef _POSIX_C_SOURCE +#define _BSD_SOURCE #else # ifndef aix_TARGET_OS /* already defined on aix */ #define _POSIX_SOURCE 1 +#define _BSD_SOURCE 1 # endif #ifndef irix_TARGET_OS #define _POSIX_C_SOURCE 199301L While this works for me, I wouldn't suggest that you apply it blindly; I don't know if it might break other places. Ideally, it would be conditioned on having GNU libc 2.0 (Linux libc 6); I don't know how to check for that here. Random information about my system: Linux gemini 2.0.29 #4 Thu Oct 23 00:34:55 PDT 1997 i686 unknown gcc version 2.7.2.3 Let me know if you have any questions, or want me to test patches. Carl Witty [EMAIL PROTECTED]
Re: Is this a bug?
Marc van Dongen= <[EMAIL PROTECTED]> writes: > [snip] > > : > > module Main( main ) where > : > > import List( genericLength ) > : > > main = putStr (show integral) >> > : > >putStr "\n">> > : > >return () > : > > where integral = genericLength [] > > [snip] > > : This is a legal Haskell program. The (ambiguous) type of `integral' is > : (Num a => a), but Haskell disambiguates numeric expressions with the > : help of `default' declarations. As per Haskell 1.4 (see section 4.3.4 > > Thanks for the pointer. > > : of the report), this means resolving `integral' to be a value of type > : Int. > > I think this ``resolving'' may lead to unwanted results. It took > me quite some time to discover that Integral was resolved to Int > in some program I had. Is there a possibility of generating a warning > message whenever programs like the one above have to be disambiguated? > Maybe a compiler-switch to turn these warning messages on and off? If you really don't like the default processing, you could use default () to disable it totally. Carl Witty [EMAIL PROTECTED]
bug in ghc 2.08 openFile
In ghc 2.08 running on Linux, if you try to do an openFile for writing
on a dangling symlink (a symlink that does not point at an existing
file), the openFile hangs in a tight loop. strace reveals the
following system calls:
open("Parser.hs", O_WRONLY|O_NOCTTY)= -1 ENOENT (No such file or directory)
open("Parser.hs", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY, 0666) = -1 EEXIST (File exists)
repeated over and over again forever.
Carl Witty
[EMAIL PROTECTED]
happy-1.3 (from ghc-2.07) bug & question
First, the question.
This version of happy (according to the CHANGES file, and according to
stuff I've seen on the mailing lists) should have the appropriate
hooks to support the Haskell layout rule (i.e., the error recovery and
the monad threading through the lexer). Do you have any examples of
parsers supporting Haskell layout? (It doesn't have to be a real
Haskell parser; I just want to see how to support Haskell layout.)
Second, the bug report.
I assume that getting a happy-generated parser to report:
Program error: Internal Happy error
implies a bug in happy. Here's a parser file which can create such an
error message (greatly stripped down from my original):
cut here
{
module ParseTP where
}
%name parsetp
%tokentype { Token }
%token
module { TokenModule }
id { TokenVar }
%%
Module :: { AModule }
: module id { Module }
| error { Module }
{
data AModule = Module
happyError _ = (Module)
data Token
= TokenModule
| TokenVar
}
cut here
Save the above in a file "ParseTP.y".
I found this bug with Hugs, so I'm giving a Hugs-specific reproduction
scenario; I don't think the bug itself is Hugs-specific, though.
To reproduce:
1) run "happy ParseTP.y"
2) run hugs
3) in hugs, type ":load ParseTP.hs"
4) in hugs, type "parsetp [TokenModule]"
Carl Witty
[EMAIL PROTECTED]
printing the ghc source?
I'm interested in learning how GHC works. To this end, I'd like to print out large chunks of its source and pore over them. I would have hoped that the fact that GHC is written in the "literate programming" style would make it easy to get high-quality printouts; however, it doesn't seem to work. When I run lit2latex over ghc/compiler/*/*.lhs, I get many errors which say: fatal flex scanner internal error--end of buffer missed lit2latex: error(s) from prefilter pipe and the relevant source file is ignored. What I really want is a way to get a fairly good-looking DVI file consisting of the entire GHC source; in an ideal world, this would have page-numbered cross references in the margin and a good index. (I would then print out selected pages from this huge DVI file.) Even without these refinements, it seems like I ought to be able to do better than printing out the source (including the "literate" comments) in a fixed-width font. Carl Witty [EMAIL PROTECTED]
documentation suggestion (-cpp and "string gaps")
The documentation says: A small word of warning: `-cpp' is not friendly to "string gaps". (In other words, strings such as the following: strmod = "\ \ p \ \ " don't work with '-cpp'; /usr/bin/cpp elides the backslash-newline pairs.) I inadvertently discovered that -cpp can work with string gaps (at least on my system) if you add an extra space to the end of the line, after the backslash. This makes no difference to Haskell, but cpp leaves backslash-space pairs alone. I don't know if other versions of cpp act like this; if so, perhaps a note to this effect should be added to the documentation. This is on: Linux bogomips 2.0.27 #2 Fri Jan 24 02:28:34 PST 1997 i686 with: GNU CPP version 2.7.2.1 (i386 Linux/ELF) Carl Witty [EMAIL PROTECTED]
