Re: .gitignore of tests

[Herbert Valerio Riedel]

Hello!

On 2014-07-29 at 08:25:15 +0200, Dr. ERDI Gergo wrote:
> Is there a good reason we have a single monolithic .gitignore file in
> testuiste/ instead of one per directory? It just feels so
> unnecessarily burdensome to maintain it compared to just putting four
> lines in a new .gitignore file...

That's a good question I've been wondering about as well. I recently
merged a few single .gitignore files I found in testsuite/ sub-folders
into the main testsuite/.gitignore file it was rather inconsistent to
have most stuff listed in the monolithic testsuite/.gitignore file and
just a few deliberate .gitignores in a few sub-folders:

  
http://git.haskell.org/ghc.git/commitdiff/767b9ddf7d2ea2bb99d49372c79be129fc2058ce

The other issue is tooling. Some Git front-ends such as
http://magit.github.io/ don't even recognize non-top-level .gitignore
files (yet), and certainly don't offer to create one if they don't find
it in the current sub-folder (instead magit just adds it to the
top-level gitignore file)

Also, I'm not sure if having .gitignore files sprinkled all over the
source-tree instead of having just a few .gitignore files would be so
much better, as in order to compute the "effective .gitignore", you have
to consider the union of all existing .gitignore files up to the
top-level folder (while not crossing Git repo boundaries).

However, we *can* switch to a scheme where we use many little per-folder
.gitignore files, but everyone would have to agree to follow that new
scheme, or we'll end up with a mess of confusing possibly overlapping
.gitignore files.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

redundant rts/StgPrimFloat decodeDouble?

[Herbert Valerio Riedel]

Hello *,

While working on integer-gmp2 I noticed that there seems to be redundant
code between rts/StgPrimFloat.c and integer-gmp. Specifically, there's a

  void
  __decodeDouble_2Int (I_ *man_sign, W_ *man_high, W_ *man_low, I_ *exp,
   StgDouble dbl);

C implementation which does some low-level bit-fiddling on the IEEE
representation instead of just using the more portable standard frexp()
function, like I'm doing in integer-gmp2, e.g.:

  HsInt ​integer_gmp_decode_double (const HsDouble x, HsInt64 *const mantisse)
  ​{
   ​ if (x) {
​  int exp = 0;
  *mantisse = (HsInt64)scalbn(frexp(x, &exp), DBL_MANT_DIG);
 ​ return exp-DBL_MANT_DIG;
   ​ } else {
​  *mantisse = 0;
 ​ return 0;
   ​ }
  ​}

A similiar operation exists in integer-gmp/cbits/float.c

So here's my questions:


 1) Is there any reason/value in doing low-level IEEE bit-fiddling instead of
just delegating to the C99/POSIX compliant frexp(3) operations?

 2) Specifically, `decodeDouble_2Int` seems to be dead-code. I'd like to
instead move the 

  HsInt ​integer_gmp_decode_double (const HsDouble x, HsInt64 *const
  mantisse);

which I currently import as

  #if WORD_SIZE_IN_BITS == 32
   foreign import prim "integer_gmp_cmm_decode_double" 
 cmm_decode_double :: Double# -> (# Int64#, Int# #)
  #elif WORD_SIZE_IN_BITS == 64
   foreign import prim "integer_gmp_cmm_decode_double" 
 cmm_decode_double :: Double# -> (# Int#, Int# #)
  #endif

   based on the size of `Int#` into rts/PrimOps.cmm & rts/StgPrimFloat.c
   as that may allow me to avoid any C-- in integer-gmp2 altogether (as I
   only need to go via C-- to return an unboxed pair)


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Overlapping and incoherent instances

[Herbert Valerio Riedel]

On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>
> Is the syntax somewhat flexible in where the pragma can be placed?
> For example, some might prefer
>
>   {-# OVERLAPPING #-}
>   instance Show [Char] where …

This variant may also be more convenient in cases where you need to
CPP-guard that pragma, as it's on a separate line.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Overlapping and incoherent instances

[Herbert Valerio Riedel]

On 2014-07-29 at 14:13:22 +0200, Richard Eisenberg wrote:
> Are folks very keen to have *warning-free* compilation on several GHC
> versions? Personally, I would aim for warning-free compilation on a
> most recent version, and otherwise successful compilation on older
> versions.

IMO: In typical build-bot configurations where you test against multiple
GHC versions you often the warnings to be turned into errors via
-Werror, as otherwise you wouldn't notice them. After all, warnings are
hints about something that may need to be looked at, and if they turn
out to be harmless, the specific warning can be turned off on a
case-by-case basis (which alas, in GHC's case is a bit difficult, as for
instance, you can't turn off a specific warning for a single declaration
only, but only for a whole module)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

[Herbert Valerio Riedel]

Hello Simon,

On 2014-07-31 at 10:53:20 +0200, Simon Marlow wrote:

[...]

>>  rts: add Emacs 'Local Variables' to every .c file
>>
>>  This will hopefully help ensure some basic consistency in the forward by
>>  overriding buffer variables. In particular, it sets the wrap length, the
>>  offset to 4, and turns off tabs.
>
> I'm not a huge fan of this.  Is there a way to do this without adding
> the spam to the end of every source file?  Also it only works for
> emacs, what if the vim folks want to add their own spam?

I recently stumbled over

  
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8d0a1a6bc05af7edd25b15ce9159025036b636ff

which lead me to read up on its effect which is explained in more detail in

  
https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html

| The usual way to define directory-local variables is to put a file
| named .dir-locals.el1 in a directory. Whenever Emacs visits any file
| in that directory or any of its subdirectories, it will apply the
| directory-local variables specified in .dir-locals.el, as though they
| had been defined as file-local variables for that file (see File
| Variables).

So maybe that's a better option?


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Question about BangPatterns semantics/documentation

[Herbert Valerio Riedel]

The GHC User's Guide[1] says:

| There is one (apparent) exception to this general rule that a bang
| only makes a difference when it precedes a variable or wild-card: a
| bang at the top level of a let or where binding makes the binding
| strict, regardless of the pattern. (We say "apparent" exception
| because the Right Way to think of it is that the bang at the top of a
| binding is not part of the pattern; rather it is part of the syntax of
| the binding, creating a "bang-pattern binding".) For example:
|
|  let ![x,y] = e in b
|
| is a bang-pattern binding. Operationally, it behaves just like a case
| expression:
|
|  case e of [x,y] -> b


However, the following two functions are not equivalent after
compilation to Core:

  g, h :: (Int -> Int) -> Int -> ()
  g f x = let !y = f x in ()
  h f x = case f x of y -> ()

In fact, compilation results in

  g = \ (f_asi :: Int -> Int)
(x_asj :: Int) ->
case f_asi x_asj of _ [Occ=Dead] { I# ipv_sKS -> () }
   
  h = \ _ [Occ=Dead] _ [Occ=Dead] -> ()

Is the documentation inaccurate/incomplete/I-missed-something or is the
implementation to blame?

Cheers,
  hvr


 [1]: http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/bang-patterns.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Moving Haddock *development* out of GHC tree

[Herbert Valerio Riedel]

Hi Mateusz,

I'm mostly interested in understanding the Git-level/workflow changes,
so here's a few questions to improve my understanding of what's changing
related to Git:

On 2014-08-08 at 07:25:01 +0200, Mateusz Kowalczyk wrote:
[...]

> I do all the work and I think it's a 1 line change in sync-all when
> transition is ready.

What change in ./sync-all are you thinking about specifically? (or
alternatively: what about those not using ./sync-all anymore?)

[...]

> * GHC itself checks out Haddock as a submodule as it does now. The only
> difference is that it points at whatever commit worked last. Let us
> assume it is the Haddock 2.14.3 release commit. The vital difference
> from current state is that GHC will no longer track changes in master
> branch.
>
> * Now when GHC API changes things proceed as they normally do: whoever
> is responsible for the changes, pops into the Haddock submodule applies
> the patches necessary for Haddock to build with HEAD and everyone is
> happy. What does *not* happen is these patches don't go into master: I
> ignore them and keep working with 7.8.3.

Just to clarify, as the last sentence contains a double-negation: GHC
devs continue pushing to github.com/haddock.git's `master` branch to
keep Haddock building with GHC HEAD? It's just that the Haddock
development proper happens in a branch other than `master` from now on?

If I get this right, there will be a branch (`master`?) that's kept compatible 
with
GHC HEAD, then there's a branch where new Haddock features are
implemented (name?), and then there are stable branches for past
releases (in the spirit of the current `v2.14`)

So the only new thing would be a new `haddock-next` (or whatever you'd
call that) branch, and `master` will just be on life-support for GHC
HEAD until the next major GHC release is around the corner?

[...]

> If I receive some patches I was promised then I will then make a 2.14.4
> bugfix/compat release make sure that master is up to date and then
> create something like GHC-tracking branch from master and track that. I
> will then abandon that branch and not push to it unless it is GHC
> release time. The next commit in master will bring Haddock to a state
> where it works with 7.8.3: yes, this means removing all new API stuff
> until 7.10 or 7.8.4 or whatever. GHC API changes go onto GHC-tracking
> while all the stuff I write goes master. When GHC makes a release or is
> about to, I make master work with that and make GHC-tracking point to
> that instead.

This paragraph confuses me a bit about which haddock branch is used for
what. Can you maybe enumerate all haddock branches in the new scheme
with their purpose?

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Moving Haddock *development* out of GHC tree

[Herbert Valerio Riedel]

On 2014-08-08 at 09:42:14 +0200, Simon Hengel wrote:
> On Fri, Aug 08, 2014 at 09:00:21AM +0200, Herbert Valerio Riedel wrote:
>> Just to clarify, as the last sentence contains a double-negation: GHC
>> devs continue pushing to github.com/haddock.git's `master` branch to
>> keep Haddock building with GHC HEAD? It's just that the Haddock
>> development proper happens in a branch other than `master` from now on?
>
> From my perspective I would prefer to use `master` for Haddock
> development and use a branch with some other name for GHC development.
> My main motivation here is that as a contributor to Haddock "I expect
> the latest code to be on `master`, and I would use it as a base when
> developing new features".

Just a minor nitpick (but I agree with having `master` used for hosting
active Haddock development): "latest code" might not be a canonical
concept, as there will be "latest code that works with GHC HEAD", and
"latest code that works with last released GHC"

> Alternatively, maybe use `master` for both Haddock and GHC development,
> but push to different remotes (say use
> http://git.haskell.org/haddock.git for GHC development and
> https://github.com/haskell/haddock for Haddock development).  I think
> this is what we already do for e.g. `containers`.

I'd rather reduce the number of doubled repositories (not the least to
simplify the mirroring setup) to avoid confusion about where things
live/need to be pushed to.

If this is just an alpha-conversion modulo thing, then let's just call
the new branch for GHC HEAD simply `ghc-head` (or something like that)
and keep hosting it in github.com/haskell/haddock.git, and have GHC HEAD
developers push to that instead (fwiw, you can specify the default
branch in .gitmodules, which some few Git tools honor).

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can Phabricator be made to understand git better?

[Herbert Valerio Riedel]

On 2014-08-10 at 12:17:56 +0200, Johan Tibell wrote:

[...]

> First, doing that was in itself a bit of a pain. 'arc diff' didn't do the
> right thing and included some random commit(s) instead of my single commit
> in my feature branch. Perhaps it tried to diff against origin/master or
> something, which doesn't make any sense if you know how git is meant to be
> used (doing that would imply that you have to constantly sync with upstream
> to create a patch.) I eventually got it to used the right commit by doing
> 'arc diff `.

While this doesn't answer your question (I'm looking forward to Austin
chiming in to answer as I'd like to understand 'arc diff' better
myself), I've been using 

  arc which

myself before performing 'arc diff's to reduce my surprise/confusion
about which commits 'arc diff' will effectively pick.

HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Moving Haddock *development* out of GHC tree

[Herbert Valerio Riedel]

On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote:

[...]

> I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most
> sense but IIRC Herbert had some objections as it had been used in the
> past for something else, but maybe he can pitch in.

I had no objections at all to that name, 'ghc-head' is fine with me :-)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Moving Haddock *development* out of GHC tree

[Herbert Valerio Riedel]

On 2014-08-16 at 16:59:51 +0200, Mateusz Kowalczyk wrote:

[...]

> Herbert kindly updated the sync-all script that
> defaults to the new branch so I think we're covered. 

Minor correction: I did not touch the sync-all script at all. I merely
declared a default branch in the .gitmodules file:

  
http://git.haskell.org/ghc.git/commitdiff/03a8003e5d3aec97b3a14b2d3c774aad43e0456e

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Wired-in data-constructors with UNPACKed fields

[Herbert Valerio Riedel]

Hello *,

I'm a bit stuck with the wired-in type aspect of integer-gmp2 and was
hoping someone with more experience in this area could provide direction
on how to properly register the data definition

  data Integer  = SI#Int#
| Jp# {-# UNPACK #-} !BigNat
| Jn# {-# UNPACK #-} !BigNat
   
  data BigNat = BN# ByteArray#

with compiler/prelude/TysWiredIn.lhs

