Ralf Laemmel | 3 Nov 12:09 2003
Picon
Picon

strange difference between old and hierachical module names

Hi,

I am trying to compile some modules with old imports
such "import MonadFix". These modules compile fine
with GHC 6.0 latest RPM, and also on CVS source tree
6.1 somewhere from july.

However, the file below does NOT get through with GHC HEAD.
I get ...

> Compiling Foo              ( Foo.hs, interpreted )
>  
> Foo.hs:13: `mfix' is not a (visible) method of class `MonadFix'
> Failed, modules loaded: none.

If I use the new "import Control.Monad.Fix" instead of MonadFix,
everything works fine. This is a bit strange because
for most old imports there is no such problem.
Seems to be something special going on with MonadFix.

Thanks,
Ralf

----------------------------------------------------------------

module Foo where

-- Does not work 6.3 as 2 Nov 2003
import MonadFix
-- Works with 6.3
(Continue reading)

SourceForge.net | 3 Nov 14:04 2003
Picon
Picon

[ ghc-Bugs-832920 ] Missing # from #-} elicits utterly opaque error

Bugs item #832920, was opened at 2003-10-30 09:17
Message generated for change (Comment added) made by simonmar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=832920&group_id=8032

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing # from #-} elicits utterly opaque error

Initial Comment:
Consider this in Foo.hs

	module Foo where
	{-# LINE 1 "Baz.hs" -}

Notice the missing #

GHC 6.3 (HEAD, 30 Oct 2003) gives the message:

       Baz.hs:0: lexical error

This is extremely opaque; after all, the error is in Foo.  
And it would help to know the offending token.

Simon PJ 
(Continue reading)

Simon Peyton-Jones | 3 Nov 16:29 2003
Picon

RE: strange difference between old and hierachical module names

Good bug report.  Now fixed in the HEAD>

Simon

| -----Original Message-----
| From: glasgow-haskell-bugs-bounces <at> haskell.org
[mailto:glasgow-haskell-bugs-
| bounces <at> haskell.org] On Behalf Of Ralf Laemmel
| Sent: 03 November 2003 11:10
| To: glasgow-haskell-bugs <at> haskell.org
| Subject: strange difference between old and hierachical module names
| 
| Hi,
| 
| I am trying to compile some modules with old imports
| such "import MonadFix". These modules compile fine
| with GHC 6.0 latest RPM, and also on CVS source tree
| 6.1 somewhere from july.
| 
| However, the file below does NOT get through with GHC HEAD.
| I get ...
| 
| > Compiling Foo              ( Foo.hs, interpreted )
| >
| > Foo.hs:13: `mfix' is not a (visible) method of class `MonadFix'
| > Failed, modules loaded: none.
| 
| If I use the new "import Control.Monad.Fix" instead of MonadFix,
| everything works fine. This is a bit strange because
| for most old imports there is no such problem.
(Continue reading)

Simon Marlow | 3 Nov 18:26 2003
Picon

RE: Slight doc typos


> Section 7.4 of the User Guide (or doc source
> ghc/docs/user_guide/glasgow_exts.sgml) references "Haskell 
> 1.4" several
> times when "Haskell 98" would perhaps be more appropriate.
> 
> Also, section 7.4.10 ("Arbitrary-rank polymorphism", same sgml source)
> has an example with functions f1, g1, f2, g2 and f3, but a few
> paragraphs later a non-existent g3 is mentioned twice.

Thanks; fixed.

Simon
Ralf.Laemmel | 3 Nov 20:18 2003
Picon
Picon

RE: strange difference between old and hierachical module names

SPJ wrote:

> Good bug report.  Now fixed in the HEAD>

Thanks, but there is now a more serious problem;
could be a consequence of the fix.
See below a little test file Main.hs and the
ghci session for this file using HEAD updated
just after your fix.

Thanks,
Ralf

[ralf <at> localhost test]$ more Main.hs
module Main where

main = print True

[ralf <at> localhost test]$
/home/ralf/cvsprojects/cvs.haskell.org/fptools/ghc/compiler/stage2/ghc-inplace
--interactive -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances -package data Main.hs
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.3, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base ... linking ... done.
Loading package haskell98 ... linking ... done.
(Continue reading)

Simon Marlow | 4 Nov 10:34 2003
Picon

RE: Bug in 6.0.1


> When I load HToolkit 1.2 into GHC 6.0.1 I get the following:
> 
> --8<----
> 
> mettw > ghci -package gio  
>    ___         ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |      GHC Interactive, version 6.0.1, 
> for Haskell 98.
> / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
> \____/\/ /_/\____/|_|      Type :? for help.
> 
> Loading package port ... linking ... 
> /usr/lib/ghc-6.0.1/HSport.o: unknown symbol `__stginit_GHCziWord_'
> ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
>         can't load package `port'

Looks like the port package is missing a dependency on 'base'.

Cheers,
	Simon
Simon Peyton-Jones | 5 Nov 12:40 2003
Picon

RE: strange difference between old and hierachical module names

Ah yes.  That's been there since I did the Big Commit (nothing to do
with the recent fix).  Thanks for finding it -- now fixed.

