Re: [GHC] #1212: Add IPv6 support to network library
#1212: Add IPv6 support to network library +--- Reporter: [EMAIL PROTECTED] | Owner: Type: proposal| Status: new Priority: normal | Milestone: Not GHC Component: libraries/network |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by guest): darcs repo here: darcs get --partial http://darcs.serpentine.com/network6 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1212 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1263: Implement Data, Typeable instances for TH.Syntax tree
#1263: Implement Data, Typeable instances for TH.Syntax tree -+-- Reporter: greenrd | Owner: greenrd Type: feature request | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 6.6 Severity: minor |Keywords: Difficulty: Unknown |Testcase: Architecture: Multiple | Os: Multiple -+-- I am testing a patch for this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1263 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1241: Functional dependency Coverage Condition is lifted, and should not be
#1241: Functional dependency Coverage Condition is lifted, and should not be -+-- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by simonpj): * milestone: _|_ = 6.8 * summary: Functional dependencies not checked. = Functional dependency Coverage Condition is lifted, and should not be Comment: See also this Haskell Cafe thread [http://www.haskell.org/pipermail/haskell-cafe/2007-March/023916.html A question about functional dependencies and existential quantification] The issue is identical: GHC with `-fallow-undecidable-instances` is lifting the Coverage Condition, and probably should not do so. Question: if we did '''not''' lift the Coverage Condition, would anyone mind? Or perhaps lifting it deserves its own flag. Or we could combine it with the already-scary flag `-fallow-incoherent-instances`, which also has the same loss-of-confluence property. Opinions? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1241 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1241: Functional dependency Coverage Condition is lifted, and should not be
#1241: Functional dependency Coverage Condition is lifted, and should not be -+-- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Comment (by Stefan O'Rear [EMAIL PROTECTED]): Last I checked, the Coverage Condition is incompatible with MTL, so we *really* shouldn't make the CC mandatory. (I'm not against a general refactor of -fallow-undecidable-instances into smaller, more self- documenting pieces, as long as the functionality is still there) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1241 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1264: darcs repo corrupted?
#1264: darcs repo corrupted?
-+--
Reporter: greenrd | Owner:
Type: bug | Status: new
Priority: high | Milestone:
Component: Template Haskell | Version: 6.6
Severity: major |Keywords:
Difficulty: Unknown |Testcase:
Architecture: x86_64 (amd64)| Os: Linux
-+--
I get this error, reproducably:
{{{
bash-3.00$ darcs get http://darcs.haskell.org/ghc-6.6/packages/template-
haskell/
Copying patch 12 of 42...
darcs failed: Failed to download URL
http://darcs.haskell.org/ghc-6.6/packages/template-haskell/_darcs/patches
/20050812104945-f996e-044e4c18be42b117efeef686e23e0ce0bf20ed02.gz
libcurl: HTTP error (404?)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1264
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci question
Hello, This is a bit lame but I don't know where to find the information... I am wondering if ghci is OK to use with threads now. It seems to work but I have written down in some of my source code that a certain function won't work under ghci because it uses threads and I can't remember what the symptom of the problem was. Many thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1265: Template Haskell fail Messages not Getting Through
#1265: Template Haskell fail Messages not Getting Through
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell | Version: 6.6
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
-+--
There is (I believe) a mistake in GHC's template Haskell implementation
int the way the fail member is handled. The error messages get eaten and
replaced with a cryptic reference to an IOEnv failure. For example (at
the ghci -fth prompt):
{{{
Prelude let doit = fail Code not written yet ::
Language.Haskell.TH.ExpQ
Loading package template-haskell ... linking ... done.
Prelude $(doit)
interactive:1:2:
Exception when trying to run compile-time code:
user error (IOEnv failure)
Code: doit
In the expression: $[splice]doit
In the definition of `it': it = $[splice]doit
Prelude
}}}
The problem seems to be that GHC runs the template code in the IOEnv monad
(compiler/typecheck/TcSplite.lhs) whose fail implementation
(compiler/utils/IOEnv.hs) eats its argument and instead raises userError
IOEnv failure.
I put a patch together for this, and will submit it soon (i.e., as soon as
I finish reading the pages on how to do so). With the patch, the above
examples becomes:
{{{
Prelude let doit = fail Code not written yet ::
Language.Haskell.TH.ExpQ
Loading package template-haskell ... linking ... done.
Prelude $(doit)
interactive:1:2: Code not written yet
Prelude
}}}
This is achieved through changing the fail implementation for the Q monad
to first log the message with report before passing control through the
fail member of the underlying Quasi instance (IOEnv in this case) and
changing the exception handling code around the running of the template
code to gracefully handle exceptions raised in such a manner (i.e., print
out the logged message).
It is a bit hackish, but it was the only way I could see to do this with
out changing the fail implementation for IOEnv (I assume it was written
the way it is for a reason -- possibly to avoid spamming the user with
messages regarding compiler problems -- although it does seems strange) or
introducing an additional function into the Q monad (such as giveUp from
Notes on Template Haskell Version 2).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1265
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci question
On Wed, 2007-04-04 at 00:01 +0100, Frederik Eaton wrote: Hello, This is a bit lame but I don't know where to find the information... I am wondering if ghci is OK to use with threads now. It seems to work but I have written down in some of my source code that a certain function won't work under ghci because it uses threads and I can't remember what the symptom of the problem was. Some Haskell libs that bind to foreign thread-unsafe libraries cannot safely be used with multiple Haskell threads in the threaded runtime system (and of course ghhci uses the threaded rts these days). In particular GUI libs are affected by this. For example you can use Gtk2Hs in GHCi, but if you forkIO and call GUI stuff from multiple threads... boom (or more likely an xlib error or segfault). There's info on the Gtk2Hs site about how to do it safely. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