Right now I'm getting the Lint-failure 

Unfolding of sqrInteger
  : Warning:
  In the expression: $wsqrBigNat dt
  Argument value doesn't match argument type:
  Fun type: ByteArray# -> BigNat
  Arg type: BigNat
  Arg: dt

where

  sqrBigNat :: BigNat -> BigNat

which seems to be caused by the UNPACK property not being handled
correctly.



The full error message can be found at

  
http://git.haskell.org/ghc.git/commitdiff/13cb42bc8b6b26d3893d4ddcc22eeab36d39a0c7

and the other half of the integer-gmp2 patch can be found at

  
http://git.haskell.org/ghc.git/commitdiff/b5ed2f277e551dcaade5837568e4cbb7dd811c04

or alternatively

  https://phabricator.haskell.org/D82


Thanks in advance,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Wired-in data-constructors with UNPACKed fields

[Herbert Valerio Riedel]

Hello Simon,

On 2014-08-19 at 00:01:17 +0200, Simon Peyton Jones wrote:

[...]

> But you can probably write the code in such a way as to be mostly
> independent (eg explicit UNPACK rather than rely on
> -funbox-strict-fields), or assume that some things won't happen
> (e.g. souce module will not be compiled with
> -fomit-interface-pragmas).  See MkId.mkDataConRep.

I was under the impression that even -O0 vs -O1+ makes a huge
difference:

As given the following program,

  {-# LANGUAGE MagicHash #-}
  module M where
  import GHC.Exts
  data T0 = C0 ByteArray#
  data T1 = C1 {-# UNPACK #-} !T0
  | C2 {-# UNPACK #-} !Int
  | C3 !Int
  | C4 Int

compilation with

  $ ../inplace/bin/ghc-stage2  -fforce-recomp  -ddump-types -O1 -c M.hs 
  TYPE SIGNATURES
  TYPE CONSTRUCTORS
data T0 = C0 ByteArray#
data T1
  = C1 {-# UNPACK #-}T0
  | C2 {-# UNPACK #-}Int
  | C3 {-# UNPACK #-}Int
  | C4 Int
  COERCION AXIOMS
  Dependent modules: []
  Dependent packages: [base, ghc-prim, integer-gmp2]

has everything but C4 unpacked as expected, but when using -O0, nothing
is UNPACKed at all:

  $ ../inplace/bin/ghc-stage2  -fforce-recomp  -ddump-types -O0 -c M.hs 
  TYPE SIGNATURES
  TYPE CONSTRUCTORS
data T0 = C0 ByteArray#
data T1 = C1 !T0 | C2 !Int | C3 !Int | C4 Int
  COERCION AXIOMS
  Dependent modules: []
  Dependent packages: [base, ghc-prim, integer-gmp2]

...am I interpreting the output `-ddump-types` incorrectly?


PS: adding a '!' in front of the 'ByteArray#' field in `T0` is not
supposed to have any effect on primitive types, is it? If so, should
GHC warn about the redundant '!'?

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: deleting branches

[Herbert Valerio Riedel]

On 2014-09-10 at 11:53:05 +0200, Simon Peyton Jones wrote:
> I accidentally created a branch (in the main repo) called
>origin/origin/wip/new-flatten-skolems-Aug14
> I was trying to make a local branch to track the existing
> origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a
> local branch called origin/wip/new-flatten-skolems-Aug14, which I then
> pushed, creating the one above.
> It's quite confusing to me that branches (listed with git branch -av) have 
> names like
>wip/rae
> and
>remotes/origin/wip/rae
> I suspect that the "remotes/origin" part isn't really part of the name
> of the branch at all, even though it is not syntactically
> distinguished.


> Anyway, I'd like to delete that branch from the main repo on the
> server, but I don't know how to do so.  I tried

Here's the problem: you are not allowed to delete anything outside the
"wip/" namespace (partly because we don't want you do delete a branch
like "ghc-7.8" or "master", and partly because the submodule gitlink
integrity check assumes that all branches outside "wip/" are to exist
forever)

however, here's how you'd usually delete that *remote* branch, if you
were allowed to (and what I've just done for you, as I have the
necessary perms being an Git admin):

   git push origin :origin/wip/new-flatten-skolems-Aug14


'git branch -D' deletes only your local branches


In the future, we will restrict the ability to create new branches
outside the "wip/" namespace to avoid such mistakes
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Herbert Valerio Riedel]

On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote:
> Forwarding this & my reply to the ML as well,
>
>
> On 22/09/14 14:27, David Luposchainsky wrote:
>> +1. While you're at it, you may also want to consider allowing
>> leading commas for the folks that write their exports/records "the
>> other way round"
> Sure. Both styles are common in the wild, so that makes sense.

+1 (I'd even say that leading-comma style is the predominant one these
days thanks to [1] et al.)


Let's be a bit more conrete. Where everywhere shall leading+trailing
commas be supported, here's a few places OTTOMH, where comma-separated
entities occur which may or may not benefit from this treatment:

 - list-syntax (+ even in pattern position?)

 - module import/export list

 - record syntax (+ patterns?)

 - pattern-guards

 - language pragmas

 - ...?


 [1]: https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md
 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Herbert Valerio Riedel]

On 2014-09-24 at 08:50:22 +0200, Edward Kmett wrote:
> I'm personally of the "it should be a language extension like everything
> else" mindset. 

Me too. Mostly for being able to have more useful error messages with
older GHCs and other Haskell parsers. 

Because if it's a lang-ext pragma, you have to specify it somewhere
explicitly ({-# LANGUAGE .. #-} and/or {other,default}-extenions in the
cabal file), and if the parser used doesn't know that extension you get
a more useful hint pointing you directly at your problem if you throw
spurious-commas at a Haskell parser which doesn't support that extension
(yet), or with Cabal involved, you'd even get a error message that the
current compiler doesn't support that extension.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Herbert Valerio Riedel]

On 2014-09-25 at 11:18:01 +0200, Simon Peyton Jones wrote:

> That would suggest continuing to make extra commas illegal in literal
> lists, for now anyway.  That’s a conservative choice, which is usually
> the side to err on when it’s a toss-up.

I'd just like to point out, that lists are something that you may want
to tweak regularily in code (while tuple are rather fixed-size entities whose
size is extended less frequently)

Consider the following JSON example:

foo = object [
   "key1" .= True,
   "key2" .= 123,
   "key3" .= (),
   ]

This is code where I often tend to add/remove lines, and ExtraCommas
would greatly reduce the diff-noise, and which I really miss from
languages such as Python which allow me to use trailing commas.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Herbert Valerio Riedel]

On 2014-09-25 at 13:34:16 +0200, Daniel Trstenjak wrote:

[...]

> One compromise could be, that additional commatas in literal lists
> are only allowed at the beginning and at the end.

...another idea could be to make it a separate Pragma
(e.g. ExtraCommasLists) if there's a chance of ListSections (which would
conflict with this) becoming a reality.

> Then your use case would work and also something like:
>
>abc = [ 
>   -- a
>   , a
>   -- b
>   , b
>   -- c
>   , c
>   ]

I'd probably prefer leading-comma over trailing-comma style anyway (as
I've grown to like it over the years).

> I think that are the main uses of additional commatas in literal lists
> and I can't see that someone really wants a list literal like '[,3,,4,]',
> so wrongly reading it as a list section shouldn't be an issue.

Yeah, I don't care much about extra middle-commas either. Personally,
I'd be already happy with just trailing & leading extra-comma support.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: tar --help is failing on Solaris.

[Herbert Valerio Riedel]

On 2014-09-27 at 21:46:13 +0200, Karel Gardas wrote:
> Hi Mikhail,
>
> On 09/27/14 09:09 PM, Mikhail Glushenkov wrote:
>> On 27 September 2014 20:19, Karel Gardas  wrote:
>>>
>>> [...]
>>> Could you be so kind and revert this patch or fix it to also work on
>>> Solaris? For Solaris the change should be easy, simply if you invoke
>>> Solaris' tar with --help, it'll fail with exit code 1 and help message
>>> printed into the stderr. If you are curious if it supports --format, then
>>> no.
>>
>> Should be fixed now. Thanks for the heads-up!
>
> Have you already pushed? I don't see it fixed on my end yet:

fyi, libraries/Cabal is a submodule, so here's what you should do,
(assuming you've ghc's checkout is at its latest state):


  # update/checkout submodule to latest commit from Cabal's master branch
  git submodule update --remote libraries/Cabal

  # test ./validate still works

  # record submodule update in git index
  git add libraries/Cabal

  # create commit, and make sure the commit msg contains the 
  # magic word "submodule"
  git commit 

  # ...
  git push



HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Herbert Valerio Riedel]

Hello!

I can only address a small subset of your comments as I don't usually
develop on Windows and hence lack any significant Windows experience...

On 2014-09-27 at 23:04:38 +0200, Gintautas Miliauskas wrote:

[...]

> 2. Since the msys2 setup instructions are so simple and linear, perhaps it
> would be even better to put them in a shellscript and check that in? Then
> the wikipage would turn into a one-liner.

Fwiw, I recently tried msys2, but after wasting several hours I simply
couldn't get it to work in a way where I could ssh (tried Freesshd and
Winsshd) into an MSYS2 environemnt.

Then I simply installed Cygwin against the recommendation, and then I
finally got a working ssh-able environment with a few steps,
which roughly where OTTOMH:

 - Install cygwin (make sure 'wget' and 'openssh' gets installed),
 - grab https://github.com/transcode-open/apt-cyg and place
   into /usr/local/bin/
 - "cygrunsrv" in order to install sshd service
 - allow 'sshd.exe' in Windows-firewall settings

from now on the graphical Windows console/deskopt isn't required anymore
(which was my primary goal). Everything else can be done headless/remote
via ssh:

 - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3
 - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's
   PATH via ~/.bash_profile or similiar
 - follow similiar steps to grab cabal and install alex/happy like for
   MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32`
   to cabal, though.
 - apt-cyg install automake git
 - clone and build ghc as if it was MSYS2


Long-story short, if it wasn't for Cygwin, I wouldn't have been able to
clean up after some of the Windows breakage I caused recently. It'd be
interesting though if there was a way to `ssh` directly (with a sane
terminal-emulation) into an MSYS2 environment capable of building GHC.


> 3. Why is ghc-tarballs a git repository? That does not seem very wise. 
[...]
> Could we have a stable folder under haskell.org/ to put the files in, to
> make sure that they never go away, and just wget/curl them from there?

http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887


> 8. A broader question: what general approach to ghc on Windows shall we
> take? 
[...]
> I think it would make sense to be consistent with the Linux builds; we
> don't bundle compilers with those. In that sense msys2 would be like
> another distribution.

I'd like that...

> 9. If I understand correctly, one other thing to consider before dropping
> ghc-tarballs is that Windows ghc still needs GCC utilities (like cpp) to
> function properly, 
[...]
Fwiw, at least `cpp` could in theory be replaced by `cpphs`
[...]

> 10. Following the idea in (8), I tried to build ghc using the mingw gcc
> provided by msys2 instead of the one in ghc-tarballs. It was a bit weird. I
> had to hack configure.ac to disable use of ghc-tarballs and try to use
> system tools. How about a configure option to enable/disable use of
> ghc-tarballs? 

Fwiw, Cygwin also provides mingw-gcc (cross)compiler packages to
install. So the same could work on Cygwin...

> 11. A build with the host gcc failed. I think the cause is that it is too
> new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of
> the currently checked in GMP (libraries/integer-gmp) fails because a
> utility used in the build process segfaults. I tried upgrading gmp from
> 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch
> used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One
> of the advantages of tracking msys2's gcc would be that we would notice
> such breakage earlier. Shall I open an issue?

The patched in-tree GMP lib isn't necessary anymore with the rewritten
integer-gmp2 package (which was one of the motivations to do the rewrite
in the first place).


[...]

> Might be a good idea to put in a guard in the configure script to warn
> if a cygwin gcc is detected (or add explicit support for
> it). Actually, looks like there's already a related issue open,
> although I'm not quite sure what the scope is there (#8842
> , thanks Thomas).

It'd be great if one couldn't only use Cygwin as a `build`-environment,
but also as the `host`-environment you compile for.

> 14. The test runner assumes native Windows Python, but it's only a few
> small changes away from working fine on the python2 provided by msys2,
> which would cut another external build dependency. Could someone review and
> merge my patches (#9604 ,
> #9626 )? Thanks.

Fwiw, the test-runner seems to work fine with the Cygwin-provided Python
interpreter.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Aliasing current module qualifier

[Herbert Valerio Riedel]

Hello *,

Here's a situation I've encountered recently, which mades me wish to be
able to define a local alias (in order to avoid CPP use). Consider the
following stupid module:


module AnnoyinglyLongModuleName
   ( AnnoyinglyLongModuleName.length
   , AnnoyinglyLongModuleName.null
   ) where
 
length :: a -> Int
length _ = 0
 
null :: a -> Bool
null = (== 0) . AnnoyinglyLongModuleName.length


Now it'd be great if I could do the following instead:

module AnnoyinglyLongModuleName (M.length, M.null) where
 
import AnnoyinglyLongModuleName as M -- <- does not work
 
length :: a -> Int
length _ = 0
 
null :: a -> Bool
null = (== 0) . M.length

However, if I try to compile this, GHC complains about

AnnoyinglyLongModuleName.hs:4:1:
   Bad interface file: AnnoyinglyLongModuleName.hi
   AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such 
file or directory)

while GHCi tells me:

Module imports form a cycle:
  module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports 
itself


Is there some other way (without CPP) to create a local alias for the
current module-name? If not, is there a reason GHC couldn't support this
special case of self-aliasing the current module name?


PS: Alternatively, this could be done as a language extension but that'd
require extending the Haskell grammar:

module AnnoyinglyLongModuleName as M (M.length, M.null) where


Cheers,
   hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Aliasing current module qualifier

[Herbert Valerio Riedel]

On 2014-09-29 at 10:43:28 +0200, Andreas Abel wrote:
> Indeed, being able to introduce a short name for the current module,
> or having a fixed short name like 'This' or 'Self' would be neat.
>
> The standard workaround for your example would be
>
>   import Prelude hiding (length,null)

That won't work though, because what I failed to mention is that I
needed this (while avoiding CPP) to cope with external modules growing
their exports lists, such as Data.Foldable starting to export 'length'
and 'null' in base-4.8.0.0

Moreover, hiding a non-existent symbol is a warning in recent GHC's but
a hard error in older GHCs, so that's not an option either if you want
to avoid CPP, support GHCs back to 7.0, and be -Werror-clean.

More generally, 'hiding'-imports aren't robust in terms of
forward-compatibility.

>
> Did you try a .hs-boot file with your self-import trick?

Not yet
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a)

[Herbert Valerio Riedel]

Hello Austin,

As this is already the 2nd time I broke nofib w/o noticing... can we
please add building (not necessarily running, i.e. NoFibRuns=0 would be
enough) nofib to the Phabricator build-process?

Cheers,
  hvr

On 2014-09-29 at 11:11:56 +0200, Joachim Breitner wrote:

[...]

> Am Sonntag, den 28.09.2014, 13:07 + schrieb g...@git.haskell.org:
>> commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa
>> Author: Herbert Valerio Riedel 
>> Date:   Sun Sep 28 13:02:53 2014 +0200
>> 
>> Extend `Foldable` class with `length` and `null` methods

[...]

>
> this broke nofib:

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: sync-all

[Herbert Valerio Riedel]

On 2014-10-02 at 09:49:11 +0200, Simon Peyton Jones wrote:
> Herbert says (in bold font) "do not ever use sync-all", in this post 
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/.
>
> If that's really true, we should either nuke it altogether, or change
> it to do something correct.  The idea that it might "set up your tree
> in subtly different ways" is alarming.

To clarify what I mean by that:

For users just wanting to clone ghc.git now and just wanting to keep
their tree updated, I'd recommend doing the following one-shot
convenience configuration setup (see [1] for more details):

  git config --global alias.pullall '!f(){ git pull "$@" && git submodule 
update --init --recursive; }; f'
 
And then clone simply via

  git clone --recursive http://ghc.haskell.org/ghc.git

(or use https:// or git:// or whatever) and to keep the tree simply use

  git pullall --rebase

(`pullall` just saves you from having to call
`git pull`+`git submodule update --init` yourself)


In contrast, `sync-all` is a multi-step process:

 1.) you need to clone ghc.git, 

 2.) then you have a sync-all, which when called
 will `git submodule init` (which doesn't yet download the
 submodules)

 3.) rewrites the fetch-urls in each initialised submodule

 4.) finally calls `git submodule update` to fetch the submodule and
 checkout the commits registered in ghc.git



The difference become apparent when wanting to use github instead; my
recommended approach is to use the URL rewriting feature of GitHub which
even allows you to easily switch between git.haskell.org and github.com
with a single command, or in its simpler form (as described on [2]):

Only needed once, and idempotent setup step:

  git config --global url."git://github.com/ghc/packages-".insteadOf  
git://github.com/ghc/packages/ 

And then just as before:

  git clone --recursive git://github.com/ghc/ghc


So long story short; I've mostly got a bad gut feeling recommending to
use a 1000-line Perl script

  http://git.haskell.org/ghc.git/blob/HEAD:/sync-all

to accomplish what the 2 `git config` commands and the the day-to-day
`git` commands I mentioned in this email can do in a more Git-idiomatic
way. 

So I'm not saying `sync-all` is doing something wrong, but rather that's
overly complex for the task at hand, and we've had support issues with
`sync-all` due to subtle bugs in it (just check the git history for
sync-all to see the tweaks we needed). Moreover, IMHO, if someone's
already proficient with Git, telling them to use `sync-all` will rather
confuse than help as it's not that transparent what it really does.


 [1]: 
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias

 [2]: https://ghc.haskell.org/trac/ghc/wiki/Newcomers
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken (again)

[Herbert Valerio Riedel]

On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
> Perhaps, yes, it is Python 3. I don't know.  Could someone revert to
> make it work again, please?

Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
have any working pure Msys2 environment yet (still working on it), as
this may exactly be the kind of failure I'd expect Msys2 to be prone to
while Cygwin to be unaffected by). 

What I tried in order to reproduce:

  $ git rev-parse HEAD
  084d241b316bfa12e41fc34cae993ca276bf0730  # <-- this is the Py3/testsuite 
commit 

  $ make TEST=tc012 WAY=normal
  ...
  => tc012(normal) 3039 of 4088 [0, 0, 0] 
  cd ./typecheck/should_compile && 
'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp 
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts 
-fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns 
>tc012.comp.stderr 2>&1
   
  OVERALL SUMMARY for test run started at Fri Oct  3 15:42:04 2014 GMT
   0:00:03 spent to go through
  4088 total tests, which gave rise to
 12360 test cases, of which
 12359 were skipped
   
 0 had missing libraries
 1 expected passes
 0 expected failures
  ...


And btw, with the latest GHC HEAD commit (and I suspect the recent
HEAP_ALLOCED-related commits to be responsible for that), I get a ton of
testsuite failures due to such errors:

  T8639_api.exe: Unknown PEi386 section name `staticclosures' (while 
processing: 
C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GitHub pull requests

[Herbert Valerio Riedel]

On 2014-10-05 at 04:51:41 +0200, Richard Eisenberg wrote:
> I've just finished reading this: 
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
>
> For better or worse, I don't read reddit often enough to hold a
> conversation there, so I'll ask my question here: Is there a way we
> can turn GitHub pull requests into Phab code reviews? I'm thinking of
> something like this:

My greatest worry about allowing GitHub PRs to the
github.com.ghc/ghc.git repo is that GitHub and Trac use the very same
`#[0-9]+` syntax tokens for referring to tickets and PRs, and trigger
actions as soon as they detect any commit using that token. In other
words, there's a namespace collisions (Luckily, Phabricator seems to
have been designed to be used in concert with an external Ticket
tracker, so it uses `[DT][0-9]+` to refer to code-revisions & tickets
respectively).