Simon

| -----Original Message-----
| From: glasgow-haskell-bugs-bounces <at> haskell.org
[mailto:glasgow-haskell-bugs-
| bounces <at> haskell.org] On Behalf Of Ralf.Laemmel <at> cwi.nl
| Sent: 03 November 2003 19:18
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-bugs <at> haskell.org
| Subject: RE: strange difference between old and hierachical module
names
| 
| SPJ wrote:
| 
| > Good bug report.  Now fixed in the HEAD>
| 
| Thanks, but there is now a more serious problem;
| could be a consequence of the fix.
| See below a little test file Main.hs and the
| ghci session for this file using HEAD updated
| just after your fix.
| 
| Thanks,
| Ralf
| 
| 
| [ralf <at> localhost test]$ more Main.hs
(Continue reading)

Simon Marlow | 5 Nov 16:58 2003
Picon

RE: 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.

Sorry for the delay in replying.

I think this is "expected behaviour" (or possibly a known bug).  You can
demonstrate it like this:

main = do
  forkIO (getChar >> return ())
  yield
  hClose stdin

The thread reading from the handle has a lock on it, so that hClose has
to wait before it can gain access to the handle to close it.

What would you like to happen in this case?  I guess getChar could be
given an exception if the handle was closed underneath it.  The problem
is that releasing the lock in the middle of getChar while it waits for
(Continue reading)

SourceForge.net | 6 Nov 11:32 2003
Picon
Picon

[ ghc-Bugs-821047 ] ghci --help produces help for ghc

Bugs item #821047, was opened at 2003-10-10 08:09
Message generated for change (Settings changed) made by simonmar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=821047&group_id=8032

Category: Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Simon Marlow (simonmar)
Summary: ghci --help produces help for ghc

Initial Comment:
The summary says it all.  Submitted by Norman Ramsey

----------------------------------------------------------------------

>Comment By: Simon Marlow (simonmar)
Date: 2003-11-06 10:32

Message:
Logged In: YES 
user_id=48280

Fixed, thanks.

----------------------------------------------------------------------

(Continue reading)

George Russell | 6 Nov 12:49 2003
Picon

Re: hClose non-terminating

Simon Marlow wrote (snipped):

> The thread reading from the handle has a lock on it, so that hClose has
> to wait before it can gain access to the handle to close it.

OK, so it isn't a bug but expected behaviour that if you have one thread
doing hGetChar on a handle, an attempt to close the handle in another thread
will not terminate.  But it seems to me at least a gotcha, which should
be documented somewhere.  The trouble is that (a) it's quite common to have
a thread somewhere dedicated to monitoring the output of some handle;
(b) I at least have up to now assumed that hClose, like the C low-level (f)close
functions, is something that basically can't fail or block, and so you never need
to worry about calling it to clean-up.

> What would you like to happen in this case?  I guess getChar could be
> given an exception if the handle was closed underneath it.  The problem
> is that releasing the lock in the middle of getChar while it waits for
> input is quite awkward to implement, and doing it in the middle of
> getLine is even worse.

I think raising an exception during getChar would be best.

However if not, what then?  It seems as if hClose has two tasks (1) flushing
any remaining output; (2) freeing any remaining datastructures, fds required for
reading or writing.  (1) can be done immediately.  Perhaps if (2) is impossible
to do right now because a getChar is sitting on the lock, you could fork a thread
to do it?  After all it's not so important if it doesn't get done at all.

> My feeling is that this would be a pain to fix.  Can you work around it?

(Continue reading)


Gmane