Re: Shipping core libraries with debug symbols
We should merge this fix to the 7.10 branch. On Jan 8, 2015 11:52 PM, Peter Wortmann sc...@leeds.ac.uk wrote: (sorry for late answer) Yes, that's pretty much what this would boil down to. The patch is trivial: https://github.com/scpmw/ghc/commit/29acc#diff-1 I think this is a good idea anyways. We can always re-introduce the data for higher -gn levels. Greetings, Peter On 05/01/2015 00:59, Johan Tibell wrote: What about keeping exactly what -g1 keeps for gcc (i.e. functions, external variables, and line number tables)? On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann sc...@leeds.ac.uk mailto:sc...@leeds.ac.uk wrote: Okay, I ran a little experiment - here's the size of the debug sections that Fission would keep (for base library): .debug_abbrev: 8932 - 0.06% .debug_line: 374134 - 2.6% .debug_frame: 671200 - 4.5% Not that much. On the other hand, .debug_info is a significant contributor: .debug_info(full): 4527391 - 30% Here's what this contains: All procs get a corresponding DWARF entry, and we declare all Cmm blocks as lexical blocks. The latter isn't actually required right now - to my knowledge, GDB simply ignores it, while LLDB shows it as inlined routines. In either case, it just shows yet more GHC-generated names, so it's really only useful for profiling tools that know Cmm block names. So here's what we get if we strip out block information: .debug_info(!block): 1688410 - 11% This eliminates a good chunk of information, and might therefore be a good idea for -g1 at minimum. If we want this as default for 7.10, this would make the total overhead about 18%. Acceptable? I can supply a patch if needed. Just for comparison - for Fission we'd strip proc records as well, which would cause even more extreme savings: .debug_info(!proc):36081 - 0.2% At this point the overhead would be just about 7% - but without doing Fission properly this would most certainly affect debuggers. Greetings, Peter On 03/01/2015 21:22, Johan Tibell wrote: How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release? _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
warn-redundant-constraints present as errors
This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Redundant constraints
I was wrong about binary, sorry. It was just the other three Simon From: Lennart Kolmodin [mailto:kolmo...@gmail.com] Sent: 08 January 2015 20:26 To: Simon Peyton Jones Cc: ghc-devs@haskell.org; Milan Straka; Bill Mitchell (bill.mitch...@hq.bcs.org.uk); Judah Jacobson; Ross Paterson Subject: Re: Redundant constraints 2015-01-07 18:19 GMT+03:00 Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com: Friends I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a = a - a - Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don’t maintain have such warnings (MANY of them in transformers) so I’m ccing the maintainers: o containers o haskeline o transformers o binary I'd like to update binary to not have any unnecessary constraints. I couldn't find any though. commit c409b6f30373535b6eed92e55d4695688d32be9e removes unnecessary constraints from ghc maintained libraries, and silences the redundant-constraints warnings from the other libraries containers, haskeline and transformers. I couldn't find anything related to binary though, nor any warnings in the build log. If there are any, please let me know, or file a bug at http://github.com/kolmodin/binary Thanks! Lennart Enjoy! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
(sorry for late answer) Yes, that's pretty much what this would boil down to. The patch is trivial: https://github.com/scpmw/ghc/commit/29acc#diff-1 I think this is a good idea anyways. We can always re-introduce the data for higher -gn levels. Greetings, Peter On 05/01/2015 00:59, Johan Tibell wrote: What about keeping exactly what -g1 keeps for gcc (i.e. functions, external variables, and line number tables)? On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann sc...@leeds.ac.uk mailto:sc...@leeds.ac.uk wrote: Okay, I ran a little experiment - here's the size of the debug sections that Fission would keep (for base library): .debug_abbrev: 8932 - 0.06% .debug_line: 374134 - 2.6% .debug_frame: 671200 - 4.5% Not that much. On the other hand, .debug_info is a significant contributor: .debug_info(full): 4527391 - 30% Here's what this contains: All procs get a corresponding DWARF entry, and we declare all Cmm blocks as lexical blocks. The latter isn't actually required right now - to my knowledge, GDB simply ignores it, while LLDB shows it as inlined routines. In either case, it just shows yet more GHC-generated names, so it's really only useful for profiling tools that know Cmm block names. So here's what we get if we strip out block information: .debug_info(!block): 1688410 - 11% This eliminates a good chunk of information, and might therefore be a good idea for -g1 at minimum. If we want this as default for 7.10, this would make the total overhead about 18%. Acceptable? I can supply a patch if needed. Just for comparison - for Fission we'd strip proc records as well, which would cause even more extreme savings: .debug_info(!proc):36081 - 0.2% At this point the overhead would be just about 7% - but without doing Fission properly this would most certainly affect debuggers. Greetings, Peter On 03/01/2015 21:22, Johan Tibell wrote: How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release? _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: seq#: do we actually need it as a primitive?
For posterity, the answer is no, and it is explained in this comment: https://ghc.haskell.org/trac/ghc/ticket/5129#comment:2 Edward Excerpts from David Feuer's message of 2015-01-07 11:12:55 -0800: I've read about the inlining issues surrounding Control.Exception.evaluate that seem to have prompted the creation of seq#, but I'm still missing something. Isn't seq# a sthe same as let !a' = a in (# s, a' #) ? David ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Clarification of HsBang and isBanged
I also note that the definition of isBanged is confusing:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
annotations with a missing !, considered banged?
On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell johan.tib...@gmail.com wrote:
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
= HsUserBang -- The user's source-code request
(Maybe Bool) -- Just True{-# UNPACK #-}
-- Just False {-# NOUNPACK #-}
-- Nothing no pragma
Bool -- True = '!' specified
| HsNoBang -- Lazy field
-- HsUserBang Nothing False means the same
as HsNoBang
| HsUnpack -- Definite commitment: this field is strict
and unboxed
(Maybe Coercion) --co :: arg-ty ~ product-ty
| HsStrict -- Definite commitment: this field is strict
but not unboxed
This data type is a bit unclear to me:
* What are the reasons for the following constructor overlaps?
* `HsNoBang` and `HsUserBang Nothing False`
* `HsStrict` and `HsUserBang Nothing True`
* `HsUnpack mb_co` and `HsUserBang (Just True) True`
* Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just True)
True`?
* Is there a difference in what the user wrote in the case of HsUserBang
and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
compiler as opposed to being written by the user (the function
documentation notwithstanding)?
A very related function is isBanged:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
What's the meaning of this function? Is it intended to communicate what
the user wrote or whether result of what the user wrote results in a strict
function?
Context: I'm adding a new StrictData language pragma [1] that makes fields
strict by default and a '~' annotation of fields to reverse the default
behavior. My intention is to change HsBang like so:
- Bool -- True = '!' specified
+ (Maybe Bool) -- True = '!' specified, False = '~'
+ -- specified, Nothing = unspecified
1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Clarification of HsBang and isBanged
I know there was a bug in the parser related to setting the HsBang value,
it could be that this whole area has just not received solid scrutiny
before now.
Alan
On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I also note that the definition of isBanged is confusing:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
annotations with a missing !, considered banged?
On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell johan.tib...@gmail.com
wrote:
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
= HsUserBang -- The user's source-code request
(Maybe Bool) -- Just True{-# UNPACK #-}
-- Just False {-# NOUNPACK #-}
-- Nothing no pragma
Bool -- True = '!' specified
| HsNoBang -- Lazy field
-- HsUserBang Nothing False means the same
as HsNoBang
| HsUnpack -- Definite commitment: this field is
strict and unboxed
(Maybe Coercion) --co :: arg-ty ~ product-ty
| HsStrict -- Definite commitment: this field is
strict but not unboxed
This data type is a bit unclear to me:
* What are the reasons for the following constructor overlaps?
* `HsNoBang` and `HsUserBang Nothing False`
* `HsStrict` and `HsUserBang Nothing True`
* `HsUnpack mb_co` and `HsUserBang (Just True) True`
* Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
True) True`?
* Is there a difference in what the user wrote in the case of HsUserBang
and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
compiler as opposed to being written by the user (the function
documentation notwithstanding)?
A very related function is isBanged:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
What's the meaning of this function? Is it intended to communicate what
the user wrote or whether result of what the user wrote results in a strict
function?
Context: I'm adding a new StrictData language pragma [1] that makes
fields strict by default and a '~' annotation of fields to reverse the
default behavior. My intention is to change HsBang like so:
- Bool -- True = '!' specified
+ (Maybe Bool) -- True = '!' specified, False = '~'
+ -- specified, Nothing = unspecified
1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Redundant constraints
Ha ha ha. Very good, yes! | -Original Message- | From: Michael Sloan [mailto:mgsl...@gmail.com] | Sent: 08 January 2015 00:06 | To: Johan Tibell | Cc: Simon Peyton Jones; Milan Straka; Bill Mitchell | (bill.mitch...@hq.bcs.org.uk); Ross Paterson; ghc-devs@haskell.org | Subject: Re: Redundant constraints | | One option for avoiding the warning without runtime overhead would be | to do something like this: | |f :: Ord a = a - a - Bool | f x y = True | where | _ = x y | | | On Wed, Jan 7, 2015 at 7:27 AM, Johan Tibell johan.tib...@gmail.com | wrote: | I think this probably makes sense, especially since you can silence | the warning when you intend to add an unnecessary constraint. | | I had one thought though: consider an abstract data type with | functions that operates over it. I might want to require e.g Ord in | the definition of a function so I have freedom to change my | implementation later, even though the current implementation doesn't | need Ord. Think of it as separating specification and | implementation. | An example is 'nub'. I initially might implement it as a O(n^2) | algorithm using only Eq, but I might want to leave the door open to | using Ord to create something better, without later having to break | backwards compatibility. | | On Wed, Jan 7, 2015 at 4:19 PM, Simon Peyton Jones | simo...@microsoft.com | wrote: | | Friends | | I’ve pushed a big patch that adds –fwarn-redundant-constraints (on | by | default). It tells you when a constraint in a signature is | unnecessary, e.g. | |f :: Ord a = a - a - Bool | |f x y = True | | I think I have done all the necessary library updates etc, so | everything should build fine. | | Four libraries which we don’t maintain have such warnings (MANY of | them in | transformers) so I’m ccing the maintainers: | | o containers | | o haskeline | | o transformers | | o binary | | | | Enjoy! | | | | Simon | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Clarification of HsBang and isBanged
From looking at the code a bit more I'm pretty sure that only HsUserBang
corresponds to what the user wrote and the remaining constructors are used
to note the actual decision we made (e.g. are we going to unpack). Is that
correct Simon PJ? If that is the case, why isn't this information split
over two data types (which would make functions over HsBang simpler)?
On Thu, Jan 8, 2015 at 9:22 AM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
I know there was a bug in the parser related to setting the HsBang value,
it could be that this whole area has just not received solid scrutiny
before now.
Alan
On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I also note that the definition of isBanged is confusing:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
annotations with a missing !, considered banged?
On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell johan.tib...@gmail.com
wrote:
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
= HsUserBang -- The user's source-code request
(Maybe Bool) -- Just True{-# UNPACK #-}
-- Just False {-# NOUNPACK #-}
-- Nothing no pragma
Bool -- True = '!' specified
| HsNoBang -- Lazy field
-- HsUserBang Nothing False means the same
as HsNoBang
| HsUnpack -- Definite commitment: this field is
strict and unboxed
(Maybe Coercion) --co :: arg-ty ~ product-ty
| HsStrict -- Definite commitment: this field is
strict but not unboxed
This data type is a bit unclear to me:
* What are the reasons for the following constructor overlaps?
* `HsNoBang` and `HsUserBang Nothing False`
* `HsStrict` and `HsUserBang Nothing True`
* `HsUnpack mb_co` and `HsUserBang (Just True) True`
* Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
True) True`?
* Is there a difference in what the user wrote in the case of HsUserBang
and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
compiler as opposed to being written by the user (the function
documentation notwithstanding)?
A very related function is isBanged:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
What's the meaning of this function? Is it intended to communicate what
the user wrote or whether result of what the user wrote results in a strict
function?
Context: I'm adding a new StrictData language pragma [1] that makes
fields strict by default and a '~' annotation of fields to reverse the
default behavior. My intention is to change HsBang like so:
- Bool -- True = '!' specified
+ (Maybe Bool) -- True = '!' specified, False = '~'
+ -- specified, Nothing = unspecified
1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: seq#: do we actually need it as a primitive?
On 08/01/15 10:00, Edward Z. Yang wrote: For posterity, the answer is no, and it is explained in this comment: https://ghc.haskell.org/trac/ghc/ticket/5129#comment:2 Thanks, this is helpful. So we have three potential implementations for evaluate: (1) \x - return $! x (2) \x - (return $! x) = return (3) implemented using seq# (1) and (2) are supposed to be equivalent (by the monad law), but are not in reality, since in (2) evaluate x is always a value. The documentation for 'evaluate' talks about the difference between (1) and (2). Furthermore, it suggests that (2) is a valid implementation. (1) is buggy, as explained in #5129 linked above. However, it doesn't say anything about (2). Would (2) still suffer from #5129? In that case, the docs should be fixed. Also, where can I find the 'instance Monad IO' as understood by GHC? grep didn't find one. Roman ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: seq#: do we actually need it as a primitive?
On 08/01/15 15:42, Roman Cheplyaka wrote: Also, where can I find the 'instance Monad IO' as understood by GHC? grep didn't find one. Found it; it's in libraries/base/GHC/Base.hs. There are two spaces after instance; that's why I didn't find it the first time. Roman ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: seq#: do we actually need it as a primitive?
On Thu, Jan 8, 2015 at 8:42 AM, Roman Cheplyaka r...@ro-che.info wrote: Also, where can I find the 'instance Monad IO' as understood by GHC? grep didn't find one. It's in GHC.Base. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Redundant constraints
On Wed, Jan 07, 2015 at 03:19:15PM +, Simon Peyton Jones wrote: I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a = a - a - Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don’t maintain have such warnings (MANY of them in transformers) so I’m ccing the maintainers: I've fixed some of the warnings in transformers, but there are still 14 of them, triggered by Applicative becoming a superclass of Monad. I can't get rid of those because the package has to build with old GHCs when bootstrapping the compiler. On Wed, Jan 07, 2015 at 04:27:21PM +0100, Johan Tibell wrote: I had one thought though: consider an abstract data type with functions that operates over it. I might want to require e.g Ord in the definition of a function so I have freedom to change my implementation later, even though the current implementation doesn't need Ord. Think of it as separating specification and implementation. I think some of the changes already made are of this sort, exposing details of the GHC implementation, e.g. the changes to the public interface of Array and Ratio. For example, it's probably reasonable to remove the Ix constraint from Data.Array.bounds, but the portable reference implementation of Data.Array.elems requires Ix, even though the GHC implementation doesn't. Similarly a portable implementation of the Functor instance for Array i requires Ix, but the GHC implementation doesn't. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: seq#: do we actually need it as a primitive?
No (2) would not suffer from #5129. Think of type IO a = State# - (State#, a) return x = \s - (s, x) (=) m k s = case m s of (s, r) - k r s (it's a newtype actually, but this will do here). (2) says = \x - (return $! x) = return = \x. \s. case return $! x s of (s1, r) - return r s1 = \x\s. x `seq` case (s,x) of (s1, r) - return r s1 = \x\s. x `seq` (s,x) which is fine. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Roman Cheplyaka | Sent: 08 January 2015 13:42 | To: Edward Z. Yang; David Feuer | Cc: ghc-devs | Subject: Re: seq#: do we actually need it as a primitive? | | On 08/01/15 10:00, Edward Z. Yang wrote: | For posterity, the answer is no, and it is explained in this | comment: | https://ghc.haskell.org/trac/ghc/ticket/5129#comment:2 | | Thanks, this is helpful. | | So we have three potential implementations for evaluate: | | (1) \x - return $! x | (2) \x - (return $! x) = return | (3) implemented using seq# | | (1) and (2) are supposed to be equivalent (by the monad law), but are | not in reality, since in (2) evaluate x is always a value. | | The documentation for 'evaluate' talks about the difference between | (1) and (2). Furthermore, it suggests that (2) is a valid | implementation. | | (1) is buggy, as explained in #5129 linked above. However, it doesn't | say anything about (2). | | Would (2) still suffer from #5129? In that case, the docs should be | fixed. | | Also, where can I find the 'instance Monad IO' as understood by GHC? | grep didn't find one. | | Roman | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Clarification of HsBang and isBanged
I’m glad you are getting back to strictness.
Good questions.
I’ve pushed (or will as soon as I have validated) a patch that adds type
synonyms, updates comments (some of which were indeed misleading), and changes
a few names for clarity and consistency. I hope that answers all your
questions.
Except these:
· Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
True) True`? Because the former is implementation generated but the latter is
source code specified.
· Why isn't this information split over two data types. Because
there’s a bit of overlap. See comments with HsSrcBang
Simon
From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 08 January 2015 07:36
To: ghc-devs@haskell.org
Cc: Simon Peyton Jones
Subject: Clarification of HsBang and isBanged
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
= HsUserBang -- The user's source-code request
(Maybe Bool) -- Just True{-# UNPACK #-}
-- Just False {-# NOUNPACK #-}
-- Nothing no pragma
Bool -- True = '!' specified
| HsNoBang -- Lazy field
-- HsUserBang Nothing False means the same as
HsNoBang
| HsUnpack -- Definite commitment: this field is strict and
unboxed
(Maybe Coercion) --co :: arg-ty ~ product-ty
| HsStrict -- Definite commitment: this field is strict but
not unboxed
This data type is a bit unclear to me:
* What are the reasons for the following constructor overlaps?
* `HsNoBang` and `HsUserBang Nothing False`
* `HsStrict` and `HsUserBang Nothing True`
* `HsUnpack mb_co` and `HsUserBang (Just True) True`
* Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just True)
True`?
* Is there a difference in what the user wrote in the case of HsUserBang and
HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the compiler
as opposed to being written by the user (the function documentation
notwithstanding)?
A very related function is isBanged:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True
What's the meaning of this function? Is it intended to communicate what the
user wrote or whether result of what the user wrote results in a strict
function?
Context: I'm adding a new StrictData language pragma [1] that makes fields
strict by default and a '~' annotation of fields to reverse the default
behavior. My intention is to change HsBang like so:
- Bool -- True = '!' specified
+ (Maybe Bool) -- True = '!' specified, False = '~'
+ -- specified, Nothing = unspecified
1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build gotchas
On 1. 1. 2015 19:01, Martin Foster wrote: Hello all, I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line. I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them: * The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just pacman -Sy pacman-mirrors before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful. This is an unfortunate, but temporary situation. The next MSYS2 installer will come with updated mirror lists. I don't know what's the policy on including this kind of information on the wiki. * That page mentions If you see errors related to fork(), try closing and reopening the shell - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-packages, ie by running pacman --needed -S bash pacman msys2-runtime, then closing re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages. This may be true for the GHC guide, but AFAIK if you decide to install other packages, you may still encounter fork errors. The installation process is taken care of by updating bash, pacman and the runtime separately, but subsequent invocations of MSYS2 programs could still fail due to newly installed MSYS2 libraries (if any). * And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so... I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run cabal install -j --prefix=/usr/local alex happy, of the form Could not find module `...': There are files missing in the `...' package. I noticed that the cabal output made reference to C:\Users\Martin\AppData\Roaming\cabal\, so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, %APPDATA%\cabal, there were also files left over in %APPDATA%\ghc. Once I removed that directory as well, things started working again - but it took me a lot of time frustration to get there. I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great. It seems to me that, ideally, the build GHC inside MSYS procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea? If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it. I had problems with this also, so I definitely support mentioning these two on the wiki. If we ever get to having a ghc package for MSYS2, it will use $HOME instead of $APPDATA, but that won't actually help with the problem of MSYS2 re-install not cleaning everything the build left behind. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: seq#: do we actually need it as a primitive?
Then why was the primop introduced? On 08/01/15 17:05, Simon Peyton Jones wrote: No (2) would not suffer from #5129. Think of type IO a = State# - (State#, a) return x = \s - (s, x) (=) m k s = case m s of (s, r) - k r s (it's a newtype actually, but this will do here). (2) says = \x - (return $! x) = return = \x. \s. case return $! x s of (s1, r) - return r s1 = \x\s. x `seq` case (s,x) of (s1, r) - return r s1 = \x\s. x `seq` (s,x) which is fine. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Roman Cheplyaka | Sent: 08 January 2015 13:42 | To: Edward Z. Yang; David Feuer | Cc: ghc-devs | Subject: Re: seq#: do we actually need it as a primitive? | | On 08/01/15 10:00, Edward Z. Yang wrote: | For posterity, the answer is no, and it is explained in this | comment: | https://ghc.haskell.org/trac/ghc/ticket/5129#comment:2 | | Thanks, this is helpful. | | So we have three potential implementations for evaluate: | | (1) \x - return $! x | (2) \x - (return $! x) = return | (3) implemented using seq# | | (1) and (2) are supposed to be equivalent (by the monad law), but are | not in reality, since in (2) evaluate x is always a value. | | The documentation for 'evaluate' talks about the difference between | (1) and (2). Furthermore, it suggests that (2) is a valid | implementation. | | (1) is buggy, as explained in #5129 linked above. However, it doesn't | say anything about (2). | | Would (2) still suffer from #5129? In that case, the docs should be | fixed. | | Also, where can I find the 'instance Monad IO' as understood by GHC? | grep didn't find one. | | Roman | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
Dear Simon, Am Donnerstag, den 04.12.2014, 08:56 + schrieb Simon Marlow: no, does not help, as -lgmp is already passed to gcc by ghc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -o linker_unload linker_unload.o -L/data1/ghc-builder/ghc-master/libraries/base/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/integer-gmp2/dist-install/build -L/data1/ghc-builder/ghc-master/libraries/ghc-prim/dist-install/build -L/data1/ghc-builder/ghc-master/rts/dist/build /tmp/ghc26637_1/ghc26637_4.o /tmp/ghc26637_1/ghc26637_6.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmp rim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_run NonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase_469rOtLAqwTGFEOGWxSUiQ -lHSinteg_21cuTlnn00eFNd4GMrxOMi -lHSghcpr_FgrV6cgh2JHBlbcx1OSlwt -lHSrts_debug -lCffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads but due to --no-needed, and linker_unload indeed not requiring any symbols from gmp, the linker does not link it. Ok, I was afraid of that. The test needs to be fixed to explicitly dlopen(libgmp). I'll take a look at it today. this is still one of the test suite failures showing up at the performance builders. Would you mind having a look? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Redundant constraints
2015-01-07 18:19 GMT+03:00 Simon Peyton Jones simo...@microsoft.com: Friends I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a = a - a - Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don’t maintain have such warnings (MANY of them in transformers) so I’m ccing the maintainers: o containers o haskeline o transformers o binary I'd like to update binary to not have any unnecessary constraints. I couldn't find any though. commit c409b6f30373535b6eed92e55d4695688d32be9e removes unnecessary constraints from ghc maintained libraries, and silences the redundant-constraints warnings from the other libraries containers, haskeline and transformers. I couldn't find anything related to binary though, nor any warnings in the build log. If there are any, please let me know, or file a bug at http://github.com/kolmodin/binary Thanks! Lennart Enjoy! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