Morever, I'm also worrying this may become confusing to new
contributors, since we already have the Trav vs Phabricator confusion
about where to submit patches; if we also add GitHub PRs it'll just add
another item to be confused about where things ought to be
submitted. And the more PRs are added on github.com/ghc/ghc, the more it
may appear as if that is the encouraged way to submit them (even though
Phabricator+Trac is our currently targetted workflow)


What I'd suggest alternatively, since this what some of our contributors
are already doing instead of uploading patches:

  Teach Phabricator to allow to submit a URL to a commit (or branch) in a
  forked github.com/ghc/ghc repo, and create a code-revision out of that.


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GitHub pull requests

[Herbert Valerio Riedel]

Hello,

On 2014-10-05 at 14:03:41 +0200, Joachim Breitner wrote:
> Am Sonntag, den 05.10.2014, 13:08 +0200 schrieb Herbert Valerio Riedel:
>> On 2014-10-05 at 12:56:28 +0200, Joachim Breitner wrote:
>> 
>> [...]
>> 
>> > I think the advantage could outweigh the downside and it’s worth a try.
>> > We don’t even have to advocate it aggressively, just remove the „Do not
>> > submit PRs“ notice on the repo and see what happens.
>> >
>> > (The problem with the ticket numbers remain, unfortunately.)
>> 
>> Take into account though, there's no easy going back once we open that
>> Pandora box; once GitHub allocates a #-number for a repo, it can only be
>> removed by involving the GitHub admins, and until then any overlapping
>> #-reference will lead to confusing notifications and ticket/issue
>> comments associated w/ the respective Trac-ticket and/or GitHub
>> pull-request.
>
> that’s a valid point. 
>
> Is there maybe a way to disable all #-number-parsing on GitHub? But I
> haven’t seen it...

Not that I know of; I'd be a bit suprised though if it was indeed
possible, as it's a core feature of GitHub (and after all, you can't
disable the PR-submission either)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Herbert Valerio Riedel]

On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:

[...]

> The idea behind an LTS-GHC would be to continue bug-fixing on the
> LTS-version, even if newer major versions no longer get bug-fixing
> support. To some extent, there will be redundancies (bugs that have
> disappeared in newer versions because newer code does the same and
> more, still needing to be fixed on the LTS code base), but the upside
> would be a clear prioritisation between stability (LTS) and innovation
> (latest major release).

As I'm not totally sure what you mean: Assuming we already had decided
years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the
future 7.10; which of those GHC versions would you have been considered
a LTS version?

[...]

> The danger, of course, is that people aren't very enthusiastic about
> bug-fixing older versions of a compiler, but for
> language/compiler-uptake, this might actually be a Better Way.

Maybe some of the commercial GHC users might be interested in donating
the manpower to maintain older GHC versions. It's mostly a
time-consuming QA & auditing process to maintain old GHCs.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Herbert Valerio Riedel]

On 2014-10-06 at 11:50:03 +0200, Malcolm Wallace wrote:
> On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote:
>
>> As I'm not totally sure what you mean: Assuming we already had decided
>> years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the
>> future 7.10; which of those GHC versions would you have been considered
>> a LTS version?
>
>
> We continue to use 7.2, at least partly because all newer versions of
> ghc have had significant bugs that affect us.  In fact, 7.2.2 also has
> a show-stopping bug, but we patched it ourselves to create our very
> own custom ghc-7.2.3 distribution.

I'd like to point out that's kinda ironic, as of *all* the GHC releases,
you had to stay on the one major release that was considered a
non-proper tech-preview... :-)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Phabricator guidance

[Herbert Valerio Riedel]

On 2014-10-07 at 10:57:00 +0200, Simon Peyton Jones wrote:
> I suppose I will have to look at this. But I have no clue how to do so.
>
> D202 itself seems to be a very small patch (only ten lines or so), so 
> presumably it applies on top of some other patch?  But what?
>
> Someone said I could use
>   arc patch D202
> to apply the patch in my own tree, which is crucial for reproducing
> the error that Jan is stuck on.  

> BUT the patch presumably applies to a
> particular commit, NOT the head of my current tree.  But what is the
> base commit to which it applies?  Does arc patch check out the base
> commit before applying?

If you actually perform 'arc patch D202', this is the output you
currently get:


