[GHC] #4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas
#4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas
-+--
Reporter: dreixel | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Consider the following two modules:
{{{
module Test1 where
{-# INLINE f1 #-}
f1 :: (Num a) = a - a
f1 a = a
module Test2 where
import Test1
{-# SPECIALIZE f1 :: Int - Int #-}
}}}
Compiling with ghc --make Test2 gives
{{{
You cannot SPECIALISE `f1'
because its definition has no INLINE/INLINABLE pragma
}}}
But 'f1' clearly has an INLINE pragma. Adding the -O flag solves the
problem. I think the error message given when compiling without
optimization could be improved, perhaps mentioning that inlining pragmas
are ignored when compiling without optimization.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4799
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] #3843: Merge plugins into HEAD
#3843: Merge plugins into HEAD -+-- Reporter: dreixel |Owner: simonpj Type: task | Status: new Priority: normal|Milestone: 7.0.1 Component: Compiler | Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): The second patch ghc_plugins_support_2010_11_19.2.dpatch is just a comment update and a warning fix. Implemented by Austin Seipp. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3843#comment:11 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] #4481: Functor, Pointed, Applicative, Monad
#4481: Functor, Pointed, Applicative, Monad -+-- Reporter: gidyn | Owner: Type: proposal| Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base |Version: 6.12.3 Resolution: invalid | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by gidyn): * status: new = closed * resolution: = invalid -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4481#comment:6 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] #4481: Functor, Pointed, Applicative, Monad
#4481: Functor, Pointed, Applicative, Monad -+-- Reporter: gidyn | Owner: Type: proposal| Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base |Version: 6.12.3 Resolution: invalid | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by gidyn): * cc: gid...@… (removed) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4481#comment:7 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] #4800: Memory Leak when Compiling qtHaskell
#4800: Memory Leak when Compiling qtHaskell --+- Reporter: gidyn | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version: 6.12.3 | Keywords: Testcase: developer.berlios.de/project/showfiles.php?group_id=10072 | Blockedby: Os: Windows| Blocking: Architecture: x86_64 (amd64) | Failure: Compile-time crash --+- I get an out-of-memory error about two thirds of the way through building qtHaskell (latest version, 1.1.4). If I start again, the remaining modules are compiled successfully, although GHC's memory usage creeps up to about 1.5Gb by the time it's finished. This is on Win7 x64 with 4Gb RAM. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4800 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] #4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas
#4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas
-+--
Reporter: dreixel |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonpj):
Good point. How about this?
{{{
You cannot SPECIALISE `f1'
because its definition has no INLINE/INLINABLE pragma
(or you compiled its defining module without -O)
}}}
Or suggest other wording?
S
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4799#comment:1
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] #4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas
#4799: Imprecise error regarding SPECIALIZE and INLINE/INLINABLE pragmas -+-- Reporter: dreixel |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by dreixel): That looks fine to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4799#comment:2 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] #4391: forkIO threads do not properly save/restore the floating point environment
#4391: forkIO threads do not properly save/restore the floating point
environment
-+--
Reporter: draconx |Owner:
Type: bug | Status: merge
Priority: normal|Milestone: 7.2.1
Component: Runtime System| Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64)| Failure: None/Unknown
-+--
Changes (by simonmar):
* status: new = merge
Comment:
I added a section to the FFI part of the User's Guide:
{{{
Fri Nov 26 12:53:36 GMT 2010 Simon Marlow marlo...@gmail.com
* Document the behaviour of fenv.h functions with GHC (#4391)
}}}
The text I added was
{{{
sect2 id=ffi-floating-point
titleFloating point and the FFI/title
para
On POSIX systems, the literalfenv.h/literal header
provides operations for inspecting and modifying the state of
the floating point unit. In particular, the rounding mode
used by floating point operations can be changed, and the
exception flags can be tested.
/para
para
In Haskell, floating-point operations have pure types, and the
evaluation order is unspecified. So strictly speaking, since
the literalfenv.h/literal functions let you change the
results of, or observe the effects of floating point
operations, use of literalfenv.h/literal renders the
behaviour of floating-point operations anywhere in the program
undefined.
/para
para
Having said that, we emphasiscan/emphasis document exactly
what GHC does with respect to the floating point state, so
that if you really need to use literalfenv.h/literal then
you can do so with full knowledge of the pitfalls:
itemizedlist
listitem
para
GHC completely ignores the floating-point
environment, the runtime neither modifies nor reads it.
/para
/listitem
listitem
para
The floating-point environment is not saved over a
normal thread context-switch. So if you modify the
floating-point state in one thread, those changes may be
visible in other threads. Furthermore, testing the
exception state is not reliable, because a context
switch may change it. If you need to modify or test the
floating point state and use threads, then you must use
bound threads
(literalControl.Concurrent.forkOS/literal), because
a bound thread has its own OS thread, and OS threads do
save and restore the floating-point state.
/para
/listitem
listitem
para
It is safe to modify the floating-point unit state
temporarily during a foreign call, because foreign calls
are never pre-empted by GHC.
/para
/listitem
/itemizedlist
/para
/sect2
}}}
Please re-open if you disagree or want to suggest alternative text.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4391#comment:12
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] #4801: Typechecker performance regression 6.12 - 7.0.1
#4801: Typechecker performance regression 6.12 - 7.0.1 +--- Reporter: simonmar |Owner: Type: bug | Status: new Priority: high |Milestone: 7.0.2 Component: Compiler (Type checker) | Version: 7.0.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown +--- The attached module is a smaller version of the example in #4505. With GHC 6.12.3 it takes 4s to compile (x86_64/Linux), whereas with 7.0.1 it takes 282s. HEAD seems about the same as 7.0.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4801 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] #4505: Segmentation fault on long input (list of pairs)
#4505: Segmentation fault on long input (list of pairs) -+-- Reporter: cathper |Owner: simonmar Type: bug | Status: new Priority: highest |Milestone: 7.0.2 Component: Compiler | Version: 7.0.1 Keywords: Segmentation fault, segfault, long input | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: Runtime crash -+-- Comment(by simonmar): I understand what the problem is here. The program compiles to code that allocates 1MB in one go, and the runtime doesn't currently support that (we support allocating 1MB only for a single object, such as an array, not for multiple objects). This is a zero-day bug: it's been around for ever, but nobody has run into it until now. Worst case we can make the RTS emit an error message rather than just segfaulting, but I hope we'll be able to find a way to fix it properly. I'll look into it. Meanwhile, it seems the HEAD can't compile the test program at all, unless a type signature is added, and 7.0.1 is significantly slower than 6.12.3 to compile it. I've created #4801 for the compiler performance regression. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4505#comment:6 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] #4505: Segmentation fault on long input (list of pairs)
#4505: Segmentation fault on long input (list of pairs) -+-- Reporter: cathper |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.0.2 Component: Compiler | Version: 7.0.1 Keywords: Segmentation fault, segfault, long input | Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64)| Failure: Runtime crash -+-- Changes (by simonmar): * priority: highest = high Comment: Not a blocker, because it's not a regression. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4505#comment:7 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] #4535: Add tryReadChan to Chan
#4535: Add tryReadChan to Chan
-+--
Reporter: mitar |Owner:
Type: proposal | Status: new
Priority: normal|Milestone:
Component: libraries/base| Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonmar):
`tryReadChan` itself looks ok to me.
If `tryModifyMVar` were to be public, I'd expect its type to be
{{{
tryModifyMVar :: MVar a - (a - IO (a, b)) - IO (Maybe b)
}}}
but I can see why you used instead
{{{
tryModifyMVar :: MVar a - (a - IO (a, Maybe b)) - IO (Maybe b)
}}}
because the former would require an extra `Control.Monad.join`, whereas
the latter has it built-in.
`tryReadMVar` looks like the right thing, I wouldn't object to that going
in `Control.Concurrent.MVar`.
What is the purpose of the INLINE pragma?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4535#comment:2
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] #4536: SampleVar could also be an instance of Eq and Typable
#4536: SampleVar could also be an instance of Eq and Typable -+-- Reporter: mitar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): no objection here. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4536#comment:2 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] #4536: SampleVar could also be an instance of Eq and Typable
#4536: SampleVar could also be an instance of Eq and Typable -+-- Reporter: mitar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): overlaps with #4537 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4536#comment:3 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] #4537: Make SampleVar an instance of Typeable
#4537: Make SampleVar an instance of Typeable -+-- Reporter: basvandijk|Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): #4536 proposes the same thing, and also an `Eq` instance. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4537#comment:1 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] #4536: SampleVar could also be an instance of Eq and Typable
#4536: SampleVar could also be an instance of Eq and Typable -+-- Reporter: mitar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by mitar): Yes, it is a duplicate of #4537. It should probably be just closed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4536#comment:4 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] #4536: SampleVar could also be an instance of Eq and Typable
#4536: SampleVar could also be an instance of Eq and Typable -+-- Reporter: mitar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by mitar): In base-4.3.0.0 it already is an `Eq` instance. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4536#comment:5 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] #4537: Make SampleVar an instance of Typeable
#4537: Make SampleVar an instance of Typeable -+-- Reporter: basvandijk|Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by mitar): * cc: mmi...@… (added) Comment: In base-4.3.0.0 it already is an 'Eq' instance. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4537#comment:2 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] #4533: IO manager can leak MVars if threads are killed
#4533: IO manager can leak MVars if threads are killed
-+--
Reporter: bos |Owner: bos
Type: bug | Status: patch
Priority: normal|Milestone:
Component: Runtime System| Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
-+--
Comment(by simonmar):
We need to think about the consequences of changing the base API and
whether we can do this in a minor release. Normally we don't make API
changes, but if the API change is just an addition and is necessary to fix
a bug, then a case could be made.
Quick patch review. Instead of this:
{{{
takeMVar m `catch` \(e::SomeException) -
M.unregisterTimeout mgr reg throw e
}}}
it's better to write
{{{
takeMVar m `onException` M.unregisterTimeout mgr reg
}}}
However, I'm a little concerned that you haven't closed the leak fully
here. I think you want a `mask_`:
{{{
threadDelay :: Int - IO ()
threadDelay usecs = mask_ $ do
Just mgr - readIORef eventManager
m - newEmptyMVar
_ - registerTimeout mgr usecs (putMVar m ())
takeMVar m `onException` M.unregisterTimeout mgr reg
}}}
otherwise an exception could strike after `registerTimeout` but before
`takeMVar`. Perhaps it works without the `mask_`, but that would only be
by accident.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4533#comment:8
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] #4536: SampleVar could also be an instance of Eq and Typable
#4536: SampleVar could also be an instance of Eq and Typable -+-- Reporter: mitar | Owner: Type: proposal| Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.1 Resolution: duplicate | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: thanks - closing as dup of #4537. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4536#comment:6 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] #4535: Add tryReadChan to Chan
#4535: Add tryReadChan to Chan -+-- Reporter: mitar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by mitar): Replying to [comment:2 simonmar]: What is the purpose of the INLINE pragma? I just copied it from `modifyMVar`. I am not sure if it is needed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4535#comment:3 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] #4391: forkIO threads do not properly save/restore the floating point environment
#4391: forkIO threads do not properly save/restore the floating point environment -+-- Reporter: draconx |Owner: Type: bug | Status: merge Priority: normal|Milestone: 7.2.1 Component: Runtime System| Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: x86_64 (amd64)| Failure: None/Unknown -+-- Comment(by draconx): The fenv.h functions are standard C, not limited to POSIX systems. Also, this IMO needs to be in the Control.Concurrent manual, because this has everything to do with threads and nothing to do with the FFI. About purity: the thing is, even if we had the perfect pure API for floating point, you'd _still_ be bitten by this issue! That's because the issue is not about purity at all: it's about the runtime clobbering CPU registers on context switches. Note that integer operations on a certain popular CPU architecture are just as impure as floating point: there is a register which stores flags such as overflow state that is modified by operations (this register performs essentially identical function to the floating point control word on that same popular architecture). But nobody would posit that all bets are off because a program uses conditional branches! No amount of purity will save you from silent data corruption. Nevertheless, I overestimated the damage: using bound threads appears to be a suitable workaround. I was under the impression that a bound thread could be pre-empted by an unbound thread, but some testing reveals this to not be the case. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4391#comment:13 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] #3165: :history throws Irrefutable pattern failed exception
#3165: :history throws Irrefutable pattern failed exception ---+ Reporter: greenrd | Owner: igloo Type: bug | Status: closed Priority: normal| Milestone: 6.12.1 Component: GHCi |Version: 6.10.2 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Linux Blocking:| Architecture: x86 Failure: None/Unknown | ---+ Comment(by simonmar): Replying to [comment:10 mnislaih]: The previous output was nicer to the user, but one could argue that the new output is more correct. In my opinion it is not a big deal, and changing it to behave as before would involve having a hybrid approach to resolving the enclosing decl of a tick, which does not sound appealing at all. So I would say the new output is OK. I think it's a bit of a shame to lose that, since the breakpoint really is on the top-level function, not the module. Why are these outer breakpoints not attributed to the function any more? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3165#comment:12 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] #4519: Do not link in unused code
#4519: Do not link in unused code --+- Reporter: gidyn| Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler |Version: 7.0.1 Resolution: duplicate| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: Thanks for the report. I think we already have this covered with #4417 and #3252. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4519#comment:5 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] #4417: Quasiquoting without bloating
#4417: Quasiquoting without bloating -+-- Reporter: rrnewton |Owner: Type: feature request | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 6.13 Keywords: executable size | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): See #4519 for another report of this. #3252 is an earlier ticket also asking to get rid of `__stginit`. Leaving both open because this ticket has lots of useful discussion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4417#comment:9 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] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain
#3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain -+-- Reporter: duncan|Owner: Type: feature request | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler (FFI)| Version: 6.10.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): See also #4417. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3252#comment:8 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] #4417: Quasiquoting without bloating
#4417: Quasiquoting without bloating -+-- Reporter: rrnewton |Owner: Type: feature request | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 6.13 Keywords: executable size | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by gidyn): * cc: gid...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4417#comment:10 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] #4391: forkIO threads do not properly save/restore the floating point environment
#4391: forkIO threads do not properly save/restore the floating point environment -+-- Reporter: draconx |Owner: Type: bug | Status: merge Priority: normal|Milestone: 7.2.1 Component: Runtime System| Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: x86_64 (amd64)| Failure: None/Unknown -+-- Comment(by simonmar): Replying to [comment:13 draconx]: The fenv.h functions are standard C, not limited to POSIX systems. True, I'll fix that. Also, this IMO needs to be in the Control.Concurrent manual, because this has everything to do with threads and nothing to do with the FFI. I don't think I agree. You have to use the FFI to access the `fenv.h` functions, and if you do, you have problems even without threads. About purity: the thing is, even if we had the perfect pure API for floating point, you'd _still_ be bitten by this issue! That's because the issue is not about purity at all: it's about the runtime clobbering CPU registers on context switches. Note that integer operations on a certain popular CPU architecture are just as impure as floating point: there is a register which stores flags such as overflow state that is modified by operations (this register performs essentially identical function to the floating point control word on that same popular architecture). But nobody would posit that all bets are off because a program uses conditional branches! No amount of purity will save you from silent data corruption. Are you claiming we have a problem with the overflow flag, or other CPU state? I get the impression from your comments that you think GHC preempts threads at arbitrary points, and therefore has to save the entire CPU state, like OS threads do. We don't do that - threads are preempted at safe points only, and we know exactly what state needs to be saved and restored (it doesn't include the overflow flag, for instance, because we know that a safe point never occurs between an instruction that sets the overflow flag and one that tests it). Using safe points means that we have much less state to save than OS threads, which is why Haskell threads are much cheaper. There are costs of course - for example it's harder to preempt tight loops without sacrificing performance, and GHC doesn't currently attempt to do that. We do handle certain global state specially. A good example is the `errno` variable: we save the value of `errno` over a context switch. We could do the same thing with the FPU state, but we've decided not to, for the reasons already explained. I'm sure this isn't the perfect solution for everyone, but I think it's the best compromise. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4391#comment:14 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] #1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin)
#1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin) -+-- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: high| Milestone: 7.0.1 Component: Compiler|Version: 7.1 Resolution: worksforme | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: MacOS X Blocking: | Architecture: powerpc Failure: Compile-time crash | -+-- Changes (by PHO): * status: patch = closed * resolution: = worksforme Comment: Ah... I must say that... the darcs HEAD works well without my last 2 (unmerged) patches. I can't explain why, but anyway it works, so I withdraw them. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1845#comment:24 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] #4802: 'current directory' is not thread local
#4802: 'current directory' is not thread local
-+--
Reporter: tanakh| Owner:
Type: bug | Status: new
Priority: normal| Component: libraries/directory
Version: 7.0.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Documentation bug
-+--
In a threaded code, the current directory is not thread local, even using
forkOS.
For example:
{{{
import System.Directory
import Control.Concurrent
main :: IO ()
main = do
print = getCurrentDirectory
forkOS $ do
setCurrentDirectory a
threadDelay $ 10^6
print = getCurrentDirectory
forkOS $ do
threadDelay $ 10^6
print = getCurrentDirectory
threadDelay $ 20*10^6
}}}
The output is:
{{{
$ ghc --make -threaded curdir.hs
[1 of 1] Compiling Main ( curdir.hs, curdir.o )
Linking curdir ...
$ ./curdir
/home/hideyuki
/home/hideyuki/a
/home/hideyuki/a
}}}
It seems to inherit the specification of pthread. It may be environment-
dependent behavior (At least, on Linux and Windows, same results are
given).
If the behavior like above is the specific, documents should be added to
setCurrentDirectory/getCurrentDirectory. It is very confusing.
Or if it is possible to wrap the behabior of 'current directory' to make
thread local in Haskell code, I hope to make it so.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4802
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] #4802: 'current directory' is not thread local
#4802: 'current directory' is not thread local -+-- Reporter: tanakh| Owner: Type: bug | Status: new Priority: normal| Component: libraries/directory Version: 7.0.1 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Documentation bug -+-- Changes (by tanakh): * cc: tanaka.hidey...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4802#comment:1 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] #4803: can't find a register in cla ss ‘BREG’ while reloading ‘asm’ - pr oblem with dynamic link libraries
#4803: can't find a register in class ‘BREG’ while reloading ‘asm’ - problem
with dynamic link libraries
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.12.3 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86 | Failure: GHC rejects valid program
---+
When compiling the cpuid package with dynamic link libraries I get the
following error:
{{{
$ cabal install --enable-shared cpuid-0.2
...
cbits/cpuid.c: In function ‘cpuid’:
cbits/cpuid.c:7:0:
error: can't find a register in class ‘BREG’ while reloading ‘asm’
cbits/cpuid.c:7:0: error: ‘asm’ operand has impossible constraints
...
}}}
The shortest call of ghc to reproduce this error is:
{{{
cpuid-0.2/cbits$ ghc -fPIC -c cpuid.c
}}}
The shortest call of gcc to reproduce this error is:
{{{
cpuid-0.2/cbits$ gcc -fPIC -c cpuid.c
}}}
The content of cpuid.c is:
{{{
void cpuid(int in, int * aa, int * bb, int * cc, int * dd)
{
int a, b, c, d;
asm(cpuid: =a (a), =b (b), =c (c), =d (d) : a (in));
*aa = a;
*bb = b;
*cc = c;
*dd = d;
}
}}}
Shall I consider this a bug of GHC or of the cpuid package?
Since GCC complains about this problem, I'm afraid it must be solved in
the cpuid package.
Just wanted to make sure the problem is reported somewhere.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4803
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] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain
#3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain -+-- Reporter: duncan|Owner: Type: feature request | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler (FFI)| Version: 6.10.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by michalt): * cc: michal.terep...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3252#comment:9 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] #4417: Quasiquoting without bloating
#4417: Quasiquoting without bloating -+-- Reporter: rrnewton |Owner: Type: feature request | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 6.13 Keywords: executable size | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by michalt): * cc: michal.terep...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4417#comment:11 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] #4803: can't find a register in class ‘BREG’ while reloading ‘asm’ - problem with dynamic link libraries
#4803: can't find a register in class ‘BREG’ while reloading ‘asm’ - problem with dynamic link libraries ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.3 |Keywords: Testcase: | Blockedby: Os: Linux |Blocking: Architecture: x86 | Failure: GHC rejects valid program ---+ Comment(by guest): Possible solutions are shown at: http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inlin -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4803#comment:1 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] #4533: IO manager can leak MVars if threads are killed
#4533: IO manager can leak MVars if threads are killed
-+--
Reporter: bos |Owner: bos
Type: bug | Status: patch
Priority: normal|Milestone:
Component: Runtime System| Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
-+--
Comment(by bos):
Thanks, Simon! I didn't know about {{{onException}}} or {{{mask_}}}, so
I'll reroll the patch and use those.
The public API changes are actually for #4514, so let's discuss that over
there.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4533#comment:9
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] #4493: Child from forkProcess calls select/read on parent's Handle, stealing data from parent
#4493: Child from forkProcess calls select/read on parent's Handle, stealing
data
from parent
---+
Reporter: josh|Owner:
Type: bug | Status: infoneeded
Priority: high|Milestone: 7.0.2
Component: Runtime System | Version: 6.12.1
Keywords: | Testcase: yes
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
---+
Comment(by joeyhess):
Josh may have a better test case, but it can be reproduced by the
following.
{{{
import System.Cmd.Utils
main = do
(h, stream) - pipeFrom find [.]
mapM (\file - pipeFrom ls [-l, file]) $ lines stream
}}}
This code is intentionally itself bad, and will leak FDs a lot, but if
you run it in a directory with lots of contents, you'll see that
sometimes, before dying due to too many open FDs, it runs `ls` with a
parameter that is not a complete line output by `find`, due to the data
stealing problem.
Here I run it in ghc's own source tree:
{{{
j...@wren:~/tmp/ghc6-6.12.1runghc ~/testcase.hs
ls: cannot access ./.pc/alpha-tcforeign/systemTests/A/c_src/hello.c: No
such
file or directory
ls: cannot access ./libraries/Cabal/tests/ow: No such file or directory
repo.hs: createPipe: resource exhausted (Too many open files)
j...@wren:~/tmp/ghc6-6.12.1find |grep libraries/Cabal/tests/ow
j...@wren:~/tmp/ghc6-6.12.1
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4493#comment:3
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] #4163: Make cross-compilation work
#4163: Make cross-compilation work
-+--
Reporter: simonmar |Owner:
Type: task | Status: new
Priority: high |Milestone: 7.0.2
Component: Build System | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty: Difficult (2-5 days)
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by altaic):
* cc: william.knop.nos...@… (added)
Comment:
I just tried compiling HEAD with host = build = target = x86_64-apple-
darwin on my OSX (10.6.5) machine (64-bit processor; kernel is booted as
64-bit as well), and it fails with:
{{{
/usr/bin/gcc -o utils/unlit/dist/build/tmp/unlit -m64 -fno-stack-
protector utils/unlit/dist/build/unlit.o
ld: warning: in utils/unlit/dist/build/unlit.o, file was built for i386
which is not the architecture being linked (x86_64)
Undefined symbols:
_main, referenced from:
start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [utils/unlit/dist/build/tmp/unlit] Error 1
make: *** [all] Error 2
}}}
I'll hazard a guess that this is because the configure scripts for
libraries/integer_gmp and libraries/unix are autodetecting host, build,
and target as i386. Shouldn't libraries inherit host, build, and target
from the overall configure script a la [wiki:CrossCompilation]?
For reference, a standard i386 build (no configure options) does pretty
well, until it inexplicably fails in stage 2 with make[1]: ***
[libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o]
Bus error, but that's for another ticket. :)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4163#comment:8
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] #1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin)
#1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for
powerpc_apple_darwin)
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: high| Milestone: 7.0.1
Component: Compiler|Version: 7.1
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: MacOS X
Blocking: | Architecture: powerpc
Failure: Compile-time crash |
-+--
Changes (by PHO):
* owner: igloo =
* status: closed = new
* resolution: worksforme =
Comment:
Sorry, looks like I spoke too soon.
GHCi still crashes on loading GHCi libraries. It only works if we don't
build GHCi libraries (not archives) at all. I'll investigate this further.
{{{
% ./inplace/bin/ghc-stage2 --interactive -package ghc
GHCi, version 7.1.20101127: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... zsh: segmentation fault
./inplace/bin/ghc-stage2 --interactive -package ghc
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1845#comment:25
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] #1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin)
#1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin) -+-- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high| Milestone: 7.0.1 Component: Compiler|Version: 7.1 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: MacOS X Blocking: | Architecture: powerpc Failure: Compile-time crash | -+-- Changes (by PHO): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1845#comment:26 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] #4804: Bus Error during Stage 2 (libraries/vector)
#4804: Bus Error during Stage 2 (libraries/vector)
-+--
Reporter: altaic| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.1 |Keywords:
Testcase:| Blockedby:
Os: MacOS X |Blocking:
Architecture: Unknown/Multiple | Failure: Building GHC failed
-+--
Vanilla build of HEAD with a virgin repository on MacOS X 10.6.5 (MacBook
Pro; Core 2 Duo CPU; 8GB RAM; kernel running in 64-bit mode) failed:
{{{
inplace/bin/ghc-stage2 -H32m -O-package-name vector-0.7.0.1 -hide-
all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build
-ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-
install/build -Ilibraries/vector/dist-install/build/autogen
-Ilibraries/vector/include -Ilibraries/vector/internal -optP-
DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-
install/build/autogen/cabal_macros.h -package base-4.3.0.0 -package
primitive-0.3.1 -O2 -XCPP -XDeriveDataTypeable -no-user-package-conf
-rtsopts -O2 -XGenerics -odir libraries/vector/dist-install/build
-hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-
install/build -hisuf hi -osuf o -hcsuf hc -c
libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o
libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package primitive-0.3.1 ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
make[1]: *** [libraries/vector/dist-
install/build/Data/Vector/Fusion/Stream/Monadic.o] Bus error
make: *** [all] Error 2
}}}
Configure Summary:
{{{
Configure completed successfully.
Building GHC version : 7.1.20101127
Build platform: i386-apple-darwin
Host platform : i386-apple-darwin
Target platform : i386-apple-darwin
Bootstrapping using : /usr/bin/ghc
which is version : 7.0.0.20100924
Using GCC : /usr/bin/gcc
which is version : 4.2.1
ld : /usr/bin/ld
Happy: /usr/local/bin/happy (1.18.5)
Alex : /usr/local/bin/alex (2.3.3)
Python : /usr/bin/python
Perl : /usr/bin/perl
dblatex : /usr/local/bin/dblatex
xsltproc : /usr/bin/xsltproc
HsColour : /Users/wknop/.cabal/bin/HsColour
Building DocBook HTML documentation : YES
Building DocBook PS documentation : YES
Building DocBook PDF documentation : YES
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4804
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] #4514: IO manager can deadlock if a file descriptor is closed behind its back
#4514: IO manager can deadlock if a file descriptor is closed behind its back
--+-
Reporter: adept| Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.0.2
Component: Runtime System |Version: 7.0.1
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime |
--+-
Comment(by bos):
I'm pasting in some comments from Ian in email:
Skimming through this patch I noticed some interface changes. We try not
to change the interfaces of libraries within a GHC branch (e.g. 7.0.1 and
7.0.2 should have the same library APIs). If it's really necessary then we
can make changes, although we should keep them as small as possible.
The particular changes also aren't obviously right to me. e.g. I
wouldn't expect {{{Control.Concurrent}}} to export something called
{{{closeFd}}}, and I wouldn't expect something called {{{closeFd}}} to
have that type.
I believe that it's not possible to avoid any of the submitted API changes
here. Specifically:
* The {{{fdWasClosed}}} function that we added during 6.13 development was
subject to a race condition: you could mark an fd as closed after another
thread had performed an {{{open}}} or similar that could reuse that fd.
* The new {{{closeFd}}} function is necessary to close that race. It
manages this by closing the fd while holding an {{{MVar}}}, so another
thread can't race in and register the fd.
* Why does {{{closeFd}}} accept an action as parameter? Because under
Windows, you have to use different functions to close a file descriptor
depending on whether it's owned by Winsock or the rest of win32.
* If the name should be something like {{{closeFdWith}}} to be more
descriptive, that's fine (please let me know if you have a preference), as
my purpose is to close the race :-)
* Why should {{{closeFdWith}}} be exported from {{{Control.Concurrent}}}?
Because {{{threadWaitRead}}} and {{{threadWaitWrite}}} already are, and
{{{closeFdWith}}} must be used with those functions now to guarantee race-
free closing.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4514#comment:32
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] #4514: IO manager can deadlock if a file descriptor is closed behind its back
#4514: IO manager can deadlock if a file descriptor is closed behind its back --+- Reporter: adept| Owner: Type: bug | Status: new Priority: high | Milestone: 7.0.2 Component: Runtime System |Version: 7.0.1 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | --+- Comment(by bos): Goddamn Trac. Augh. * The fdWasClosed function that we added during 6.13 development was subject to a race condition: you could mark an fd as closed after another thread had performed an open or similar that could reuse that fd. * The new closeFd function is necessary to close that race. It manages this by closing the fd while holding an MVar, so another thread can't race in and register the fd. * Why does closeFd accept an action as parameter? Because under Windows, you have to use different functions to close a file descriptor depending on whether it's owned by Winsock or the rest of win32. * If the name should be something like closeFdWith to be more descriptive, that's fine (please let me know if you have a preference), as my purpose is to close the race :-) * Why should closeFdWith be exported from Control.Concurrent? Because threadWaitRead and threadWaitWrite already are, and closeFdWith must be used with those functions now to guarantee race-free closing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4514#comment:33 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] #4514: IO manager can deadlock if a file descriptor is closed behind its back
#4514: IO manager can deadlock if a file descriptor is closed behind its back --+- Reporter: adept| Owner: bos Type: bug | Status: new Priority: high | Milestone: 7.0.2 Component: Runtime System |Version: 7.0.1 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | --+- Changes (by bos): * owner: = bos -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4514#comment:34 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] #4514: IO manager can deadlock if a file descriptor is closed behind its back
#4514: IO manager can deadlock if a file descriptor is closed behind its back --+- Reporter: adept| Owner: bos Type: bug | Status: patch Priority: high | Milestone: 7.0.2 Component: Runtime System |Version: 7.0.1 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | --+- Changes (by bos): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4514#comment:35 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] #4805: segfault in Data.HashTable, triggered by long Agda runs
#4805: segfault in Data.HashTable, triggered by long Agda runs
---+
Reporter: wkahl | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.0.1 |Keywords: Data.HashTable segfault
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Agda uses {{{Data.HashTable}}} for interface (*.agdai) serialisation.
I have been able to localise a reproducible segfault (with one of the many
theories in a sizeable Agda develoment) in
{{{Agda.TypeChecking.Serialise.encode}}} inside the {{{icode}}} call,
which essentially limits the possible source of the segfault to the Agda
module {{{Agda.TypeChecking.Serialise}}} and to {{{Data.HashTable}}}.
Then I replaced all hash table uses in {{{encode}}} with {{{Data.Map}}},
and the Agda run in question finishes successfully.
(I confirmed with a selection of the theories that already could be type-
checked with {{{Data.HashTable}}} that the {{Data.Map}}}-based version
generates the same interface files.)
(Agda interface serialisation maintains four partial maps; their
respective sizes at the end of this run are 151796,733,3319,0.)
I consider this as a (non-constructive) proof that there is a bug in
{{{Data.HashTable}}}.
(For the time being, I need to make some long-delayed progress in my Agda
developments and won't have time to try to debug {{{Data.HashTable}}}, but
I should be able to occasionally test potential fixes.)
Wolfram
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4805
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] #4805: segfault in Data.HashTable, triggered by long Agda runs
#4805: segfault in Data.HashTable, triggered by long Agda runs
---+
Reporter: wkahl | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.0.1 |Keywords: Data.HashTable segfault
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Comment(by wkahl):
Currently, I normally run with the following RTS flags:
{{{
+RTS -C0 -i0 -K64M -M12G -H12G -S -RTS
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4805#comment:1
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] #4391: forkIO threads do not properly save/restore the floating point environment
#4391: forkIO threads do not properly save/restore the floating point
environment
-+--
Reporter: draconx |Owner:
Type: bug | Status: merge
Priority: normal|Milestone: 7.2.1
Component: Runtime System| Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64)| Failure: None/Unknown
-+--
Comment(by draconx):
Replying to [comment:14 simonmar]:
Replying to [comment:13 draconx]:
Also, this IMO needs to be in the Control.Concurrent manual, because
this
has everything to do with threads and nothing to do with the FFI.
I don't think I agree. You have to use the FFI to access the `fenv.h`
functions
Sure, but the fenv.h functions aren't the only way to access the floating
point unit (the fact that they're standard C helps with portability,
though).
Maybe it's impossible to access it without using the FFI, but that's
incidental: I don't think you can access the internet without using the
FFI either, but that doesn't mean we should put issues related to IP
fragmentation in the FFI section of the user guide.
and if you do, you have problems even without threads.
The reason why this is purely a threading issue is because it affects
*all*
floating point, not just the built-in floating point ops. You will get no
argument from me in saying that the built-in ops are problematic. To
illustrate this, let's consider an example. Suppose we had a floating
point
API which captures all impurity. For simplicitiy, we'll do this by
putting
everything in IO. Our API therefore looks something like the following:
{{{
dblAdd :: Double - Double - IO Double
dblMul :: Double - Double - IO Double
fpSetRoundingMode :: FPRoundingMode - IO ()
fpTestExceptions :: IO [FPException]
etc.
}}}
We can easily implement this API, today, using the FFI (ignoring all
issues
related to the marshalling of floating point data). Further suppose that
the
program never uses any of the built-in floating point ops, thus there are
trivially no problems related to impurity. This API might even come from
a
library which hides the fact that it uses the FFI internally.
A well-intentioned application developer has a correct single-threaded
program
using this API. She realizes that she can make it faster by using
threads, so
she turns to the threading documentation. The thread documentation tells
her
that forkOS threads are needed if you use thread local state, otherwise
forkIO threads are much faster (the docs emphasize this last point *very*
strongly). It makes no mention of floating point, so she (quite
reasonably)
assumes that floating point (which doesn't depend on thread local state
in
the usual sense of that term) is OK to use with forkIO.
Little does she know that her program is now subject to subtle, rare
races.
Despite extensive testing, these races are never encountered in the lab.
The
issue remains hidden until the maiden launch of the spacecraft on which
her
code is running, at which point a mishandled floating point exception
causes
the craft to break apart shortly after takeoff.
About purity: the thing is, even if we had the perfect pure API for
floating
point, you'd _still_ be bitten by this issue! That's because the
issue is not
about purity at all: it's about the runtime clobbering CPU registers
on context
switches. Note that integer operations on a certain popular CPU
architecture
are just as impure as floating point
Are you claiming we have a problem with the overflow flag, or other CPU
state?
No, I didn't mean to suggest that there was any problem with the handling
of
the integer overflow flag. I just wanted to draw a parallel to show that
the
issues are the same; that floating point is not somehow special in this
regard.
I get the impression from your comments that you think GHC preempts
threads
at arbitrary points
From the perspective of the application developer, this is exactly what
happens, since it's essentially impossible to know in advance when memory
allocations will or will not occur. Furthermore, the wording in the docs
suggests that it's not even safe to rely on this. Statements such as
threads
are interleaved in a random fashion and GHC doesn't *currently* attempt
[to
preempt tight loops] (emphasis mine) suggest that threads might be
preempted
for other reasons in the future.
We don't do that - threads are preempted at safe points only, and we
know
exactly what state needs to be saved and restored (it doesn't include
the
overflow flag, for
Re: [GHC] #2442: Heuristics to improve error messages for badly referenced things
#2442: Heuristics to improve error messages for badly referenced things -+-- Reporter: batterseapower|Owner: simonpj Type: feature request | Status: patch Priority: high |Milestone: 7.0.1 Component: Compiler | Version: 6.9 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by mitar): * cc: mmi...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2442#comment:17 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] #4806: Make error message more user friendly when module is not found because package is unusable
#4806: Make error message more user friendly when module is not found because package is unusable -+-- Reporter: mitar | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.0.1 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with `ghc-pkg find-module` shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4806 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: Modifying functions in the typechecker?
I think it would help to separate issues. If it were not for rebindable syntax, there would be no need for these op fields in (say) BindStmt etc. Instead, we'd have a fixed typing rule for BindStmt, and the desugarer would use the fixed Control.Monad.(=). The rebindable syntax thing just allows you to use a different (=), and therefore we must record the one we use in the BindStmt node. It's the same for ExprStmt. I believe you want to support rebindable syntax for monad comprehensions, so you have to record the rebindable () and guard operators. But I don't think you intend to allow the programmer rebind composition (.), do you? If not, don't record it. The desugarer can use the fixed one from the Prelude. | Is this a valid approach? Should I move the () . guard function | somewhere else? I had a look at the renamer where () is added to the | statement ExprStmt the first time, but apparently you cannot call | tcSyntaxOp in the typechecker on this function if you construct it | with HsApp (compose_op `HsApp` then_op) guard_op. Is there another | function which could typecheck such a constructed expression without | telling the user what functions we've used? I think it'd be easier just to record 'guard' and 'then' separately. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to activate DEBUG in Data.HashTable?
On 29/11/2010 02:05, Wolfram Kahl wrote: Hello, with a large Agda development, I have a reproducible segmentation fault that I have been able to localise to the serialisation (Agda.TypeChecking.Serialise.encode), which heavily relies on Data.HashTable. Now I find that Data.HashTable (from GHC-7.0.1) has a CPP-enabled DEBUG version --- is there a ``proper'' way to activate this? Possibly even so that it can be added ex-post to an existing installation? (So I don't have to re-install all packages.) mk/ways.mk says that the ``debug'' way only affects the RTS... This is a compile-time option, so there's no way to enable it without recompiling the base package (and hence, GHC itself). However, you can always grab a copy of the source code and drop it into your souce tree, it will be used in place of the base package version. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SpecConstr number of specializations (-fspec-constr-count)
On 25/11/2010 20:01, Roman Leshchinskiy wrote: On 25/11/2010, at 10:33, José Pedro Magalhães wrote: Is this a bug, or is the value of spec-constr-count being manipulated in some way for certain passes? spec-constr-count decreases for nested specialisations. For instance, if spec-constr-count is 6 and SpecConstr generates 2 specialisations for a function foo, then spec-constr-count will be 3 for all functions nested in foo. You can turn it off completely with -fno-spec-constr-count. The messages are a bit counter-intuitive though - I encountered this recently too, and was baffled by the fact that the suggested flag, -fspec-constr-count, didn't seem to have any effect. Also, these messages should be clearly labelled as warnings, and there should be a way to disable them (I realise they're being generated by the SpecConstr pass and we don't normally generate warnings beyond the desugarer, but still.) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: packaging options for Mac OS X
On Mon, Nov 29, 2010 at 01:29:10PM +1100, Manuel M T Chakravarty wrote: Ian Lynagh: On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote: Outstanding question is what should this framework be called? I would like to continue to call it GHC.framework, but change the version to something like 7.0.1+HP-i386, I think it ought to be called Haskell-Platform.framework. The GHC.framework inside the Haskell Platform should still be the GHC.framework. The rest of the Haskell Platform might be in a different framework (or further, more specific frameworks identifying the individual components inside). A Mac OS X framework is *not* a unit of distribution. It is more like a library with associated meta data and tools. You wouldn't rename glibc to, say, ubuntulibc just because you happen to get it via an Ubuntu install. Oh, if the framework just contains GHC then GHC.framework makes sense. [*] The binary GHC distribution could be - built by the GHC team, and asking them for a tarball (as Duncan suggested) I do make framework-pkg to build the OS X installer, but it's essentially a black box to me. We're happy to accept patches that make this also produce a bindist, though. Now that we have the Haskell Platform, perhaps we should stop making GHC OS X installers, and only make plain old unix bindists. Especially given that the Haskell Platform is released many months after GHC, please keep making GHC OS X installers. At the very least, that will lead to more GHC installs and *testing* on OS X between the GHC release and Haskell Platform release. For previous GHC releases, some OS X users have been not testing GHC RCs as that would mean uninstalling their current GHC (which they know works, and has a load of packages installed). That's semi-fixed now (there are still some issues, e.g. you can't install an earlier version than you already have installed - although I don't know how earlier is determined), but even so a bindist installed under ~ may feel safer to people who don't want their system GHC affected. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton w...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-C-Error.html#v%3AthrowErrnoIfRetryMayBlock ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On 11/29/10 6:36 PM, Bryan O'Sullivan wrote: On Sat, Nov 27, 2010 at 9:05 PM, wren ng thorntonw...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? The blocking for someone to open the other end is perfectly normal. The fact that compiling with -threaded takes a perfectly working program and makes it consistently crash I wouldn't call normal. N.B., the call to openFd in question is from the main thread and before any STM or forkIO shenanigans. Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-C-Error.html#v%3AthrowErrnoIfRetryMayBlock I'll see if I can make a workaround with that, but as I said: Simon's already confirmed that this is a bug, I'm just looking for a ticket number or a version where it's fixed. -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On Mon, Nov 29, 2010 at 9:49 PM, wren ng thornton w...@freegeek.org wrote: Isn't that pretty normal? The blocking for someone to open the other end is perfectly normal. The fact that compiling with -threaded takes a perfectly working program and makes it consistently crash I wouldn't call normal. Actually, this happens all the time if you're calling a system call that isn't already wrapped for you, and the behaviour is expected: you absolutely must expect, and deal with, EINTR. Here's an example: http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ Are you using System.Posix.IO.openFD? The check for EINTR wasn't added to the unix package until January of this year, so perhaps the version of GHC or the unix package that you're using is too old to contain the fix? N.B., the call to openFd in question is from the main thread and before any STM or forkIO shenanigans. That doesn't matter. Once the threaded RTS starts, it's going to send your program SIGVTALRM. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: genprog-0.1
Dear Haskellers, I am pleased to announce the release of genprog-0.1, a genetic programming library. Genetic programming is an evolutionary technique, inspired by biological evolution, to evolve programs for solving specific problems. A genetic program is represented by a value of an algebraic datatype and associated with a custom-defined fitness value indicating the quality of the solution. Starting from a randomly generated initial population of genetic programs, the genetic operators of selection, crossover, and mutation are used to evolve programs of increasingly better quality. genprog-0.1 is available from Hackage at: http://hackage.haskell.org/package/genprog An example of how to use the library is included in the documentation. Cheers, Jan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haskell.org downtime: Tuesday Nov 30th
Hi Bas, Neil will be working on developing Hoogle all this weekend, but without Internet access. He expects to get it set up on the new server sometime during next week, but probably not before Weds. Ok thanks for the heads up! We get a new developer at work next week who needs to read through some of our Haskell code. It really helps to have Hoogle around for this type of thing. I'll tell him to install one locally. (Of course there's also Hayoo which is great also) With the darcs version of Hoogle running a local hoogle server is now trivial - just type hoogle server. With that you can build a version of Hoogle that indexes both hackage, along with whatever codebase you might use. Thanks, Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haskell.org downtime: Tuesday Nov 30th
On Mon, Nov 29, 2010 at 10:02 PM, Neil Mitchell ndmitch...@gmail.com wrote: Hi Bas, Neil will be working on developing Hoogle all this weekend, but without Internet access. He expects to get it set up on the new server sometime during next week, but probably not before Weds. Ok thanks for the heads up! We get a new developer at work next week who needs to read through some of our Haskell code. It really helps to have Hoogle around for this type of thing. I'll tell him to install one locally. (Of course there's also Hayoo which is great also) With the darcs version of Hoogle running a local hoogle server is now trivial - just type hoogle server. With that you can build a version of Hoogle that indexes both hackage, along with whatever codebase you might use. Thanks, Neil Nice, thanks! ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haskell.org downtime: Tuesday Nov 30th
Thanks to a large portion of help from Ian, I now have Hoogle working at http://new-www.haskell.org/hoogle/ The old Hoogle seems to have broken with a configuration error - not sure if that's related to the move, or just the old server being flakey, but come tomorrow it won't matter. Thanks, Neil On Mon, Nov 29, 2010 at 10:01 PM, Bas van Dijk v.dijk@gmail.com wrote: On Mon, Nov 29, 2010 at 10:02 PM, Neil Mitchell ndmitch...@gmail.com wrote: Hi Bas, Neil will be working on developing Hoogle all this weekend, but without Internet access. He expects to get it set up on the new server sometime during next week, but probably not before Weds. Ok thanks for the heads up! We get a new developer at work next week who needs to read through some of our Haskell code. It really helps to have Hoogle around for this type of thing. I'll tell him to install one locally. (Of course there's also Hayoo which is great also) With the darcs version of Hoogle running a local hoogle server is now trivial - just type hoogle server. With that you can build a version of Hoogle that indexes both hackage, along with whatever codebase you might use. Thanks, Neil Nice, thanks! ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell-cafe] GHC 7.0.1 developer challenges
| The irony of this situation is deep. CPSA is a program that analyzes | cryptographic protocols in an effort to expose security flaws. To | ensure that the program does not crash a user's machine, I have to use | a linker option that may expose the user to some security problems. Do you have an alternative to suggest? After all, the previous situation wasn't good either. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Template Haskell: exchanging information between 'splicers'
Oleg, I am using GHC 6.12.3 Here a reproduction: in the file Template.hs proc () = runIO $ do runQ [|1+1|] proc' () = [|1+1|] In the file Main.hs i1 = $(proc ()) -- fails at compile time with Segmentation fault/access violation in generated code. Maybe is it the expected behavior, I do not know. i2 = $(proc' ()) -- sucessfull i3 = proc() -- sucessful but proc is executed at runtime main = ... Hope it is clear enough otherwise let me know. Regards J-C On Mon, Nov 29, 2010 at 4:45 AM, o...@okmij.org wrote: Hello! But, please, correct me if I am wrong, in your example, the splicer are executed at run time and not at compile time. With TH, it becomes a bit difficult to tell what is exactly `compile time'. One can say however that when the code is ready to be spliced in at the top level, the IO actions in its splices must have been completed. I have modified your example to make it run at compile time and I get a (compile time) segmentation fault. As I mentioned, the code was specifically designed to cause something like segmentation fault. Sneaking out free variables is definitely the bad thing. The principle of exchanging data between splices (using runQ/runIO) is valid and could be used for good things, too. I am wondering though what GHC version and command-line parameters are you using? On my system. with GHC 6.10.3, I tried running the original and modified code in GHCi and GHC (with and without -O2) and did not get segmentation fault. Could you provide more details about your system so to reproduce the segfault? I think Simon Peyton-Jones would really like to know all that. Cheers, Oleg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transparent identity instances
On Sun, Nov 28, 2010 at 10:59 PM, Jafet wrote:
Hi,
Does it make sense to declare a transparent identity instance for
Functor, Applicative, Monad, etc?
For example, I might want to generalize ($) = (*) where
($) :: (a - b) - a - b
(*) :: (Functor f) = f (a - b) - f a - f b
[...]
Is it sound for such an instance to exist? If so, how might it be defined?
Hi again,
This is my partial progress.
I tried to stuff the Identity concept into another typeclass
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
class FunctorApply a b a' b' where
fmap' :: (a - b) - a' - b'
instance (Functor f) = FunctorApply a b (f a) (f b) where
fmap' = fmap
instance FunctorApply a b a b where
fmap' = id
FunctorApply does work... on purely monomorphic arguments, so that the
only thing that needs to be inferred is the instance to use:
monosucc :: Int - Int
monosucc = succ
foo :: Int
foo = fmap' monosucc (1 :: Int)
bar :: [Int]
bar = fmap' monosucc ([1,2,3] :: [Int])
It does not work with even the slightest polymorphism, because
FunctorApply, like other typeclasses, is open:
foo_bad = fmap' monosucc (1 :: Int)
bar_bad = fmap' succ ([1,2,3] :: [Int]) :: [Int]
foo_bad expects a fictional instance FunctorApply Int Int Int b, and
similarly for bar_bad.
PS: The replies stating that overlapping or undecidable instances
would be required are probably true. Here is my failed attempt to
generalize FunctorApply with Oleg magick:
{-# LANGUAGE EmptyDataDecls, ScopedTypeVariables, MultiParamTypeClasses,
FlexibleInstances, FlexibleContexts, FunctionalDependencies,
UndecidableInstances #-}
class FunctorApply a b a' b' where
fmap' :: (a - b) - a' - b'
class FunctorApply' af bf a b a' b' where
fmap'' :: af - bf - (a - b) - a' - b'
instance (Classify a a' af, Classify b b' bf, FunctorApply' af bf a b a' b')
= FunctorApply a b a' b' where
fmap' = fmap'' (undefined::af) (undefined::bf)
instance FunctorApply' HId HId a b a b where
fmap'' _ _ = id
instance (Functor f, Classify a (f a) HFunctor, Classify b (f b) HFunctor) =
FunctorApply' HFunctor HFunctor a b (f a) (f b) where
fmap'' _ _ f = fmap f
data HFunctor
data HId
class Classify a f x
instance (Functor f, TypeCast x HFunctor) = Classify a (f a) x
instance (TypeCast x HId) = Classify a a x
-- from HList
class TypeCast a b | a - b, b - a where typeCast :: a - b
class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b
class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b
instance TypeCast' () a b = TypeCasta b where typeCast x = typeCast' ()
x
instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
But fmap' still cannot be used polymorphically. What is wrong with the
above code?
PPS: In the initial post, (*) is of course a method of Applicative,
not Functor.
--
Jafet
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Load testing
Grinder : http://grinder.sourceforge.net/ On Mon, Nov 29, 2010 at 1:23 AM, Tony Morris tonymor...@gmail.com wrote: Does there exist a package for convenient load-testing against a website? e.g. making lots of HTTP requests against a server, including timing, and collecting the results? -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Transparent identity instances
On Sun, 2010-11-28 at 22:59 +0800, Jafet wrote:
{-# LANGUAGE TypeSynonymInstances #-}
type Identity a = a
instance Applicative Identity where
-- something like
pure a = a
f * a = f a
But GHC does not accept type synonym instances unless they are fully
applied.
Is it sound for such an instance to exist? If so, how might it be
defined?
data Tag a = Tag
instance Applicative Tag where
pure _ = Tag
Tag * Tag = Tag
cast :: Tag a - Tag b
cast Tag = Tag
1. pure id * Tag = Tag
2. I'm too lazy to prove it
3. pure f * pure x = Tag * Tag = Tag = pure (f x)
4. u * pure y = u * Tag = u = Tag * u = pure ($ y) * u
x = pure undefined
y = x :: Tag ()
Is y defined?
pure!Tag undefined = Tag
pure!Identity undefined = undefined
Regards
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Crazy idea, building ghc with cabal?
Hello Could it be done and would it be interesting, building 'ghc' using cabal? * 'lhc' does it * Use 'cabal-rpm' and 'cabal2arch' to create packages for linux distributions * As ordinary user, install specific versions in your home directory. cabal install ghc = $HOME/.cabal/bin/ghc * Get base packages as a dependency. Greetings Joris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unable to install packages
On 10-11-28 09:55 AM, Ketil Malde wrote: Joachim Breitnerm...@joachim-breitner.de writes: I would not recommend using --global on Debian/Ubuntu-systems, as it might interfere with packages installed by Debian. But 'cabal install --global' installs in /usr/local/, does it not? And official packages (i.e. debs) put stuff in /usr, so these would be separate. Metadata is more important than data. In the case of Debian/Ubuntu's GHC, both 'cabal install --global' and 'apt-get install' records in /var/lib/ghc-6.12.3/package.conf.d If you cabal install one version and apt-get another version, sure, they are two different records in the metadata, no immediate problem. But how about cabal install --global binary apt-get install libghc6-binary-dev They are the same version (at the time of writing, and assume Ubuntu 10.10) and they will fight for the unique throne of binary-0.5.0.2 in the metadata. The immediate problem: they likely have different ABI hashes because they're built differently. Suppose you cabal install --global binary (suppose it becomes binary-0.5.0.2-300339c66a688207241e4643a9e17721) cabal install --global I-depend-on-binary apt-get install libghc6-binary-dev (this is binary-0.5.0.2-32d59ff8fdfc79aa888e82997612374d in Ubuntu 10.10 i386 32-bit) Now I-depend-on-binary is hosed. It was built against binary-0.5.0.2-300339c66a688207241e4643a9e17721 but that's usurped. OK, who would knowingly usurp his/her own binary-0.5.0.2? Of course no one knowingly does. But everyone does it unknowingly: cabal install --global maccatcher (this brings in binary) apt-get install libghc6-agda-dev (this brings in libghc6-binary-dev) Now maccatcher is hosed. See also my http://www.vex.net/~trebla/haskell/sicp.xhtml P.S. Deleting --global mitigates this problem but causes some other problem. I will describe it in my article in the future. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
On Mon, Nov 29, 2010 at 3:36 AM, Simon Peyton-Jones simo...@microsoft.com wrote: | The irony of this situation is deep. CPSA is a program that analyzes | cryptographic protocols in an effort to expose security flaws. To | ensure that the program does not crash a user's machine, I have to use | a linker option that may expose the user to some security problems. Do you have an alternative to suggest? After all, the previous situation wasn't good either. At the time I wrote the above paragraph, I didn't know what security flaw was being addressed. Given that my program would not be used in a risky situation, there is no reason I can't just add the option that turns on runtime flags. But that doesn't address your real question, what to do about Haskell programs that are vulnerable to unauthorized changes to its runtime flags, but which might take input that makes it use up all available swap space. If supplying a special memory limiting flag that is always available is not an option, I can see only one other solution. Somehow the default behavior of the runtime system must impose some reasonable limit. Here is the problem with this suggestion. When I first ran into the memory exhaustion problem, and reported it, I received what I thought was a carefully reasoned explanation as to why choosing a default memory limit was difficult, at least on Linux. The trouble is, I cannot remember the details of explanation nor its author. Sorry to be short of important details. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Crazy idea, building ghc with cabal?
On 30 November 2010 03:46, Joris Putcuyps joris.putcu...@gmail.com wrote: Hello Could it be done and would it be interesting, building 'ghc' using cabal? * 'lhc' does it * Use 'cabal-rpm' and 'cabal2arch' to create packages for linux distributions * As ordinary user, install specific versions in your home directory. cabal install ghc = $HOME/.cabal/bin/ghc * Get base packages as a dependency. ... except we then have a chicken and egg problem: GHC is built with Cabal, which needs a Haskell compiler/implementation, etc. ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unable to install packages
On 10-11-29 03:15 PM, Albert Y. C. Lai wrote: cabal install --global binary apt-get install libghc6-binary-dev They are the same version (at the time of writing, and assume Ubuntu 10.10) and they will fight for the unique throne of binary-0.5.0.2 in the metadata. Oh bother, Debian/Ubuntu's packages are even more treacherous. They circumvent the uniqueness checks of ghc-pkg register. They just smuggle records into /var/lib/ghc-6.12.1/package.conf.d and call ghc-pkg recache. This procedure allows both binary-0.5.0.2 instances to be recorded, both as global. Ironically, ghc-pkg check does not see a problem. But this is more corruption, not less: cabal install --global maccatcher (this brings in binary) apt-get install libghc6-agda-dev (this brings in libghc6-binary-dev) The same problem remains. When you finally try to use binary, GHC still picks one instance only. Depend on luck, one of maccatcher and agda is hosed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Crazy idea, building ghc with cabal?
On Mon, Nov 29, 2010 at 2:48 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 30 November 2010 03:46, Joris Putcuyps joris.putcu...@gmail.com wrote: Hello Could it be done and would it be interesting, building 'ghc' using cabal? * 'lhc' does it * Use 'cabal-rpm' and 'cabal2arch' to create packages for linux distributions * As ordinary user, install specific versions in your home directory. cabal install ghc = $HOME/.cabal/bin/ghc * Get base packages as a dependency. ... except we then have a chicken and egg problem: GHC is built with Cabal, which needs a Haskell compiler/implementation, etc. ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Well, GHC is already written in Haskell, so you already need GHC to compile GHC. I think the reasons are more to do with the fact that Cabal doesn't have some features that are needed for such a complex build as GHC, maybe including the bootstrapping that needs to happen. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Console.Haskeline
How do I load this module? Michael = *Main :m + System.Console.Haskeline no location info: Could not find module `System.Console.Haskeline': it is not a module in the current program, or in any known package. *Main ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Console.Haskeline
On 30 November 2010 13:07, michael rice nowg...@yahoo.com wrote: How do I load this module? Michael = *Main :m + System.Console.Haskeline no location info: Could not find module `System.Console.Haskeline': it is not a module in the current program, or in any known package. *Main What does ghc-pkg list haskeline say? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System.Console.Haskeline
On 30 November 2010 13:43, michael rice nowg...@yahoo.com wrote: [mich...@localhost ~]$ ghc-pkg list haskeline /usr/lib/ghc-6.12.3/package.conf.d /home/michael/.ghc/i386-linux-6.12.3/package.conf.d [mich...@localhost ~]$ This means you don't have the haskeline library installed. If your distribution doesn't have a package for it, cabal install haskeline should do the trick. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Bifold: a simultaneous foldr and foldl
Somebody suggested I post this here if I wanted feedback.
So I was thinking about the ReverseState monad I saw mentioned on r/haskell
a couple days ago, and playing around with the concept of information
flowing two directions when I came up with this function:
bifold :: (l - a - r - (r,l)) - (l,r) - [a] - (r,l)
bifold _ (l,r) [] = (r,l)
bifold f (l,r) (a:as) = (ra,las)
where (ras,las) = bifold f (la,r) as
(ra,la) = f l a ras
(I'm sure someone else has come up with this before, so I'll just say I
discovered it, not invented it).
Basically, it's a simultaneous left and right fold, passing one value from
the start of the list toward the end, and one from the end toward the start.
It lets you do some interesting stuff, like filter based on positionor other
left-dependent information:
evenIndexed :: [a] - [a]
evenIndexed = fst . bifold alternate (0,[])
where alternate 0 x xs = (x:xs, 1)
alternate 1 _ xs = (xs, 0)
maximums :: (Ord a) = [a] - [a]
maximums [] = []
maximums (a:as) = a : (fst $ bifold (\m a l - if a m then (a:l,a) else
(l,m)) (a,[]) as)
As long as you don't examine the left-to-right value, it can still work on
infinite lists:
ghci take 20 $ evenIndexed [0..]
[0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38]
Also, it can be used for corecursive data (or, at least, doubly-linked
lists):
data DList a = Start { first :: DList a } |
Entry { value :: a, next :: DList a, prev :: DList a } |
End { last :: DList a } deriving (Eq)
ofList :: [a] - (DList a, DList a)
ofList as = (start,end)
where start = Start first
end = End last
(first,last) = bifold mkEntry (start,end) as
mkEntry p v n = let e = Entry v n p in (e,e)
It's just been running around my head all night, so I thought I'd share.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: typehash patch for base = 4 4.4
Hi all,
Typehash 1.4.0.0, the latest version of typehash in hackage, has a cabal
constraint base 4, making it difficult to use with packages that only
support newer base versions.
I sent a patch to fix this to the maintainer for the typehash package
(Lennart Augustsson) on the 16th of November, but haven't heard anything
back - it is possible that he doesn't read the e-mail address I sent it
to, or is no longer interested in maintaining typehash.
Does anyone who would be willing to know Lennart in person to confirm
this? Failing this, does anyone want to be maintainer for the typehash
package? If I don't hear any better ideas, I could simply upload a
version 1.4.0.1 with my split base patch applied, and the maintainer
changed to haskell-cafe@haskell.org.
Best wishes,
Andrew
Original Message
Subject: typehash patch for base = 4 4.4
Date: Tue, 16 Nov 2010 17:55:13 +1300
From: Andrew Miller and...@amxl.com
To: lenn...@augustsson.net
diff -rbud typehash-1.4.0.0/src/Data/TypeHash.hs
typehash-1.4.0.1/src/Data/TypeHash.hs
--- typehash-1.4.0.0/src/Data/TypeHash.hs 2009-10-06 03:43:44.0
+1300
+++ typehash-1.4.0.1/src/Data/TypeHash.hs 2010-11-16 17:43:51.917333177
+1300
@@ -44,7 +44,7 @@
data Type
= Name { typeName :: String }-- Abstract type, or
recursive reference
-| Data { typeName :: String, constrs :: [Constructor] }
+| Data { typeName :: String, dconstrs :: [Constructor] }
deriving (Eq, Ord, Show, Typeable, Data)
type Constructor = (String, [Field])
type Field = (String, Type) -- a unique number is used for missing
field names
@@ -54,7 +54,7 @@
let tn = show $ fullTypeOf x
in case dataTypeRep $ dataTypeOf x of
AlgRep cs | tn `notElem` tns -
- Data { typeName = tn, constrs = map (gConstr (tn:tns) x) cs }
+ Data { typeName = tn, dconstrs = map (gConstr (tn:tns) x) cs }
_ - Name { typeName = tn } -- Use type name for truly
abstract types and recursive types.
gConstr :: (Data a) = [String] - a - Constr - (String, [Field])
Only in typehash-1.4.0.1/src/Data: TypeHash.hs~
diff -rbud typehash-1.4.0.0/typehash.cabal typehash-1.4.0.1/typehash.cabal
--- typehash-1.4.0.0/typehash.cabal 2009-10-06 03:43:44.0 +1300
+++ typehash-1.4.0.1/typehash.cabal 2010-11-16 17:40:55.496953710 +1300
@@ -1,5 +1,6 @@
Name: typehash
-Version: 1.4.0.0
+Cabal-Version: = 1.2
+Version: 1.4.0.1
License: BSD3
Author: Lennart Augustsson
Maintainer: Lennart Augustsson
@@ -10,6 +11,18 @@
Description: Produce a hash for a type that is unique for that type.
The hash takes both actual type names and type structure into
account.
This is useful for checking the type of persisted values.
-Hs-Source-Dirs: src
-Build-Depends: base 4, mtl, bytestring, pureMD5, binary
-Exposed-modules: Data.TypeHash
+
+Flag base4
+Description: Use base-4.*
+Default:True
+
+Library
+ Hs-Source-Dirs: src
+ Build-Depends: mtl, bytestring, pureMD5, binary
+ If flag(base4)
+Build-Depends:
+ base = 4 4.4,
+ syb 0.3
+ else
+Build-Depends: base 4
+ Exposed-modules: Data.TypeHash
Only in typehash-1.4.0.1: dist
diff -rbud typehash-1.4.0.0/src/Data/TypeHash.hs typehash-1.4.0.1/src/Data/TypeHash.hs
--- typehash-1.4.0.0/src/Data/TypeHash.hs 2009-10-06 03:43:44.0 +1300
+++ typehash-1.4.0.1/src/Data/TypeHash.hs 2010-11-16 17:43:51.917333177 +1300
@@ -44,7 +44,7 @@
data Type
= Name { typeName :: String }-- Abstract type, or recursive reference
-| Data { typeName :: String, constrs :: [Constructor] }
+| Data { typeName :: String, dconstrs :: [Constructor] }
deriving (Eq, Ord, Show, Typeable, Data)
type Constructor = (String, [Field])
type Field = (String, Type) -- a unique number is used for missing field names
@@ -54,7 +54,7 @@
let tn = show $ fullTypeOf x
in case dataTypeRep $ dataTypeOf x of
AlgRep cs | tn `notElem` tns -
- Data { typeName = tn, constrs = map (gConstr (tn:tns) x) cs }
+ Data { typeName = tn, dconstrs = map (gConstr (tn:tns) x) cs }
_ - Name { typeName = tn } -- Use type name for truly abstract types and recursive types.
gConstr :: (Data a) = [String] - a - Constr - (String, [Field])
Only in typehash-1.4.0.1/src/Data: TypeHash.hs~
diff -rbud typehash-1.4.0.0/typehash.cabal typehash-1.4.0.1/typehash.cabal
--- typehash-1.4.0.0/typehash.cabal 2009-10-06 03:43:44.0 +1300
+++ typehash-1.4.0.1/typehash.cabal 2010-11-16 17:40:55.496953710 +1300
@@ -1,5 +1,6 @@
Name: typehash
-Version: 1.4.0.0
+Cabal-Version: = 1.2
+Version: 1.4.0.1
License: BSD3
Author: Lennart Augustsson
Maintainer: Lennart Augustsson
@@ -10,6 +11,18 @@
Description: Produce a hash for a type that is unique for that type.
The hash takes both actual type names and type structure into
[arch-haskell] Please update haskell-text in [extra]
Hi, can someone with access to [extra] please update haskell-text to version 0.10.0.0? The old version is blocking other updates, such as haskell-yesod, etc. Take care, Peter ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