,
| Created and checked out branch arcpatch-D202.
| 
| 
| This diff is against commit 3e17822f5f4e4d2f582dc0a053f532125f9777c7, but
| the commit is nowhere in the working copy. Try to apply it against the
| current working copy state? (3549c952b535803270872adaf87262f2df0295a4)
| [Y/n] n
`

So yes, 'arc' tries apply the code-revision on top of the commit is was
based on; and in this case, it is actually missing from ghc.git :-/

What's more, you can also declare that a code-revisions builds on top of
another code-revision, in which case 'arc' will automatically try to
(recursively) apply that other code-revision to your source-tree first, before
applying the one you are actually requesting on top.


I hope Austin or someone else may chime in to provide further assistance
if this doesn't help...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Herbert Valerio Riedel]

On 2014-10-07 at 15:04:18 +0200, cg wrote:

[...]

> I guess the current two build server are all Cygwin based, they are
> failing at the same permission issue at early building stage, it prevents
> checking out the real problem. It seems msys2 (or msys)  seldom has
> such issue.

Btw, while I finally managed to get a pure MSYS2 environment to work
with a manually started sshd.exe, it'd be great if somebody could point
me to instructions on how to setup e.g. cygrunsrv+sshd in order to have
sshd.exe startup automatically on boot-up *and* have sshd.exe be able to
log into more than just one single account (currently if I start sshd, I
can only log into the very same account which started sshd)

Having such a setup would be really useful to provide the GHC
development improve its infrastructure as well to help reduce the
regular windows-arch failures we're seeing so often.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RFC: Source-markup language for GHC User's Guide

[Herbert Valerio Riedel]

Hello GHC Developers & GHC User's Guide writers,

I assume it is common knowledge to everyone here, that the GHC User's
Guide is written in Docbook XML markup.

However, it's a bit tedious to write Docbook-XML by hand, and the XML
markup is not as lightweight as modern state-of-the-art markup languages
designed for being edited in a simple text-editor are.

Therefore I'd like to hear your opinion on migrating away from the
current Docbook XML markup to some other similarly expressive but yet
more lightweight markup documentation system such as Asciidoc[1] or
ReST/Sphinx[2].

There's obviously some cost involved upfront for a (semi-automatic)
conversion[3].  So one important question is obviously whether the
long-term benefits outweight the cost/investment that we'd incur for the
initial conversion.

All suggestions/comments/worries welcome; please commence brainstorming :)



 [1]: http://www.methods.co.nz/asciidoc/

 [2]: http://sphinx-doc.org/

 [3]: There's automatic conversion tools to aid (though manual cleanup
  is still needed) the initial conversion, such as

 https://github.com/oreillymedia/docbook2asciidoc

  As an example, here's the conversion of

 
http://git.haskell.org/ghc.git/blob/HEAD:/docs/users_guide/extending_ghc.xml
  
  to Asciidoc:
  
 https://phabricator.haskell.org/P24

  to give an idea how XML compares to Asciidoc
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Herbert Valerio Riedel]

On 2014-10-08 at 04:28:50 +0200, cg wrote:

[...]

> After cloning ghc repository, I switch every sub-module to Master (it is
> usually HEAD) branch.

Why are you doing that? :-)

[...]

> Now after cloning ghc repository, if I don't switch to any branch -- 
> 'git branch'
> will show all submodules are detached -- the build will succeed.

Well, that's how you're supposed to work with submodules in ghc.git[1]

> So why the Master/HEAD branches don't have the latest code?

Generally, the "master" branch refers to the latest upstream code,
which is not always supposed to work with GHC HEAD (yet). And if the
package is not owned by GHC HQ, you are not allowed to push changes to
"master" anyway (as it'd be automatically overwritten by the automatic
Git mirror job)

Take Cabal for example, we have an automatic mirror-job that keeps
Cabal's "master" branch synced to the state of the github.com/

However, we only update the gitlink for Cabal in ghc.git every couple of
weeks to Cabal's latest "master" tip commit, as it has the potential to
affect performance numbers or simply be temporarily in a broken state
wrt GHC HEAD.


Then there's Haddock for which it was recently decided to let upstream
development progress decoupled from GHC HEAD's API changes, and have GHC
HEAD simply use its own branch 'ghc-head' to diverge from upstream until
shortly before a GHC release is close (at which point Haddock will
converge again). Fwiw, 'git submodule update --remote utils/haddock'
will track the "ghc-head" branch in this case.


Finally, "binary" is a case where we needed a patch merged into binary,
but couldn't wait for the "binary" upstream to merge the pull-request,
as it was blocking GHC HEAD development. So that's why we temporarily
are on a "ghc-head" branch, which will be switched away from again as
soon as "binary"'s upstream "master" branch can be used again with GHC
HEAD.


And then there's also the potential case when we need to temporarily
rollback a submodule update; then we don't necessarily need to 'git
revert' commits inside that submodule, but we simply just reset the
pointed-to submodule commit to an older commit.


I hope this sheds a bit of light on the situation. Then there's also [1]
which may provide further pointers.


 [1]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Herbert Valerio Riedel]

Hello,

On 2014-10-08 at 02:34:50 +0200, George Colpitts wrote:
> I agree a section show stoppers is a good idea, in parallel would it
> make sense to use the priority "highest" for tickets that we consider
> showstoppers?

I think, they are marked 'highest' already

Btw, one could additionally add a dynamic ticket-query-table to that
section to list all tickets currently marked priority="highest" and
milestone="7.8.4" to make sure nothing is missed.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Herbert Valerio Riedel]

On 2014-10-08 at 02:13:01 +0200, Carter Schonwald wrote:
> the checkout process for the 7.8 branch is a bit involved (and NB: you
> really want to use a different tree than one for working on head, the
> checkout process is different
> )
>
> $ git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-7.8TREE
> $ cd ghc-7.8TREE/
> $ ./sync-all   get -b ghc-7.8
>
> (theres no need for a lot of this with HEAD)

Just to clarify/remind why this is needed:

The GHC 7.8 branch was not converted to a proper submodule-only scheme
like GHC HEAD was.  Unless we keep maintaining GHC 7.8 for longer than a
7.8.4 release, this irregularity will become less of a concern, as the
stable GHC 7.10 branch will be switchable to/from later branches such as
GHC 7.12/HEAD w/o requiring a separately cloned tree.

However, should GHC 7.8.x turn out to become a LTS-ishly maintained
branch, we may want to consider converting it to a similiar Git
structure as GHC HEAD currently is, to avoid having to keep two
different sets of instructions on the GHC Wiki for how to work on GHC
7.8 vs working on GHC HEAD/7.10 and later.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Herbert Valerio Riedel]

On 2014-10-08 at 10:49:33 +0200, Jan Stolarek wrote:
>> Therefore I'd like to hear your opinion on migrating away from the
>> current Docbook XML markup to some other similarly expressive but yet
>> more lightweight markup documentation system such as Asciidoc[1] or
>> ReST/Sphinx[2].

> My opinion is that I don't really care. I only edit the User Guide
> once every couple of months or so. I don't have problems with Docbook
> but if others want something else I can adjust.

I'd argue, that casual contributions may benefit significantly from
switching to a more human-friendly markup, as my theory is that it's
much easier to pick-up a syntax that's much closer to plain-text rather
than a fully-fledged Docbook XML. With a closer-to-plain-text syntax you
can more easily focus on the content you want to write rather than being
distracted by the incidental complexity of writing low-level XML markup.

Or put differently, I believe or rather hope this may lower the
barrier-to-entry for casual User's Guide contributions.


Fwiw, I stumbled over the slide-deck (obviously dogfooded in Asciidoc)

  
http://mojavelinux.github.io/decks/discover-zen-writing-asciidoc/cojugs201305/index.html

which tries to make the point that Asciidoc helps you focus more on
writing content rather than fighting with the markup, including a
comparision of the conciseness of a chosen example of Asciidoc vs. the
resulting Docbook XML it is converted into.


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Warning when deriving Foldable/Traversable using -Wall

[Herbert Valerio Riedel]

On 2014-10-08 at 14:00:05 +0200, Alan & Kim Zimmerman wrote:

[...]

> Should this go into Trac?

Fwiw, there is a version "7.9" you can select when writing a Trac ticket
for the very purpose to file bugs against GHC HEAD.

[...]

> The file being compiled is
>
> 
> {-# LANGUAGE DeriveTraversable #-}
>
> module T9069 where
>
> import Data.Foldable
> import Data.Traversable
>
> data Trivial a = Trivial a
>deriving (Functor,Foldable,Traversable)
> -

There's two simple ways to workaround this;

either

 a) add a 'import Prelude' after the two imports

or

 b) remove the two imports



The a) option has the benefit that it will still work with GHC 7.8.3
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Herbert Valerio Riedel]

On 2014-10-09 at 07:15:13 +0200, Páli Gábor János wrote:
> 2014-10-07 17:02 GMT+02:00 Páli Gábor János :
>> 2014-10-07 15:04 GMT+02:00 cg :
>>> I guess the current two build server are all Cygwin based, they are
>>> failing at the same permission issue at early building stage, it prevents
>>> checking out the real problem. It seems msys2 (or msys)  seldom has
>>> such issue.
>>
>> For what it is worth, I have been witnessing those permission issues
>> with msys2 on my Windows builders.  They worked (more or the less)
>> fine until September 24, but suddenly, something has changed (not on
>> my side) and all I got those errors since.
>
> Looks like the commit with the Cabal submodule update causes this [1].
> The revision before that commit still builds fine on my system, while
> everything else after that commit dies early at build [2].  Is this
> only me, has anybody else experienced the problem?  Perhaps I am doing
> something wrong?  I do not remember to see any related "heads-up"
> message on the list, like I should update any of the build-time
> dependencies.

Fwiw, I didn't see this issue on a newly setup MSYS2 environment
either. How old is your MSYS environment? (And what filesystem & windows
version are you running?)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Broken build: 32-bit FreeBSD, SmartOS, Solaris

[Herbert Valerio Riedel]

On 2014-10-10 at 09:19:31 +0200, Páli Gábor János wrote:
> Looks one of the recent commits broke the x86 builds on multiple
> platforms [1][2][3].  The common error message basically is as
> follows:
>
> rts/Linker.c: In function 'mkOc':
> rts/Linker.c:2372:6:
>  error: 'ObjectCode' has no member named 'symbol_extras'
>
> Please fix it!
>
> Note that the x86_64 counterparts of the affected builders completed
> their builds fine -- except for Solaris, but that has been broken
> already for a long time (relatively).
>
> [1] http://haskell.inf.elte.hu/builders/smartos-x86-head/144/10.html
> [2] http://haskell.inf.elte.hu/builders/freebsd-i386-head/403/10.html
> [3] http://haskell.inf.elte.hu/builders/solaris-x86-head/191/10.html

Fyi, this was the commit, and I'm positive Simon is aware already:

  https://phabricator.haskell.org/rGHC5300099edf106c1f5938c0793bd6ca199a0eebf0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Curious Windows GHCi linker behaviour .o vs. .dll

[Herbert Valerio Riedel]

Hello *,

I assume this is a well known issue to MSYS2/Windows developers, so I
hope somebody may be able to provide more insight for me to better
understand the underlying problem of

  https://github.com/haskell/time/issues/2


So the prototype for tzset() is simply

void tzset(void);

and it's defined in `msvcrt.dll` as far as I can tell; 
Consider the following trivial program:

module Main where
 
foreign import ccall unsafe "time.h tzset" c_tzset :: IO ()
 
main :: IO()
main = c_tzset

When compiled with GHC 7.8.3, the resulting executable works and has the
following tzset-symbols:

$ nm tz.o | grep tzset
 U tzset

$ nm tz.exe  | grep tzset
0050e408 I __imp_tzset
004afc40 T tzset

However, when loaded into GHCi, the RTS linker fails to find `tzset`:

$ ghci tz.hs
WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in 
particular)
 doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper 
instead
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( tz.hs, interpreted )
 
ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  tzset
...

However, when I prefix a `_` to the symbol-name in the FFI import, i.e.

foreign import ccall unsafe "time.h tzset" c_tzset :: IO ()

Now, GHCi happily loads the module and is apparently able to resolve the
`tzset` symbol:

$ ghci tz.hs
WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in 
particular)
 doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper 
instead
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( tz.hs, interpreted )
Ok, modules loaded: Main.
*Main> 

Moreover, compiling and running the program still works, and the
additional underscore is visible in `nm` as well:

$ nm tz.o | grep tzset
 U _tzset

$ nm tz.exe | grep tzset
0050e558 I __imp__tzset
004b8050 T _tzset


What's going on here? Why does one need to add an artificial underscore
to FFI imported symbols for GHCi to resolve symbols? Is this a bug?


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Curious Windows GHCi linker behaviour .o vs. .dll

[Herbert Valerio Riedel]

On 2014-10-11 at 17:04:57 +0200, cg wrote:
[...]
> [...]
>>  ByteCodeLink: can't find label
>>  During interactive linking, GHCi couldn't find the following symbol:
>>tzset
>
> Strange, I tried it under HaskellPlatform-2014.2, it works, I didn't
> see the
> failure. And I tried it in both Windows cmd and msys2 shell.

Well, I basically used a MSYS2 environment setup according to 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows


>> However, when I prefix a `_` to the symbol-name in the FFI import, i.e.
>>
>>  foreign import ccall unsafe "time.h tzset" c_tzset :: IO ()
>>
>
> I guess it should read:
> foreign import ccall unsafe "time.h _tzset" c_tzset :: IO ()
>
> It works too.

Yes, sorry, I forgot to add that leading underscore :-/

> Actually both _tzset and tzset exist in include/time.h, only tzset is old
> style name. They will be linked as the same function __imp__tzset.

What do you mean by "old style"? And more importantly, what
foreign-import line shall be used that works both on Windows and
non-Windows platforms, compiled as well as interpreted in GHCi?

Note also that I reduced the original problem to a much smaller
repro-case here, the time-library actually has an additional
redirection: The `tzset()` call is made inside a C function in
`cbits/HsTime.c` which in turn is then foreign-imported. So in this
case, the GHCi linker fails to resolve the correctly referenced
`tzset()`. To me this sounds more and more like a serious bug in GHCi's
linker.


PS: If I run ./validate on GHC HEAD, several of the GHCi testcases such
as

   ghci/prog001  prog001 [bad stderr] (ghci)
   ghci/prog002  prog002 [bad stderr] (ghci)
   ghci/prog003  prog003 [bad stderr] (ghci)
   ghci/prog012  prog012 [bad stderr] (ghci)
   ghci/prog013  prog013 [bad stderr] (ghci)

fail for me due to not being able to load the `time` package (due to
tzset).

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Curious Windows GHCi linker behaviour .o vs. .dll

[Herbert Valerio Riedel]

Hello!

On 2014-10-12 at 04:30:13 +0200, cg wrote:

[...]

> Are you using 64-bit ghc? If so, it looks the issue is 64-bit only.

Indeed, I have only set up 64bit CygWin & MSYS2 environments so far.

>>> Actually both _tzset and tzset exist in include/time.h, only tzset is old
>>> style name. They will be linked as the same function __imp__tzset.
>>
>> What do you mean by "old style"? And more importantly, what
>> foreign-import line shall be used that works both on Windows and
>> non-Windows platforms, compiled as well as interpreted in GHCi?
>>
>
> I meant OLDNAME in MS's jargon, because they deprecate tzset [1],
> then call it 'old'. But it it still usable.
>
> [1] http://msdn.microsoft.com/en-us/library/ms235451.aspx

Ok, thanks for clairification, so I see there are actually two entangled
issues here:

 1) When coding directly against the MSVCRT, one is supposed to use the
underscore-prefixed POSIX symbols, like e.g `_tzset()`. However,
when targetting CygWin, using the proper `tzset()` POSIX name is the
recommended course of action.

To this end, I've submitted https://github.com/haskell/time/pull/4
(I hope that works for 32bit MSYS2 environments as well)

Personally, I think this was a very questionable decision on
Microsoft's part, as this way you effectively destroy any chance to
simply compile existing POSIX-compatible source code for no good
reason...


 2) The other issue seems to be that while linking a package using
`tzset()` into a `.exe`, `tzset()` gets resolved just fine, however
as soon as GHCi's linker is used to resolve `tzset()` contained in
that package, it fails. At this point, I still consider this a bug.
It was suggested by Brandon, that GHCi's linker fails to resolve
weak symbols.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Herbert Valerio Riedel]

On 2014-10-13 at 10:57:10 +0200, Simon Peyton Jones wrote:
> I think the potential difficulty is (1).  Maybe they take it down (e.g. they 
> move on to version X so they take down old version Y).
>
> An alternative would be to stash a copy somewhere on GHC’s main web
> server, and wget that.  I’d be more comfortable doing that; less
> dependence on others.

I guess storing a copy somewhere on https://ghc.haskell.org/ should be
ok (I'm hoping Austin may weigh in wrt CDN-related considerations). I'd
suggest using it as a fallback location though. I.e. try downloading
from the official upstream location, and if that fails (either due to
I/O errors and/or unexpected checksum), fallback to using our locally
mirrored copy. However, we may need to take into account license issues,
such as hosting the source-code as well, if we host binary distributions
depending on the licenses involved (I'm not sure if this was ever
considered for ghc-tarballs.git to begin with)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: One-shot semantics in GHC event manager

[Herbert Valerio Riedel]

On 2014-10-13 at 23:33:13 +0200, Austin Seipp wrote:

[...]

> Also, if any other developers (like Andreas, Johan, Bryan, etc) in
> this space want a big machine to test it on, I can probably equip you
> with one (or several). Since Rackspace is so gracious to us, we can
> immediately allocate high-powered, physical (i.e. not Xen, but real
> machines) machines to do high-scale testing on.[1]
>
> In any case, it's not hard to do and only takes a few minutes, so Ben:
> let me know. (I've thought it would be neat to implement a leasing
> system somehow, where a developer could lease a few machines for a
> short period of time, at which point they expire and a background job
> cleans them up.)

I'd like to add to this; If there's demand to provide SSH accounts to
MSYS2-environments for developing/testing GHC patches or generally
debugging/fixing GHC issues occuring on Windows, we may be able to
provide such (ephemeral) accounts.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Wiki: special namespace for proposals?

[Herbert Valerio Riedel]

On 2014-10-15 at 18:09:32 +0200, Andrew Farmer wrote:

[...]

> I'm not really familiar with what Trac Wiki is capable of. Is it
> possible to add tags/categories to a page and then make an
> auto-generated list of links to all pages with a given tag/category?

Fyi, Trac by default has no tags, and the TitleIndex macro can be used
to insert a list of wiki pages matching certain criterias:

  http://trac.edgewall.org/wiki/WikiMacros#TitleIndex-macro

However, there's a plugin to teach 'tags' to Trac:

  http://trac-hacks.org/wiki/TagsPlugin


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Making GHCi awesomer?

[Herbert Valerio Riedel]

On 2014-10-18 at 19:59:24 +0200, Christopher Done wrote:

[...]

> Herbert doesn't have time to hack on it, but was encouraging about
> continuing with ghci-ng.

Yeah, it's quite convenient to hack on GHCi that way as it's just an
ordinary Cabal package (so it doesn't require to setup a GHC source-tree
and wrangle with the GHC build-system), if you're lucky enough (which is
most of the time) that the parts you want to tweak don't require
changing the GHC API.

> I'm thinking to try forward-porting ghci-ng to GHC 7.8,

Iirc all of the deltas in ghci-ng-7.6 relative to GHC 7.6.3 landed in
GHC 7.8.1, so extracting the latest GHCi frontend code would be probably
better.

> or otherwise extracting GHC 7.8's GHCi again
> and then backporting it
> to 7.6. 

Fwiw, I setup the ghci-ng .cabal's in such a way, that if you 'cabal
install ghci-ng' with a GHC 7.4.x, you'd get a ghci-ng-7.4.2.1, while
when on GHC 7.6.x, ghci-ng-7.6.3.5 would be selected.

Supporting multiple major-versions of the GHC API simultanously in the
same code-base could prove to be rather tedious (and make it more
difficult to extract clean patches to merge back into GHC HEAD). But
this is only speculation on my part, so your mileage may vary

> (Under the assumption that current + past is a reasonable number of
> GHCs to support.) I'm going to experiment with the JSON interface and
> I'll report back with results.

You may want to be careful with the build-deps though; e.g. if you use
JSON and want this to be merged back into GHC HEAD at some point, we may
need something lighter than the usual go-to JSON implementation `aeson`
in terms of build-deps...


PS: I've added you to
http://hackage.haskell.org/package/ghci-ng/maintainers/, just in case...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Does D351 Unwiring-Integer patch now look like you envisioned?

[Herbert Valerio Riedel]

Hello!

On 2014-10-24 at 10:08:00 +0200, Simon Peyton Jones wrote:
> I replied, but failed to press "Submit" (which is several screenfuls
> away). Sorry

Thanks! 

(if you press the 'z'-key outside of any input-form on code-revision
pages, you get the screen horizontally tiled with the submit-form in the
bottom half - this is sometimes generally useful to have IMHO)

> The Maybe DataCon idea looks right to me.
>
>
> FWIW I *hate* the way that TidyPgm is forced to predict what CorePrep
> will do.  I've created https://ghc.haskell.org/trac/ghc/ticket/9718 to
> explain.

Btw, this reminds me I have a low-priority plan to improve the
`mkInteger` call interface, as the current one is terrible: it requires
splitting a large integer literal into 31-bit words (even when machine
wordsize is 64bit!), and then wrapping those into an ordinary
[Int]-list.

I'd rather like mkInteger to take an packed array of machine-size words,
similar to how [Char] literals are handled via `unpackCString#`, which
would allow for a more compact representation in object files as well as
possibly direct conversion of integer literals in GHC's Integer
backends... I've created a ticket to keep track of that idea:

  https://ghc.haskell.org/trac/ghc/ticket/9719

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: old-time.git/tests/time004.hs is DST-sensitive :-/

[Herbert Valerio Riedel]

Hello *,

It's that time of the year again when time004 fails...

and there's also an associated ticket:

  https://ghc.haskell.org/trac/ghc/ticket/4440

On 2013-10-27 at 11:03:41 +0100, Herbert Valerio Riedel wrote:
> if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to
> DST (and depends on your system's TZ-config):
>
>   http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs
>
> For me, the comparison this unit-test checks now suddenly fails, because
> the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e.
>
>   length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 
> 2012"
>
> Does anyone happen to know what the rationale behind this 'time004' unit
> test was?
>
> Cheers,
>   hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on mingw-w64 / gcc 4.8.3 on Windows

[Herbert Valerio Riedel]

Hello *,

On 2014-10-27 at 11:37:01 +0100, Gintautas Miliauskas wrote:
>> Since I don't follow Phabricator I didn't even suspect you are making all
>> this work.

> Yes, looks like I undercommunicated, sorry about that.

In the hopes to aid with communication, I've just created a "GHC Windows
Task Force" Team/Project in Phab:

  https://phabricator.haskell.org/project/view/11/

Assuming you make use of this, you can reference the group of people
that are part of that "project" by simply using of its associated
hash-tags like e.g. `#ghc_windows_task_force` (or a bit easier its
abbreviation `#ghc-wtf`, we can add additional ones at well) in place of
a user-name.

So, if everyone interested in keeping the Windows platform working by
code-reviewing would join the the "GHC Windows Task Force" Phab group,
he/she could get CC'ed everytime there's the suspicion a patch may
affect compilation on windows and may benefit from additional eyes...

HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Herbert Valerio Riedel]

On 2014-10-29 at 10:59:18 +0100, Phyx wrote:

[...]

>> The Win32 package for example, is dreadfully lacking in
>> maintainership. While we merge patches, it would be great to see a
>> Windows developer spearhead and clean it up
>
> A while back I was looking at adding some functionality to this
> package, but could never figure out which one was actually being
> used. I think there are multiple repositories out there.

I'm not sure which multiple repositories you have seen, but

  http://hackage.haskell.org/package/Win32

points quite clearly to

  https://github.com/haskell/win32

and that's the official upstream repository GHC tracks (via a locally
mirrored repo at git.haskell.org)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Herbert Valerio Riedel]

On Wed, Oct 29, 2014 at 12:36 PM, Gintautas Miliauskas <
gintau...@miliauskas.lt> wrote:

> By the way, regarding that repository, could someone merge my pull request
> ?
>
>
​The problem here is that the official maintainer according to​

http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries

​is Bryan, so he's the one supposed to pull the trigger on pull-requests
(unless he's ok with GHC HQ pushing commits straight to `master` or
granting the GHC Windows Task Force officially co-maintership of the Win32
package)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RFC: Properly stated origin of code contributions

[Herbert Valerio Riedel]

Hi,

GHC's Git history has (mostly) a good track record of having properly
attributed authorship information in the recent past; Some time ago I've
even augmented the .mailmap file to fix-up some of the pre-Git meta-data
which had mangled author/committer meta-data (try 'git shortlog -sn' if
you're curious)

However, I just noticed that

  
http://git.haskell.org/ghc.git/commitdiff/322810e32cb18d7749e255937437ff2ef99dca3f

landed recently, which did change a significant amount of code, but at
the same time the author looks like a pseudonym to me (and apologies if
I'm wrong).

Other important projects such as Linux or Samba, just to name two
examples, reject contributions w/o a clearly stated origin, and
explicitly reject anonymous/pseudonym contributions (as part of their
"Developer's Certificate of Origin" policy[1] which involves a bit more
than merely stating the real name)

I believe the GHC project should consider setting some reasonable
ground-rules for contributions to be on the safe side in order to avoid
potential copyright (or similiar) issues in the future, as well as
giving confidence to commercial users that precautions are taken to
avoid such issues.

Comments?

Cheers,
  hvr

 [1]: See 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Herbert Valerio Riedel]

On 2014-10-30 at 22:59:45 +0100, Isaac Dupree wrote:
> There are good reasons not to require people's "real" name to participate:
>
> http://geekfeminism.wikia.com/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F
>
> Simon PJ often advocates to know people's name as part of creating a
> friendly community.  There are good things about this.  It also helps
> exclude people with less privilege, whom we have few enough of already,
> if it is a policy.
>
> I like most things about "Developer's Certificate of Origin", though.

However, if we want to adopt the DCO[1] (as used by Linux Kernel
development) as a good-faith (and yet light-weight) attempt to track the
origin/accountability of contributions it relies on real names to know
who is actually making that assertion. Having the DCO signed off by an
obvious pseudonym would defeat the whole point of the DCO imho.

Cheers,
  hvr

 [1]: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n358
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Herbert Valerio Riedel]

Hi Austin,

On 2014-10-30 at 21:55:14 +0100, Austin Seipp wrote:
[...]
> Can we get a standardized copyright/comment header across all our
> files? It seems as if every single file in the compiler (and RTS) has
> different header text, mentioning different people or groups, some
> from 10 years ago or more and others just recently added. This is
> somewhat related to this RFC but also somewhat not, I feel.
[...]

Could you draft up a standard-header as a suggestion somewhere, maybe on
the Wiki? 

The current situation is suboptimal, as it's unclear where the threshold
for adding yourself as an author to a module header is
(whitespace/indentation cleanups, fixing/writing docs, removing lines,
adding a 5-line function in a 500 line module, ...?), and it's a bit
unfair to those that have contributed far more to a module but haven't
bothered to add themselves to the module header. So I'd welcome a
standard approach.

Would there be a single AUTHORS file for the code in ghc.git, or
multiple ones (one for the compiler proper, one for base, ghc-prim,
template-haskell, integer-*, ...?)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal: Improving the LLVM backend by packaging it

[Herbert Valerio Riedel]

On 2014-11-01 at 17:26:26 +0100, Austin Seipp wrote:

[...]

>> How long does building those two llvm binaries take? If it is
>> sufficiently quick, maybe that would be a suitable distribution for
>> developers as well, and avoids having to separately build, distribute,
>> download, and install the binaries.
>
> In practice it takes a while... I haven't timed it, but I'd guess on
> average it adds about 30-40 minutes for most people just to build
> llvm. I'm not sure how many things we can disable to make the build
> faster, but I'd ballpark it at half an hour at best (it's a few
> thousand source files, after all).
>
> This would mostly hurt if you cleaned up the tree later (e.g. 'make
> distclean'), which I do rather frequently in order to get a pristine
> build tree.

This also hurts buildbots as 30+ minutes is even more than a validate
run takes... :-/

Otoh, we don't have to force everyone to build GHC's bundled LLVM, and
could allow to use the system-wide installed LLVM binaries if a matching
version is provided by the system. As an example, I currently have
llvm-3.4 and llvm-3.5 installed, and could easily have a llvm-3.6
snapshot installed via the package manager (e.g. via
http://llvm.org/apt/).

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal: Improving the LLVM backend by packaging it

[Herbert Valerio Riedel]

On 2014-11-01 at 18:43:35 +0100, Ben Gamari wrote:

[...]

>> This would mostly hurt if you cleaned up the tree later (e.g. 'make
>> distclean'), which I do rather frequently in order to get a pristine
>> build tree.
>>
> Ideally `make clean` would be a bit more complete so it could be used
> more often. Much of my use of `make distclean` comes from superstition
> after thinking `make clean` would be sufficient only to find out
> half-way through the build that there is still vestigal state hanging
> around.

I regularly run ./validate, which by definition has to reset everything
to a zero-state. Moreover, I keep a few GHC source-trees around, and
wouldn't want to have to keep redundant LLVM binaries around. So using
'make clean' isn't an option for everyone. I'd rather install the
required LLVM version system-wide (or rather, reachable via PATH), and
have ./configure try to pick that one up, before deciding it needs to
build its own LLVM.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library

[Herbert Valerio Riedel]

Hello Gergo,

On 2014-11-02 at 14:29:06 +0100, Dr. ERDI Gergo wrote:
> On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:
>
>> On a completely clean clone, I've checked out the tag
>> ghc-7.8.3-release, ran sync-all get, boot, and configure, but the
>> build fails on haskell98. Any ideas what I could be doing wrong?
>
> I've worked around this by manually checking out the 'ghc-7.8' branch
> of various submodules until I got it to work (I think the ones I
> needed to change were dph, haskell98, haskell2010, template-haskell,
> and haddock, but I'm not sure). It seems the `ghc-7.8.3-release` tag
> is in a horrible shape in terms of reproducable building of imported
> repos. Is anyone looking into fixing this?

Starting with GHC 7.8.x, fingerprints are written into
annotated & gpg-signed release tags:

  http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release

That way you're able to restore via the fingerprint for a given release
via:

 ./utils/fingerprint/fingerprint.py restore -f <(git show ghc-7.8.3-release | 
grep -F '|')

I'm just surprised I couldn't find that described anywhere in the wiki,
I was sure it was written down somewhere...

hth,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Problem with select(2) in single threaded runtime.

[Herbert Valerio Riedel]

On 2014-11-04 at 07:42:11 +0100, Merijn Verstraaten wrote:
> Worse, it appears the maximum size of time_t is unrelated to the
> maximum value accepted by select(2). 

Fwiw, I found the following on
http://pubs.opengroup.org/onlinepubs/009695399/functions/pselect.html

,
| Implementations may place limitations on the maximum timeout interval
| supported. All implementations shall support a maximum timeout interval
| of at least 31 days. If the timeout argument specifies a timeout
| interval greater than the implementation-defined maximum value, the
| maximum value shall be used as the actual timeout value. Implementations
| may also place limitations on the granularity of timeout intervals. If
| the requested timeout interval requires a finer granularity than the
| implementation supports, the actual timeout interval shall be rounded up
| to the next supported value.
`

So I'm a bit surprised you get an EINVAL instead of the timeout being
capped to the implementation's max supported value.

Was the passed `timeval` structure valid? I.e. is the tv_usec value inside
the [0,1e6-1] range? and was tv_sec>=0 ?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't install packages with my inplace compiler

[Herbert Valerio Riedel]

Hello Simon,

On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote:
> When I say
>
> cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
>
> I get this
>
> ghc-stage2: ghc no longer supports single-file style package databases
> (dist/package.conf.inplace) use 'ghc-pkg init' to create the database
> with the correct format.
>
> Now, this is an old build tree, and I could blow it away entirely, but
> maybe there is something else going on.  What should I do?

What does `cabal --version` say? If it doesn't say something like

  $ cabal --version
  cabal-install version 1.21.1.0
  using version 1.21.1.0 of the Cabal library 

you probably need a newer one (in which case you should build the
`cabal` binary from Git, and to make life easier compile `Cabal` and
`cabal-install` with GHC 7.8.x rather than GHC HEAD)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Phab and I differ

[Herbert Valerio Riedel]

On 2014-11-04 at 16:38:52 +0100, Simon Peyton Jones wrote:
> I built and validated this commit just fine.  Phab says
>
> Unexpected failures:
> ghci/should_run ghcirun004 [bad stdout or stderr] (ghci)
> rts linker_unload [bad exit code] (normal)
> stranal/should_compile str001 [exit code non-0] (optasm)
> stranal/should_compile str002 [exit code non-0] (optasm)
> stranal/should_compile test [exit code non-0] (optasm)
>
>
> but none of them fail for me.  I don't know how to see enough of
> Phab's log to see what it thinks when wrong. (it just shows me 25
> lines; clicking on "unlimited" still only shows 30 lines)

It seems to me that compiling T3064 may be the culprit, as that seems
to eat up an humongous amount of RAM...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Problem with select(2) in single threaded runtime.

[Herbert Valerio Riedel]

On 2014-11-04 at 18:18:44 +0100, Merijn Verstraaten wrote:

[...]

> This exits with EINVAL for me on OSX, if I replace INT_MAX with 1000,
> it runs just fine. The man page on OSX mentions EINVAL for values that
> exceed the maximum timeout, so it looks like OSX is not following the
> spec, then...

Btw, I also stumbled over these ancient bug-reports:

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18909

 http://gnats.netbsd.org/11287

So it seems that BSD-ish systems have (or had?) this arbitrary 1e8
second limit in combination with the questionable EINVAL response which
seems in conflict with the POSIX specification.

I'm wondering if there's already an Autoconf test somewhere we could
steal for detecting this peculiarity of select() on BSD systems...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Phab and I differ

[Herbert Valerio Riedel]

On 2014-11-04 at 19:17:13 +0100, Richard Eisenberg wrote:
> Is it possible to get the full build logs on Phab? I just had a
> testsuite (framework) failure, but I can't see what test caused it!
> (https://phabricator.haskell.org/harbormaster/build/1686/)

It's most likely the T3064 test-case (eating up time & space resources)
I mentioned in an earlier post that leads to these framework failures
and similar collateral test-case failures.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Fw: Long term support - in general and Windows XP specifically

[Herbert Valerio Riedel]

On 2014-11-08 at 20:32:17 +0100, Howard B. Golden wrote:

[...]

> I am an interested observer, not an active developer, so take my
> comments with this in mind. I wonder if the release of 7.10 is being
> rushed. Perhaps once a year releases are too frequent for everyone
> except the bleeding edge, who may be satisfied with snapshots. Maybe a
> reallocation of developer effort should be considered. This question
> deserves to be considered even if it is ultimately discarded.

Fyi, last year there was already a discussion sub-thread debating a
change of GHC's yearly major release cycle over at

  http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23425/focus=23451

IIRC, the conclusion was basically that a yearly cycle is a good
compromise balancing all needs/wishes involved.


IMO, since GHC gains so many new features/improvements every year
already, releasing less often would, for one, increase the amount of new
(potentially non-backward compatible changes) features contained in a
release, therefore increasing the work involved to update old code-bases
to a new GHC release[1], while at the same time give less opportunity to
get short release-feedback cycles (as Hackage developers probably only
take serious proper stable GHC releases (candidates), rather than
work-in-progress snapshots that are fast moving targets, potentially
exhibiting all sorts of transient bugs).

IOW, what I'm basically saying is that I'm a proponent of

 http://en.wikipedia.org/wiki/Release_early,_release_often




 [1]: An *extreme* example of what can happen if you accumulate too many
  changes into a new compiler/language release is the Python3
  situation, where it took ages for code-bases to get updated/ported
  from Python2 to Python3 (and it's still ongoing), as the upgrade
  path was too steep, while Python3 development was even slowed down
  for a few years by a self-imposed "Python Language Moratorium" to
  let Python3's adoption catch up.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: small `arc` victory -- commit message not changed

[Herbert Valerio Riedel]

On Mon, Nov 10, 2014 at 10:22 AM, Simon Marlow  wrote:


> So I'm hesitant to recommend this workflow.  I think the biggest problem
> in your description is the bit where you "de-Phabbed" the commit message,
> which meant that you had to tell Phabricator exactly which diff you wanted
> to update later
> ​.
>

​The important thing when de-phabbing the commit message is to keep the

"Differential Revision: ..."

line intact; that way `arc` and Phabricator recognise what differential the
commit belongs to.

​
​I always de-phab the commit messages before landing manually (alas `arc
land` is useless here) because otherwise we end up with non-idiomatic
commit messages which look terrible everywhere else except in
Phabricator... :-/​
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

HEADS-UP: integer-gmp2 landed!

[Herbert Valerio Riedel]

Hello GHC devs,

A few minutes ago, I landed `integer-gmp2` to master!

Ideally, you shouldn't notice any breakages (I've tried to make sure all
tier-1 platform configuration work...), but if you do have problems,
please report any issues/regressions you encounter to me!

Morever, should something break in a way that blocks you on your
platform, just add "INTEGER_LIBRARY=integer-gmp" to the end of your
mk/build.mk (or edit mk/config.mk.in locally), and you'll get the "old"
integer-gmp which worked previously, so you can continue hacking on GHC
HEAD while I figure out what's broken for you with `integer-gmp2`
(assuming you reported the issue to me...).

Cheers,
  hvr

 [1]: 
http://git.haskell.org/ghc.git/commitdiff/c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Implement new integer-gmp2 from scratch (re #9281) (c774b28)

[Herbert Valerio Riedel]

On 2014-11-12 at 11:22:25 +0100, Simon Peyton Jones wrote:
> Great stuff.  But why do primetest, rsa, and mandel allocate so much
> more?  You mention different accounting, but I've found that it is
> often worth really understanding what is happening because you
> discover "Oh, yes, that's egregiously bad, and easily fixed".

Oh, but I still plan to investigate those allocation numbers a bit more
to give a more exhaustive explaination (or even fix them)!

But I've already got a few ideas where to look: For instance,for the old
integer-gmp I did that trick to to avoid single-limb allocations (by
using a C stack-allocated temp buffer instead) so much as to avoid them
altogether, and I may have lost some of those opportunities due to the
different design.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Herbert Valerio Riedel]

Hello Merijn,

On 2014-11-14 at 05:22:11 +0100, Merijn Verstraaten wrote:
> As requested on my ticket I summarised the entire proposal on the wiki
> here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension

I don't see Cabal mentioned anywhere on that wiki page. Doesn't Cabal
need to be made aware of those new extensions?

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS UP: haskell{98,2010} and old-{time,locale} deleted

[Herbert Valerio Riedel]

On 2014-11-21 at 06:09:06 +0100, Bardur Arantsson wrote:

[...]

> Does this mean that any code compiling against the current release of
> old-locale (1.0.0.6) will fail to compile with GHC 7.10.x? I ask because
> I note that old-locale (1.0.0.6) depends on
>
>   base >= 4.2 && < 4.8
>
> and presumably GHC 7.10.x will have a new "base" version? (Which will
> exclude old-locale 1.0.0.6 from any Cabal install plan.)

Oh it's quite simple, old-{time,locale} will continue to live on via
Hackage; We'll upload GHC 7.10 compatible versions of those two packages
to Hackage soon.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS UP: haskell{98,2010} and old-{time,locale} deleted

[Herbert Valerio Riedel]

On 2014-11-21 at 08:41:21 +0100, Herbert Valerio Riedel wrote:

[...]

> Oh it's quite simple, old-{time,locale} will continue to live on via
> Hackage; We'll upload GHC 7.10 compatible versions of those two packages
> to Hackage soon.

PS: I've already uploaded new {base-4.8,GHC-7.10}-compatible versions:

 - http://hackage.haskell.org/package/old-locale-1.0.0.7

 - http://hackage.haskell.org/package/old-time-1.1.0.3

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC filepath sync

[Herbert Valerio Riedel]

On 2014-11-21 at 18:13:16 +0100, Neil Mitchell wrote:
> As part of the forthcoming GHC release, I assume the filepath library
> will be sync'd to the latest version in the GitHub repo? When will
> that sync happen? 

We'll probably try to sync up w/ filepath's current master-tip for the
upcoming freeze to make sure it still builds. And then shortly before
the first GHC 7.10.1 RC is cut sometime around mid-december (if nothing
changes).

> Who will do the sync? 

It'll be probably me, or Austin

> When is the last time I can make changes that go into GHC 7.10?

*Ideally* we'd want to have the libraries in a frozen RC-ish state
before we cut the GHC 7.10.1 RC

> What should I be doing to help? As this is my first time, any details
> would be most appreciated.

If you can time it so that `filepath` is in a releasable state (i.e. you
don't need to actually upload it to Hackage) shortly before the first
RC, it'd be great. 

Then, if during the public GHC 7.10.1 RC test-phase serious issues with
the filepath package are found, it would very desirable for those to be
fixed upstream in `filepath` in a timely manner in order to ship the
final GHC 7.10.1 with a final bug-free `filepath` package.


...does that make any sense so far? :-)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Be consistent with placement of Safe Haskell mode at top of file (2a523eb)

[Herbert Valerio Riedel]

Hello David,

On 2014-11-21 at 22:03:23 +0100, git-4Dsf34iY/nkouohngz6...@public.gmane.org 
wrote:

[...]

> commit 2a523ebf091478aea39deef28073320bed628434
> Author: David Terei 
> Date:   Wed Nov 19 18:29:51 2014 -0800
>
> Be consistent with placement of Safe Haskell mode at top of file

Why is that necessary?

Fwiw, I'm afraid that's gonna be hard to retain; it's more
obvious/easier to keep all LANGUAGE pragmas in alphabetic order (I've
probably done that a couple of times in `base` deliberately myself) than
to introduce such an artificial ordering on the language pragmas.

The reason is, you can instruct an editor to select the first paragraph
which comprises the block of one-per-line language-pragmas is, and have
it sorted it alphabetically. That's just a few keystrokes. But it's
rather difficult to teach the editor to use an ordering relation other
than the usual alphabetic/lexicographic ordering.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Herbert Valerio Riedel]

On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
>> linker_unload:
>> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
>> unknown symbol `__gmpn_rshift'

> Herbert, perhaps this is integer-gmp2 breakage?

...can't rule it out, but I haven't seen that failure anywhere else so
far (including http://haskell.inf.elte.hu/builders/) and can't reproduce
it myself either :-/

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Herbert Valerio Riedel]

Hello Simon,

On 2014-11-21 at 14:51:55 +0100, Simon Peyton Jones wrote:
> I'm getting this for test linker_unload on Linux. I'm sure it's not my fault!
>
> But it makes validate fail

[...]

> linker_unload:
> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
> unknown symbol `__gmpn_rshift'
> linker_unload: resolveObjs failed
> make[3]: *** [linker_unload] Error 1

I've tried this in an Ubuntu 12.04.5 LTS/x86_64 environment, but
couldn't reproduce it.

I'm quite confident that '__gmpn_rshift' is in fact not missing,
otherwise you'd get much more failures (and GHC probably wouldn't even
build). I also don't think that Ubuntu 12.04's is too old, as it's a GMP
5.0.2 version afaik.

Does `TEST=linker_unload` fail deterministically?

Would it be possible to update your `sudo apt-get update` & `sudo
apt-get dist-upgrade` your Linux environment with the latest bugfixes to
Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
fixed upstream...


Finally, if that also doesn't help, can you try cloning a fresh tree via

   git clone --recursive git://ghc.haskell.org/ghc.git 

and invoke ./validate inside ?


HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Herbert Valerio Riedel]

On 2014-11-25 at 08:23:04 +0100, Karel Gardas wrote:
> On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:
>> Would it be possible to update your `sudo apt-get update`&  `sudo
>> apt-get dist-upgrade` your Linux environment with the latest bugfixes to
>> Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
>> fixed upstream...
>
> I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you
> should use is probably
> `sudo apt-get update` &  `sudo apt-get upgrade`

http://askubuntu.com/questions/215267/will-apt-get-dist-upgrade-upgrade-my-system-to-newer-version

TLDR: no, `apt-get dist-upgrade` will not ugrade away from the 12.04.x branch
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[Herbert Valerio Riedel]

On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote:
> 2014-11-25 20:46 GMT+01:00 Austin Seipp :
>> We are pleased to announce the first release candidate for GHC 7.8.4:
>>
>> https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]
>
> Would it be possible to get the RC on
> https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
> easily test things on Travis CI.

I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10
branch has been created)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: superfluous ghc --make log?

[Herbert Valerio Riedel]

On 2014-11-27 at 18:32:47 +0100, Tuncer Ayaz wrote:
> This is a very minor "issue", but I've been wondering if there's
> a rationale behind ghc --make pretty much printing the same thing
> thrice.

IMO it isn't the "same" thing that's printed thrice. If you
e.g. compile `transformers`, you'd get the following output:

Preprocessing library transformers-0.4.2.0...
[ 1 of 28] Compiling Data.Functor.Identity ( oldsrc/Data/Functor/Identity.hs, 
dist/build/Data/Functor/Identity.o )
[ 2 of 28] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, 
dist/build/Control/Monad/Trans/Class.o )
[ 3 of 28] Compiling Control.Monad.Signatures ( Control/Monad/Signatures.hs, 
dist/build/Control/Monad/Signatures.o )
...

there you'd see the two pathnames are not necessarily directly derivable
from the module name, but depend on additional flags given to `ghc`...

So it does indeed provide additional information about what GHC is
doing. Btw, this also tells you whether a .hs file or a .lhs file was
picked up.

As to whether it's too noisy for the default verbosity level, I have no
opinion (yet)...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Herbert Valerio Riedel]

Hello Simon,

On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> |  Just a hunch... could it have been broken by one of the recent linker-
> |  related patches since Nov 24th?
>
> That seems very plausible, yes.  But still there's the question of
> what to do about it.

 a) Empirically: Try locally 'git revert'ing

 383733b9191a36e2d3f757700842dbc3855911d9 

 and/or

 b5e8b3b162b3ff15ae6caf1afc659565365f54a8

 and see if your problem goes away, or

 b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
he sees something odd in those patches that could have broken
Windows' GHCi...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Herbert Valerio Riedel]

On 2014-12-03 at 09:38:09 +0100, Joachim Breitner wrote:
> Am Mittwoch, den 03.12.2014, 09:25 +0100 schrieb Joachim Breitner:
>> I can confirm this on my performance builder machine (Ubuntu 13.10):
>
> and on Ubuntu 14.04. Reported as
> http://ghc.haskell.org/trac/ghc/ticket/9856
>
> This was clearly triggered by the integer-gmp2 commit.

...but why don't we see it everywhere (I for one have never experienced
the linker_unload failure myself (which makes it difficult to debug...),
and neither did Phab)? What's triggering it only on some configurations?

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Herbert Valerio Riedel]

On 2014-12-03 at 09:48:58 +0100, Simon Peyton Jones wrote:
> I did the Ubuntu upgrade thing, and it's still happening for me too.
>
> I have no idea how to narrow it down some more.

I had a short conversation w/ Joachim on #ghc, and what we know so far:

For a non-failing linker_unload environment, the testprogram is linked
against libgmp.so:

$ ldd tests/rts/linker_unload 
linux-vdso.so.1 =>  (0x7fff20f6c000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7f83c5bbb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f83c58b5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f83c56ac000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f83c54a8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f83c50e3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f83c4ec4000)
/lib64/ld-linux-x86-64.so.2 (0x7f83c5e76000)

Also, in the reported test failure, the failure occurs when calling
resolveObjs() on the Test.o file (after the libHS-libs were already
succesfully loadPkg()ed)


r = loadObj(OBJPATH);
if (!r) {
errorBelch("loadObj(%s) failed", OBJPATH);
exit(1);
}
r = resolveObjs();
if (!r) {
errorBelch("resolveObjs failed");
exit(1);
}


Alas we still don't know what property of the build-environment
determines whether this test fails or succeeds... :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can we rename completion to autocomplete

[Herbert Valerio Riedel]

On 2014-12-05 at 10:01:54 +0100, Edward Z. Yang wrote:
> I keep typing 'comp' and expecting it to autocomplete to compiler,
> and this is stopped working. Can we rename the 'completion' directory
> to something? How about 'autocomplete'?

I'm not sure about the folder-name/location either. I'm used to see
completion-scripts and similiar in sub-folders of 'contrib/', e.g.

 https://github.com/git/git/tree/master/contrib/completion

otoh, we do already have a 'utils/' folder, we could simply move it
there, as ghc's top-folder is already quite crowded...

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: docker GHC image for hacking

[Herbert Valerio Riedel]

On 2014-12-09 at 23:47:01 +0100, Greg Weber wrote:
> I added documentation to
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and linked
> from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX

Btw, you write

> This way you can still hack on GHC with Emacs, etc, but you are just
> building from the docker container.

...does that mean you can't invoke `make` directly from within Emacs via
`M-x haskell-compile`?

I'm still trying to understand what you meant exactly by "too high an
overhead to getting started" with GHC development (as I don't consider
having to basically `apt-get install ...` (and possibly `cabal install
...` if your distribution doesn't have a recent alex/happy package) such
a high overhead to get your system able to compile a cloned GHC source
tree)

So I'd like to identify what you consider an overhead to improve the
underlying issues to make it easier for interested parties to get up and
running with GHC development.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Trouble committing

[Herbert Valerio Riedel]

On 2014-12-14 at 08:46:03 +0100, Erik de Castro Lopo wrote:

[...]

>> $ git push origin master
>> 
>> as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on
>> the last command I get this error:
>> 
>> fatal: remote error: access denied or repository not exported: /ghc.git
>> 
>> Maybe I just no longer have commit access to ghc?
>
> Andi,
>
> Did you get a response to this? I seem to be in the same boat for D570.

What does the following command output in your case?

$ git remote show -n origin | grep URL
  Fetch URL: git://git.haskell.org/ghc.git
  Push  URL: ssh://g...@git.haskell.org/ghc.git
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Herbert Valerio Riedel]

Hello Richard,

Can you please push the fix asap to master? This performance failures
are causing distracting false alarms (in terms of validation failures)
on each pushed commit as well as submitted code-revisions.

Thanks,
  HVR
  
On 2014-12-13 at 16:55:40 +0100, Richard Eisenberg wrote:
> Fixed, hopefully!
>
> On Dec 13, 2014, at 10:03 AM, Richard Eisenberg  wrote:
>
>> I think I've fixed this. I've pushed the fix to wip/rae, and waiting for 
>> validation results before pushing to master.
>> 
>> My hunch below was right -- it was the change to matchFam, which
>> essentially evaluated type-level functions more strictly. I've now
>> made it lazier again. I'd like to better understand the tradeoff
>> here, and to see if there's a principled sweet spot. But that will
>> happen in a few days.
>> 
>> Expect a push to master soon.
>> 
>> Again, sorry for the bother.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Trouble committing

[Herbert Valerio Riedel]

On 2014-12-14 at 11:25:35 +0100, Erik de Castro Lopo wrote:
>> What does the following command output in your case?
>> 
>> $ git remote show -n origin | grep URL
>>   Fetch URL: git://git.haskell.org/ghc.git
>>   Push  URL: ssh://g...@git.haskell.org/ghc.git
>
> Fixed it with some help from ezyang who suggested:
>
> git remote set-url origin --push ssh://g...@git.haskell.org/ghc.git

That works too, but the more general approach (so you don't have to
repeat the step above for other ghc.git repos and/or each submodule
separately) is described below:

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Pushaccess

Cheers,
  HVR
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Customizing Phab

[Herbert Valerio Riedel]

On 2014-12-16 at 14:58:16 +0100, Jan Stolarek wrote:

[...]

> I can't find any such settings so I suppose that's not possible by
> default. Is there any way to extend Phab's functionality do allow
> customizing layout in a way described above?

Not a direct answer to your question, but have you tried the 'z' hotkey
(or "keyboard shortcut") while in a revision? It "cycles comment panel
haunting modes" (see '?' hotkey for a list of other useful hotkeys).

HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Herbert Valerio Riedel]

On 2014-12-16 at 22:45:36 +0100, Richard Eisenberg wrote:
> I've learned several very interesting things in this analysis.
>
> - Inlining polymorphic methods is very important. 

otoh, there are cases where marking methods INLINE have catastrophic
effects; the following

  
https://github.com/kolmodin/binary/commit/48c02966512a67b018fcdf093fab8d34bddf9a69

was necessary a few months ago, as otherwise GHC HEAD's compile-time
memory usage would explode:

  https://ghc.haskell.org/trac/ghc/ticket/9630

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Perl for Windows and GHC

[Herbert Valerio Riedel]

On 2014-12-21 at 09:54:05 +0100, Gintautas Miliauskas wrote:

[...]

> Are there any utilities other than ghc-split which rely on perl at ghc
> runtime? If not, are there any plans to convert ghc-split to a sane
> language? I would sign up if I knew I would have the time... :(

https://ghc.haskell.org/trac/ghc/ticket/9832 :-)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC 7.10.1 / cabal-install 1.22 Ubuntu-PPA pre-RC snapshots available!

[Herbert Valerio Riedel]

To early adopters & multi-ghc-travis users,

I've uploaded pre-RC snapshots for GHC 7.10.1 and cabal-install 1.22
to my GHC PPA[1], so you can start extending your .travis.yml files w/ 

  CABALVER=1.22 GHCVER=7.10.1

There are no official RCs yet for GHC 7.10/cabal-install 1.22, these are
merely snapshots from the respective Git branches which I'll keep
updating regularly (every 1-3 days) till the final proper release for
GHC 7.10.1 and cabal-install 1.22.0.0 occur, at which point those
packages (`ghc-7.10-*` & `cabal-install-1.22`) will install the final
release versions.

The usual official release-candidates (including respective
announcements) for GHC & cabal will follow soon.

So please, help us finding issues/bugs with these pre-RC snapshots of
GHC & cabal-install. Obviously, it's desirable to become aware of any
serious issues ASAP, as opposed to shortly before the planned final
release date...

As these are Git snapshots, when reporting bugs/issues, please also
provide the snapshot's Git commit id (which uniquely identifies the GHC
source-tree state), which can be queried via a new GHC CLI option, e.g.:

  $ ghc --print-project-git-commit-id
  a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a

Here's an example build using 7.10.1 to show those packages actually
work:

  https://travis-ci.org/haskell/unix/builds/44919992


 [1]: https://github.com/hvr/multi-ghc-travis
  https://launchpad.net/~hvr/+archive/ubuntu/ghc
 

Cheers,
  hvr


PS: If you happen to run into compile errors for Hackage packages which
claim to work with GHC 7.10.1 (e.g. by allowing `base-4.8`), I'd be
interested to hear about it.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC 7.10.x migration guide

[Herbert Valerio Riedel]

Hello!

I've started collecting the most common compile-errors (and their
respective fixes) I have encountered while compiling Hackage packages
with GHC 7.10 in

  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10

Feel free to contribute to this migration guide.

HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Herbert Valerio Riedel]

On 2014-12-28 at 04:41:45 +0100, cg wrote:

[...]

> Besides downloading a tarball, can I checkout it using git?
>
> I tried using sync-all as described on wiki [1] to checkout it:
>
> ./sync-all checkout ghc-7.10
>
> but it seems it doesn't work, there are error message like:
> error: pathspec 'ghc-7.10' did not match any file(s) known to git.

Rather follow

  
https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingabranchGHC7.9orlater

and/or

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules

i.e.

  git clone -b ghc-7.10 --recursive git://git.haskell.org/ghc.git

or (if you have already a GHC 7.9.x tree cloned out), use

  git checkout ghc-7.10 && git submodule update --init

to switch to the ghc-7.10 branch (and update the submodules)

HTH,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Limiting size of global package database

[Herbert Valerio Riedel]

Hello Michael,

On 2014-12-31 at 15:10:37 +0100, Michael Snoyman wrote:
> tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library),
> can we remove Cabal from the global package database installed with GHC?

[...]

> For both of these reasons, I think we should limit the number of packages
> included in the global package database. One seemingly small step we could
> do on that front is not include extraneous packages. In GHC 7.10rc1, that
> includes Cabal and xhtml: 

btw, haskeline and terminfo should be considered as well, according to
your argument.

> both packages are in the global package database, but could just as
> easily be removed from there and installed by users. The motivation
> for that would be to avoid problem (1) above.

However, as for xhtml, haskeline and terminfo, we had to register/expose
them in the global pkg DB due to

  https://ghc.haskell.org/trac/ghc/ticket/8919

and as for Cabal, I have been told (maybe Duncan can weigh in...?) that
Haskell implementations need to provide it (together with a `*hc-pkg`
executable) in order to conform to the CABAL specification[1].


Cheers,
  hvr

 [1]: https://www.haskell.org/cabal/proposal/pkg-spec.pdf
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS

[Herbert Valerio Riedel]

On 2015-01-01 at 14:58:40 +0100, George Colpitts wrote:
> I built from source on Mac OS and found the following issues:

[...]

>- ​cabal install cpphs fails:​
>-cabal install cpphs
>   Resolving dependencies...
>   Configuring cpphs-1.13...
>   Building cpphs-1.13...
>   Failed to install cpphs-1.13
>   Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ):
>   Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
>   Fields allowed in this section:
>   name, version, cabal-version, build-type, license, license-file,
>   license-files, copyright, maintainer, stability, homepage,
>   package-url, bug-reports, synopsis, description, category, author,
>   tested-with, data-files, data-dir, extra-source-files,
>   extra-tmp-files, extra-doc-files
>   Configuring cpphs-1.13...
>   Building cpphs-1.13...
>   Preprocessing library cpphs-1.13...
>   - Language/Preprocessor/Cpphs.hs:1:1:
>   Could not find module ‘Prelude’
>   It is a member of the hidden package ‘base-4.8.0.0’.
>   Perhaps you need to add ‘base’ to the build-depends in your
>   .cabal file.
>   Use -v to see a list of the files searched for.

[...]

This is a known issue; cpphs-1.18.6 would actually work with GHC
7.10/base-4.8, but it depends on polyparse, but there isn't yet a
polyparse version compatible w/ base-4.8 (due to AMP) on Hackage[1]

Otoh, cpphs-1.13 is selected even though Hackage shows that it has a
constraint `base <4.8`. However, that's rather a bug in Hackage, as the
`.cabal` file is actually invalid, as it has the `build-depends` at the
wrong level. So effectively it has no build-depends line at all, so
cabal-install is led to believe that it works w/o any build-deps at
all.. I did file an issue about that[3]








 [1]: Coincidentally, I sent Malcolm a AMP-compatibility patch for
  polyparse just earlier today...

 [2]: http://hackage.haskell.org/package/cpphs-1.13

 [3]: https://github.com/haskell/hackage-server/issues/303
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build gotchas

[Herbert Valerio Riedel]

Hello Martin,

Here's just some minor additional context information...

On 2015-01-01 at 19:01:53 +0100, Martin Foster wrote:

[...]

>- I note "./sync-all --help" says, under "Flags", that "--windows also
>clones the ghc-tarballs repository (enabled by default on Windows)", and
>I've confirmed that default behaviour experimentally - but
>https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources tells
>you to manually clone ghc-tarballs when on Windows. Is that line on the
>wiki obsolete, or am I overlooking something?

Somewhat related: when

  https://phabricator.haskell.org/D339

is landed, we can finally forget about having to clone that
objectionable ghc-tarballs repo...

[...]

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

That's btw because Cabal/GHC uses `getAppUserDataDirectory "cabal"` and
`getAppUserDataDirectory "ghc"` respectively...


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC 7.4.2 on Ubuntu Trusty

[Herbert Valerio Riedel]

Hello Edward,

On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote:

[...]

> There are also some changes to hoopl, transformers and hpc (mostly
> because their bootstrap libraries.)

...what kind of changes specifically? 

Once thing that needs to be considered is that we'd require to upstream
changes to transformers (it's not under GHC HQ's direct control) for a
transformers point(?) release ... and we'd need that as we can't release
any source-tarball that contains libraries (which get installed into the
pkg-db) that don't match their upstream version on Hackage.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Updating submodules

[Herbert Valerio Riedel]

Hello Simon,

On 2015-01-06 at 10:59:44 +0100, Simon Peyton Jones wrote:
> I'm very confused about the workflow for updating submodules.  I want
> to update several (to remove redundant constraints from contexts)
> which are maintained by GHC HQ.  But for libraries/parallel I find:
>
>

> * There is no .git/config in libraries/parallel.  (Whereas
> there is for another submodule, libraries/hoopl.)

> * There is, however, a .git file which points to 
> .git/modules/libraries/parallel

That's most likely because libraries/hoopl wasn't created via `git
submodule` but rather inherited from a Git checkout where
libraries/hoopl was an decoupled (not yet submodule) sub-repo...

In any case, if you manage Git remotes (while in libraries/hoopl) via
the `git remote` command, Git takes care of following the "symlinked"
.git folder...

> * In .git/modules/libraries/parallel/config, I see a url of
> https://git.haskell.org/packages/parallel.git.  But I can't push to
> this URL.

yes, that's our mirrored copy of github.com/haskell/parallel/

> * That matches the url in
> https://ghc.haskell.org/trac/ghc/wiki/Repositories, but contradicts
> the url in 'packages', which says

> ssh://g...@github.com/haskell/parallel.git

yes, that's exactly the upstream URL you're supposed to push to...  (and
since it's a ssh:// protocl url, it means you should have push-rights
there)

> * I don't understand what URL should be expected for submodules with
> "-" in the 'upstream url' column of the 'packages' file.  It says "-"
> means 'this is a submodule', but parallel is certainly a submodule and
> doesn't have "-".  

The comment there is probably a bit misleading;

"-" in the "upstreamurl" field just means that the official upstream
repo is at git.haskell.org, and you should use the usual
ssh://git.haskell.org/... URL for pushing...

> But so is hoopl, which does have "-".
> I tried a minimal change of adding
>pushurl = ssh://g...@git.haskell.org/packages/hoopl.git

are you confusing 'hoopl' with 'parallel' here?

hoopl's upstream is in fact at git.haskell.org, but parallel lives at
github.com/haskell/parallel ...

> to .git/modules/libraries/parallel/config.  But when I tried to push I got
> simonpj@cam-05-unx:~/code/HEAD-2/libraries/parallel$ git push
> Counting objects: 7, done.
> Delta compression using up to 32 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 410 bytes, done.
> Total 4 (delta 3), reused 0 (delta 0)
> remote: W refs/heads/master packages/parallel simonpj DENIED by refs/.*
> remote: error: hook declined to update refs/heads/master
> To ssh://g...@git.haskell.org/packages/parallel.git
> ! [remote rejected] HEAD -> master (hook declined)
> error: failed to push some refs to 
> 'ssh://g...@git.haskell.org/packages/parallel.git'
>
> So I'm thoroughly stuck. I can't push my main patch until I push the 
> submodule patches.  What do I do?
> And would it be possible to update the wiki pages to make this clear?  
> Especially
>
> * https://ghc.haskell.org/trac/ghc/wiki/Repositories
>
> * 
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
>
> Thanks
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

warning-suppression granularity (was: Redundant constraints)

[Herbert Valerio Riedel]

On 2015-01-07 at 16:40:49 +0100, Simon Peyton Jones wrote:

[...]

> Yes, a per-function way to suppress the warning might be useful.  But
> I have not implemented that.  At the moment it’s just per-module.

Btw, there are a couple of other warnings, I have been wishing to have a
way to disable them on a per-entity basis... any chance for for a
general syntax to suppress warnings on a more granular level than
per-module?

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Cabal update fails

[Herbert Valerio Riedel]

On 2015-01-07 at 17:12:01 +0100, Simon Peyton Jones wrote:
> What does this mean (on Linux)?
>
> Thanks, Simon
>
> bash$ cabal update
> Downloading the latest package list from hackage.haskell.org
> cabal: : resource vanished

Simply a network error while communicating w/ hackage... does `cabal
update -v3` give any useful indication?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Herbert Valerio Riedel]

On 2015-01-09 at 11:09:07 +0100, Roman Cheplyaka wrote:
[...]
>>> Just curious, is there a way to keep these functions for backwards compat
>>> in 7.14 or is that unfeasible?
>> They could stay, technically that's not a problem. But I'm adding new 
>> functions that can do the 
>> same thing (and more), so we have redundancy.
>
> Can you hide them in the haddock but leave in the module, so that we
> don't break existing code?

Why hide them? DEPRECATEd entities have the deprecation-message shown in
discouraging red letters (including any hyperlinks to their
replacements) in the generated Haddock documentation...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Herbert Valerio Riedel]

On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote:

> The reall 
> question is how to remember that we should remove this at some point?

This affects all exposed libraries; I think it's enough to simply make
this part of the release-procedure at some point in the release-cycle,
to actively scan all DEPRECATIONs, and decide for each whether to kill
them or let them live for another cycle.

It simplifies things though, if it's obvious when a deprecation was
declared so one doesn't have to `git blame` for it. Many deprecations
already have a comment attached like "deprecated in GHC x.y"
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Build failure under Fedora 21

[Herbert Valerio Riedel]

On 2015-01-17 at 09:22:05 +0100, Dominick Samperi wrote:
> It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
> when installing pandoc is not related to the use of CentOS or Debian
> binaries. I get the same undefined reference when I try to use
> ghc-7.8.4 compiled from source under Fedora 21. Here is the output of
> 'locate libHSprimitive':
>
> /home/dsamperi/.cabal/lib/primitive-0.5.4.0/ghc-7.8.4/libHSprimitive-0.5.4.0.a
> /usr/lib64/ghc-7.6.3/primitive-0.5.0.1/libHSprimitive-0.5.0.1-ghc7.6.3.so
> /usr/lib64/ghc-7.6.3/primitive-0.5.0.1/libHSprimitive-0.5.0.1.a
> /usr/lib64/ghc-7.6.3/primitive-0.5.0.1/libHSprimitive-0.5.0.1_p.a
>
>
> So there is a .a library, but no .so (shared) lib in the build from
> source. Can someone explain how to get the build process to create all
> necessary shared libs?

How did you compile GHC? Iirc `primitive` isn't supposed to be
built/installed/used unless you enable DPH

(otherwise, it would lead to a similiar issue like
https://ghc.haskell.org/trac/ghc/ticket/8919)

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs