Re: Proposal: Improving the LLVM backend by packaging it

[Sophie Taylor]

Also, it could be a chance to make it easier to experiment with things like
polly: http://polly.llvm.org/

On 31 October 2014 15:18, Sophie Taylor  wrote:

> If this does happen, it'd probably make sense to use this as a chance to
> refactor out the LLVM bits and use the llvm-general package. llvm-general
> seems to only depend on base libraries (apart from parsec, which seems to
> only be used for parsing data layout formats; it could probably be disabled
> with a compiler flag if we construct the data layout structures directly;
> see
> https://github.com/bscarlet/llvm-general/blob/5f266db5ad8015f7d79374684b083ffdeed3c245/llvm-general-pure/src/LLVM/General/DataLayout.hs).
> It seems a more principled way than what is currently implemented, and work
> done to improve that library via ghc would also help every other user of
> the library, and visa versa.
>
> On 27 October 2014 19:25, Sergei Trofimovich  wrote:
>
>> On Fri, 24 Oct 2014 18:52:53 -0500
>> Austin Seipp  wrote:
>>
>> > I won't repeat what's on the wiki page too much, but the TL;DR version
>> > is: we should start packaging a version of LLVM, and shipping it with
>> > e.g. binary distributions of GHC. It's just a lot better for everyone.
>> >
>> > I know we're normally fairly hesitant about things like this (shipping
>> > external dependencies), but I think it's the only sane thing to do
>> > here, and the situation is fairly unique in that it's not actually
>> > very complicated to implement or support, I think.
>>
>> That makes a lot of sense! Gentoo allows user
>> upgrade llvm and ghc independently, which makes
>> syncing harder. Thus Gentoo does not care much
>> about llvm support in ghc.
>>
>> --
>>
>>   Sergei
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal: Improving the LLVM backend by packaging it

[Sophie Taylor]

If this does happen, it'd probably make sense to use this as a chance to
refactor out the LLVM bits and use the llvm-general package. llvm-general
seems to only depend on base libraries (apart from parsec, which seems to
only be used for parsing data layout formats; it could probably be disabled
with a compiler flag if we construct the data layout structures directly;
see
https://github.com/bscarlet/llvm-general/blob/5f266db5ad8015f7d79374684b083ffdeed3c245/llvm-general-pure/src/LLVM/General/DataLayout.hs).
It seems a more principled way than what is currently implemented, and work
done to improve that library via ghc would also help every other user of
the library, and visa versa.

On 27 October 2014 19:25, Sergei Trofimovich  wrote:

> On Fri, 24 Oct 2014 18:52:53 -0500
> Austin Seipp  wrote:
>
> > I won't repeat what's on the wiki page too much, but the TL;DR version
> > is: we should start packaging a version of LLVM, and shipping it with
> > e.g. binary distributions of GHC. It's just a lot better for everyone.
> >
> > I know we're normally fairly hesitant about things like this (shipping
> > external dependencies), but I think it's the only sane thing to do
> > here, and the situation is fairly unique in that it's not actually
> > very complicated to implement or support, I think.
>
> That makes a lot of sense! Gentoo allows user
> upgrade llvm and ghc independently, which makes
> syncing harder. Thus Gentoo does not care much
> about llvm support in ghc.
>
> --
>
>   Sergei
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: cabal sdist trouble with GHC from head

[Mikhail Glushenkov]

Hi,

On 30 October 2014 21:30, Sven Panne  wrote:
> 2014-10-30 17:20 GMT+01:00 Austin Seipp :
>> [...] So this just means that Cabal isn't necessarily *future compatible*
>> with future GHCs - they may change the package format, etc. But it is
>> backwards compatible with existing ones.
>
> OK, that's good to know. To be sure, I've just tested Cabal head + GHC
> 7.8.3, and it works. But as I've mentioned already, there seems to be
> *no* Cabal version which works with GHC head:
> https://travis-ci.org/haskell-opengl/StateVar/builds/39533448 Is this
> known to the Cabal people?

Yes, I know that the Cabal test suite wasn't passing on GHC HEAD for some time.

Re: the next release - I think it'll be out at the same time with GHC 7.10.1.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Carter Schonwald]

I agree with herbert, and one solution would be to ask those people who
which to remain pseudonymous to have a named person who's agreed to be
their proxy co-sign the patch or whatever.  That i think accomplishes that
same goal :)

On Thu, Oct 30, 2014 at 7:34 PM, Herbert Valerio Riedel 
wrote:

> 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
>
___
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: Tests with compilation errors

[Gintautas Miliauskas]

> > On a related note, how about separating test failures from failing
> > performance tests ("stat too good" / "stat not good enough")? The latter
> are
> > important, but they seem to be much more prone to fail without good
> reason.
>
> I also think this is a good idea.
>

https://phabricator.haskell.org/D406

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

Re: Tests with compilation errors

[Nicolas Frisby]

This reply is very informative! Could you put it on the wiki for me to
digest at a later date? (Or maybe there's already a consolidated place to
find it all on there?)

Thanks very much for sharing all of this.

On Thu, Oct 30, 2014 at 2:19 PM, Austin Seipp  wrote:

> On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas
>  wrote:
> > Going through some validate.sh results, I found compilation errors due to
> > missing libraries, like this one:
> >
> > => stm052(normal) 4088 of 4108 [0, 21, 0]
> > cd ../../libraries/stm/tests &&
> > 'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'
> > -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output
> -no-user-package-db
> > -rtsopt
> > s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm
> >>stm052.comp.stderr 2>&1
> > Compile failed (status 256) errors were:
> >
> > stm052.hs:10:8:
> > Could not find module ‘System.Random’
> > Use -v to see a list of the files searched for.
> >
> > I was surprised to see that these are not listed in the test summary at
> the
> > end of the test run, but only counted towards the "X had missing
> libraries"
> > row. That setup makes it really easy to miss them, and I can't think of a
> > good reason to sweep such tests under the rug; a broken test is a failing
> > test.
>
> Actually, these tests aren't broken in the way you think :) It's a bit
> long-winded to explain...
>
> Basically, GHC can, if you let it, build extra dependencies in its
> build process, one of which is the 'random' library. 'random' was not
> ever a true requirement to build GHC (aka a 'bootlib' as we call
> them). So why is this test here?
>
> Because 'random' was actually a dependency of the Data Parallel
> Haskell package, and until not too long ago (earlier this year),
> `./validate` built and compiled DPH - with all its dependencies;
> random, vector, primitive - by default. This actually adds a pretty
> noticeable time to the build (you are compiling 5-8 more libraries
> after all), and at the time, DPH was also not ready for the
> Applicative-Monad patch. So we turned it off, as well as the
> dependencies.
>
> Additionally, GHC does have some 'extra' libraries which you can
> optionally build during the build process, but which are turned off by
> default. Originally this was because the weirdo './sync-all' script
> used to not need everything, and 'stm' was a library that wasn't
> cloned by default.
>
> Now that we've submoduleified everything though, these tests and the
> extra libraries could be built by default. Which we could certainly
> do.
>
> > How about at least listing such failed tests in the list of failed tests
> of
> > the end?
>
> I'd probably be OK with this.
>
> > At least in this case the error does not seem to be due to some missing
> > external dependencies (which probably would not be a great idea
> anyway...).
> > The test does pass if I remove the "-no-user-package-db" argument. What
> was
> > the intention here? Does packaging work somehow differently on Linux?
> (I'm
> > currently testing on Windows.)
>
> I'm just guessing but, I imagine you really don't want to remove
> '-no-user-package-db' at all, for any platform, otherwise Weird Things
> Might Happen, I'd assume.
>
> The TL;DR here is that when you build a copy of GHC and all the
> libraries, it actually *does* register the built packages for the
> compiler... this always happens, *even if you do not install it*. The
> primary 'global' package DB just sits in tree instead, under
> ./inplace.
>
> When you run ./validate, what happens is that after the build, we
> actually create a binary distribution and then test *that* compiler
> instead, as you can see (obviously for a good reason - broken bindists
> would be bad). The binary distribution obviously has its own set of
> binary packages it came with; those are the packages you built into it
> after all. The reason we tell GHC to ignore the user package db here
> is precisely because we *do not* want to pick it up! We only want to
> test the binary distribution with the packages *it* has.
>
> Now you might say, well, Austin, the version numbers are different!
> How would it pick that up? Not always... What if I built a copy of GHC
> HEAD today, then built something with it using Cabal? Then that will
> install into my user package database. Now I go back to my GHC tree
> and hack away _on the same day_ and run './validate'... the version
> number hasn't changed *at all* because it's date based, meaning the
> binary distribution could certainly pick up the previously installed
> libraries, which I installed via the older compiler. But I don't want
> that! I only want to run those tests with the compiler I'm validating
> *now*.
>
> I imagine the reason you see this test pass if you remove this
> argument is precisely for this reason: it doesn't fail because it's
> picking up a package database in your existing environment. But that's
> really, really not what you want (I'd be surprise

Re: RFC: Properly stated origin of code contributions

[Isaac Dupree]

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.

-Isaac

On 10/30/2014 04:13 AM, Herbert Valerio Riedel wrote:
> 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
> 

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

Re: Tests with compilation errors

[Austin Seipp]

On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas
 wrote:
> Going through some validate.sh results, I found compilation errors due to
> missing libraries, like this one:
>
> => stm052(normal) 4088 of 4108 [0, 21, 0]
> cd ../../libraries/stm/tests &&
> 'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'
> -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
> -rtsopt
> s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm
>>stm052.comp.stderr 2>&1
> Compile failed (status 256) errors were:
>
> stm052.hs:10:8:
> Could not find module ‘System.Random’
> Use -v to see a list of the files searched for.
>
> I was surprised to see that these are not listed in the test summary at the
> end of the test run, but only counted towards the "X had missing libraries"
> row. That setup makes it really easy to miss them, and I can't think of a
> good reason to sweep such tests under the rug; a broken test is a failing
> test.

Actually, these tests aren't broken in the way you think :) It's a bit
long-winded to explain...

Basically, GHC can, if you let it, build extra dependencies in its
build process, one of which is the 'random' library. 'random' was not
ever a true requirement to build GHC (aka a 'bootlib' as we call
them). So why is this test here?

Because 'random' was actually a dependency of the Data Parallel
Haskell package, and until not too long ago (earlier this year),
`./validate` built and compiled DPH - with all its dependencies;
random, vector, primitive - by default. This actually adds a pretty
noticeable time to the build (you are compiling 5-8 more libraries
after all), and at the time, DPH was also not ready for the
Applicative-Monad patch. So we turned it off, as well as the
dependencies.

Additionally, GHC does have some 'extra' libraries which you can
optionally build during the build process, but which are turned off by
default. Originally this was because the weirdo './sync-all' script
used to not need everything, and 'stm' was a library that wasn't
cloned by default.

Now that we've submoduleified everything though, these tests and the
extra libraries could be built by default. Which we could certainly
do.

> How about at least listing such failed tests in the list of failed tests of
> the end?

I'd probably be OK with this.

> At least in this case the error does not seem to be due to some missing
> external dependencies (which probably would not be a great idea anyway...).
> The test does pass if I remove the "-no-user-package-db" argument. What was
> the intention here? Does packaging work somehow differently on Linux? (I'm
> currently testing on Windows.)

I'm just guessing but, I imagine you really don't want to remove
'-no-user-package-db' at all, for any platform, otherwise Weird Things
Might Happen, I'd assume.

The TL;DR here is that when you build a copy of GHC and all the
libraries, it actually *does* register the built packages for the
compiler... this always happens, *even if you do not install it*. The
primary 'global' package DB just sits in tree instead, under
./inplace.

When you run ./validate, what happens is that after the build, we
actually create a binary distribution and then test *that* compiler
instead, as you can see (obviously for a good reason - broken bindists
would be bad). The binary distribution obviously has its own set of
binary packages it came with; those are the packages you built into it
after all. The reason we tell GHC to ignore the user package db here
is precisely because we *do not* want to pick it up! We only want to
test the binary distribution with the packages *it* has.

Now you might say, well, Austin, the version numbers are different!
How would it pick that up? Not always... What if I built a copy of GHC
HEAD today, then built something with it using Cabal? Then that will
install into my user package database. Now I go back to my GHC tree
and hack away _on the same day_ and run './validate'... the version
number hasn't changed *at all* because it's date based, meaning the
binary distribution could certainly pick up the previously installed
libraries, which I installed via the older compiler. But I don't want
that! I only want to run those tests with the compiler I'm validating
*now*.

I imagine the reason you see this test pass if you remove this
argument is precisely for this reason: it doesn't fail because it's
picking up a package database in your existing environment. But that's
really, really not what you want (I'd be surprised if it worked and
didn't result in some horrible error or crash).

> On a related note, how about separating test failures from failing
> performance tests ("stat too good" / "stat not good enough")? The latter are
> important, but they seem to be much more prone to fail without good reason.
> Perhaps do some color coding of the test runner output? That would also
> help.

I also think this is a good idea.

> --
> Gintautas Miliauskas
>
> 

Re: RFC: Properly stated origin of code contributions

[Austin Seipp]

I hate to spam this with possibly-tangential requests, but I also have a peeve:

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.

Ideally it would be nice if we could have, say, an AUTHORS.txt file
containing the names of all those people who have committed to GHC
(essentially like 'git shortlog -sn' shows), which we would ask users
to add their name into, and then if we could standardize all the
headers to follow a known convention, and give boilerplate for people
to copy.

On Thu, Oct 30, 2014 at 12:16 PM, Carter Schonwald
 wrote:
> yup, agreed
>
> -Carter
>
>
> On Thu, Oct 30, 2014 at 1:14 PM, Stephen Paul Weber
>  wrote:
>>
>> 
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: cabal sdist trouble with GHC from head

[Austin Seipp]

I would imagine they are well aware, what with all the changes that
have gone in the past few weeks (for backpack support, package db
overhauls, etc).

However, I think crux of it (and the real question) isn't are they
aware - but "When will there be a Cabal release that supports GHC
HEAD, which will become 7.10"? This is a question I'm afraid I cannot
answer - Johan does the typical Cabal releases, AFAIK.

I've CC'd Duncan and Johan - do either of you have plans for this?
Considering we hope the stable freeze will happen soon for 7.10, I
imagine Cabal won't be very far behind in this regard, but I'm not
sure if there's a plan set down anywhere as to when the next release
will happen.

On Thu, Oct 30, 2014 at 3:30 PM, Sven Panne  wrote:
> 2014-10-30 17:20 GMT+01:00 Austin Seipp :
>> [...] So this just means that Cabal isn't necessarily *future compatible*
>> with future GHCs - they may change the package format, etc. But it is
>> backwards compatible with existing ones.
>
> OK, that's good to know. To be sure, I've just tested Cabal head + GHC
> 7.8.3, and it works. But as I've mentioned already, there seems to be
> *no* Cabal version which works with GHC head:
> https://travis-ci.org/haskell-opengl/StateVar/builds/39533448 Is this
> known to the Cabal people?
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Austin Seipp]

For the record, I also think this is a great idea. I'll find a time
that works for me in the next few days (I've never used doodle but I
imagine I can manage).

On Thu, Oct 30, 2014 at 10:34 AM, Gintautas Miliauskas
 wrote:
>
>
> On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones 
> wrote:
>>
>> The people problem is tricky. At work, this would be the right time to do
>> a video chat and at least see the faces of the other people involved. Would
>> folks be interested in a Skype/Hangout sometime? It would be interesting to
>> hear what interests / skills / resources / constraints we have between us.
>>
>>
>>
>> I think that’s a great idea, thanks.  It’s easier to work with people with
>> whom you have formed a personal relationship, and a video conf is a good way
>> to do that.
>
>
> Let's try that. Shall we try to find a good timeslot? Sign up at
> http://doodle.com/34e598zc7m8sbaqm
>
> --
> Gintautas Miliauskas



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Austin Seipp]

Hey Gintautas,

Yes, I apologize about that (and I missed this request in my quick
read over this email yesterday). To be clear, I apologize if my
review/merge latencies are too long. :) What normally happens it that
I review and merge patches in bulk, about once or twice a week. I'll
review about, say, a dozen patches one day, and wait a few days for
more to come in, then sweep up everything in that time at once.

So there are two things: a review latency, *and* a merge latency.

However, two things are also clear:

 1) This is annoying for people who submit 'rapid improvements', e.g.
in the process of working on GHC, you may fix 4 or 5 things, and then
not having those in the mainline is a bit of a drain!
 2) Phabricator building patches actually means the merge latency can
be *shorter*, because in the past, we'd always have to double check if
a patch worked in the first place (so it took *even longer* before!)

Another thing is that I'm the primary person who lands things off
Phabricator, although occasionally other people do too. This is
somewhat suboptimal in some cases, since really, providing something
has the OK (from me or someone else), anyone should be able to merge
it. So I think this can be improved too.

Finally, it's also worth mentioning that Phabricator reviews are
special (and unlike GitHub) in that people who are *not* reviewers *do
not* see the patch by default! That means if I am the *only* person on
the review, it is pretty high guarantee that the review will only be
done by me, and it will only be merged by me, unless I poke someone
else. Others can see your review using a slightly different search
criterion, however, but that's not the default.

Note this is not a mistake - it is intentional in the design. Why?
Because realistically, I'd say for about 85% of the patches that come
in, they are irrelevant to 90% of all GHC developers, and
historically, 90% of developers will never bother committing it
either. It is often pointless to spam them with emails, and enlarging
their review queue beyond what's necessary makes things even *worse*
for them, since they can't tell what may really deserve their
attention. I do want more people reviewing code actively - but to do
that, there must be a tradeoff - we should try and keep contributor
burden low. Most developers are just our friends after all, including
you - not paid GHC hackers! I don't want to overburden you; we need
you!

I am one of the exceptions to this: I realistically care and want to
see about 95% of all patches that go into the tree, at least to keep
up to date with what's happening, and also to ensure things get proper
oversight - by, say, adding someone else to a review who I want to
look at it. This is why I'm the common denominator, and a reviewer of
almost every patch (and I think I'm fairly keen on who might care
about what).

However it's clear that if this is slowing you down we should try to
fix it - we want you to help after all! We already have nearly 40
people with commit rights to GHC, and you've clearly dedicated
yourself to helping. That's fantastic. Perhaps it's time for you to
enter the fray as well so I can get out of your way. :) But I do still
want you to submit code reviews, as everyone else does - it really
does help everyone, and increases a sense of shared ownership, IMO.

In light of this though, I do think I need to ramp up my merge
frequency. So how does a plan of just trying to merge all outstanding
patches every day sound? This is normally very trivial amounts of time
these days, considering Phabricator tends to catch the most obvious
failures.

BTW: I merged your pull request on the Win32 repository, so we can
update MinGW - I didn't realize that it was open at all, and in fact I
completely forgot I had permissions to merge things on that
repository! Most of the external library management is normally dealt
with by Herbert or individual maintainers.

On Wed, Oct 29, 2014 at 6:36 AM, Gintautas Miliauskas
 wrote:
> By the way, regarding that repository, could someone merge my pull request?
>
> In general, it's a bit frustrating how a lot of the patches in the
> Phabricator queue seem to take a while to get noticed. Don't take it
> personally, I'm just sharing my impressions, but I do feel it's taking away
> some momentum - not good for me & other contributors, and not good for the
> project. I know reviewers are understaffed, maybe consider spreading commit
> rights a bit more widely until the situation improves?
>
> On Wed, Oct 29, 2014 at 11:04 AM, Herbert Valerio Riedel
>  wrote:
>>
>> 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

Re: cabal sdist trouble with GHC from head

[Sven Panne]

2014-10-30 17:20 GMT+01:00 Austin Seipp :
> [...] So this just means that Cabal isn't necessarily *future compatible*
> with future GHCs - they may change the package format, etc. But it is
> backwards compatible with existing ones.

OK, that's good to know. To be sure, I've just tested Cabal head + GHC
7.8.3, and it works. But as I've mentioned already, there seems to be
*no* Cabal version which works with GHC head:
https://travis-ci.org/haskell-opengl/StateVar/builds/39533448 Is this
known to the Cabal people?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Gintautas Miliauskas]

Updated.

Note that I'm on vacation starting Friday (Nov 7) and will be back only on
Nov 24.

On Thu, Oct 30, 2014 at 6:40 PM,  wrote:

>  Hi Gintautas,
>
> Is it possible for you to add the rest of next week to the schedule times?
> I’m unavailable on the given dates.
>
> Kind Regards,
> Tamar
>
> *From:* Gintautas Miliauskas 
> *Sent:* ‎Thursday‎, ‎October‎ ‎30‎, ‎2014 ‎16‎:‎34
> *To:* Simon Peyton Jones 
> *Cc:* kyra , ghc-devs@haskell.org
>
>
>
> On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>>   The people problem is tricky. At work, this would be the right time to
>> do a video chat and at least see the faces of the other people involved.
>> Would folks be interested in a Skype/Hangout sometime? It would be
>> interesting to hear what interests / skills / resources / constraints we
>> have between us.
>>
>>
>>
>> I think that’s a great idea, thanks.  It’s easier to work with people
>> with whom you have formed a personal relationship, and a video conf is a
>> good way to do that.
>>
>
> Let's try that. Shall we try to find a good timeslot? Sign up at
> http://doodle.com/34e598zc7m8sbaqm
>
> --
> Gintautas Miliauskas 
>  
>



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

Re: Automating GHC build for Windows

[Páli Gábor János]

2014-10-30 16:24 GMT+01:00 Gintautas Miliauskas :
> I wonder what's going on with DeleteFile. What is the step that's failing?

Basically it happens at the same point, that is, at the "configure"
phase but at the ghc-prim package.  Note that the previously mentioned
workaround has a "removeFile" action [1], I guess the failure of that
triggers the DeleteFile exception.

> Can you post the log?

"inplace/bin/ghc-cabal.exe" configure libraries/ghc-prim dist-install
"" --with-ghc="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-stage1.exe"
--with-ghc-pkg="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-pkg.exe"
--flag=include-ghc-prim --disable-library-for-ghci
--enable-library-vanilla --enable-library-for-ghci
--enable-library-profiling --disable-shared
--configure-option=CFLAGS=" -U__i686 -march=i686 -fno-stack-protector
 " --configure-option=LDFLAGS="   " --configure-option=CPPFLAGS="   "
--gcc-options=" -U__i686 -march=i686 -fno-stack-protector   "
--with-gcc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
--with-ld="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/ld.exe"
--configure-option=--with-cc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
--with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex"
--with-happy="/usr/local/bin/happy"
Configuring ghc-prim-0.3.1.0...
ghc-cabal.exe: DeleteFile "dist-install\\setup-config": permission
denied (The process cannot access the file because it is being used by
another process.)
libraries/ghc-prim/ghc.mk:4: recipe for target
'libraries/ghc-prim/dist-install/package-data.mk' failed
make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
Makefile:71: recipe for target 'all' failed

> I also wonder why this issue is not arising on other Windows machines...

As the comment in the workaround goes, it has a "Big fat hairy race
condition".  Therefore I am inclined to believe that it may be a
problem for other systems as well, but I am the most unfortunate one
who hits this error with 100% probability :-)

[1] 
https://github.com/ghc/ghc/blob/master/libraries/bin-package-db/GHC/PackageDb.hs#L267
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[lonetiger]

Hi Gintautas,


Is it possible for you to add the rest of next week to the schedule times? I’m 
unavailable on the given dates.


Kind Regards,

Tamar





From: Gintautas Miliauskas
Sent: ‎Thursday‎, ‎October‎ ‎30‎, ‎2014 ‎16‎:‎34
To: Simon Peyton Jones
Cc: kyra, ghc-devs@haskell.org









On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones  
wrote:




The people problem is tricky. At work, this would be the right time to do a 
video chat and at least see the faces of the other people involved. Would folks 
be interested in a Skype/Hangout sometime? It would be interesting to hear what 
interests / skills / resources / constraints we have between us.

 

I think that’s a great idea, thanks.  It’s easier to work with people with whom 
you have formed a personal relationship, and a video conf is a good way to do 
that.



Let's try that. Shall we try to find a good timeslot? Sign up at 
http://doodle.com/34e598zc7m8sbaqm

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

Re: Understanding core2core optimisation pipeline

[Nicolas Frisby]

On Thu, Oct 30, 2014 at 9:55 AM, David Feuer  wrote:

> On Thu, Oct 30, 2014 Jan Stolarek wrote:
>
>>
>> 2. First pass of full laziness is followed by floating in. At that stage
>> we have not yet run the
>> demand analysis and yet the code that does the floating-in checks whether
>> a binder is one-shot
>> (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This
>> suggests that cardinality
>> analysis is done earlier (but when?) and that demand analysis is not the
>> same thing as
>> cardinality analysis.
>>
>
> If you're looking at super-recent code, that could be Joachim Breitner's
> work. He's exposed the one-shot stuff at the Haskell level with the
> experimental magic oneShot function, intended primarily for use in the
> libraries to make foldl-as-foldr and related things be analyzed more
> reliably. The old GHC arity analysis combined with his Call Arity get
> almost everything right, but there are occasional corner cases where things
> go wrong, and when they do the results tend to be extremely bad.
>
>
Joachim's work looks like neat stuff. I've only been scanning those emails,
but I recall mention of interface files. Jan, would your question #2 be
addressed by that information being imported from interface files? With
separate compilation, phase ordering because more nuanced.




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

Re: RFC: Properly stated origin of code contributions

[Carter Schonwald]

yup, agreed


-Carter

On Thu, Oct 30, 2014 at 1:14 PM, Stephen Paul Weber
 wrote:

>>In the absence of a license agreement, the contribution is usually owned by
>>the submitter and not the project (copyright, see Berne convention). This
>>doesn't scale very well. A signed CLA allows the project to demonstrate
>>that the submitter has agreed to transfer ownership of the contribution to
>>the project('s administrators).
> I wouldn't want a copyright-assignment system (since that allows the project 
> to re-license when it wants, for example) but an inbound=outbound agreement 
> (that is, an explicit agreement from contributors to have their 
> contributions released under the license of the project) is not an 
> unreasonable thing to do.
> -- 
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Stephen Paul Weber]

In the absence of a license agreement, the contribution is usually owned by
the submitter and not the project (copyright, see Berne convention). This
doesn't scale very well. A signed CLA allows the project to demonstrate
that the submitter has agreed to transfer ownership of the contribution to
the project('s administrators).


I wouldn't want a copyright-assignment system (since that allows the project 
to re-license when it wants, for example) but an inbound=outbound agreement 
(that is, an explicit agreement from contributors to have their 
contributions released under the license of the project) is not an 
unreasonable thing to do.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


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

Re: Understanding core2core optimisation pipeline

[David Feuer]

On Thu, Oct 30, 2014 Jan Stolarek wrote:

>
> 2. First pass of full laziness is followed by floating in. At that stage
> we have not yet run the
> demand analysis and yet the code that does the floating-in checks whether
> a binder is one-shot
> (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This
> suggests that cardinality
> analysis is done earlier (but when?) and that demand analysis is not the
> same thing as
> cardinality analysis.
>

If you're looking at super-recent code, that could be Joachim Breitner's
work. He's exposed the one-shot stuff at the Haskell level with the
experimental magic oneShot function, intended primarily for use in the
libraries to make foldl-as-foldr and related things be analyzed more
reliably. The old GHC arity analysis combined with his Call Arity get
almost everything right, but there are occasional corner cases where things
go wrong, and when they do the results tend to be extremely bad.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Carter Schonwald]

tl;dr I think we're fine :)

long version; asking people the first time they contribute to confirm that
their work is their own, and they can and do grant bsd license is about all
thats needed.

i'm not sure how language standards relate to this topic, but i'll ask you
about that out of band I guess ;)

On Thu, Oct 30, 2014 at 11:45 AM, Brandon Allbery 
wrote:

> On Thu, Oct 30, 2014 at 11:25 AM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> I'm happy to ask the IP lawyers in my family for some opinions on this
>> but I think what we are doing now is fine.
>
>
> As Joachim already noted, it's a bit late to switch course for GHC; you'd
> have to track down every past contributor. (I've been involved with
> projects that needed to do that; if at all possible, avoid it.)
>
> The reality, as I understand it (note that I Am Not A Lawyer(tm) but have
> experience with projects that have had to face the question), is that
> there's complex interactions between copyright law and contract law (not to
> mention questions of how contract law affects contributions to an open
> project). And both have a certain "valid until proven otherwise" aspect,
> which often makes it wisest to not change what's already working well
> enough --- especially since even asking a lawyer "on the clock" can
> potentially have legal implications on the whole project (but only if
> someone actually challenges in court and brings it up). As a result, the
> FUD's kinda built into the legal structure. :/
>
> (My earlier response is not incompatible with this; the question I was
> answering was why a project might go with a CLA. In reality, whether the
> answer is *relevant* to a project is certainly open to question. One
> difference between the situation with GHC and the situation with Scala or
> Perl 6 is that the latter are also defining a language specification, which
> may have implications if there is a plan to submit it to an official
> standards body at some point. For ghc, that rests on the language
> committee, not the GHC developers.)
>
> If it really bothers you, probably best to ask someone like the EFF.
> Almost certainly do *not* formally ask a lawyer (informal is fine) --- they
> are going to concentrate on the worst case, mainly because even asking for
> a formal evaluation suggests that there is a need to worry about the worst
> case. Otherwise, leave well enough alone.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: URL issue

[Austin Seipp]

(Resending to hit ghc-devs list.)

Yep, good point.

For those at home: this will affect you too, if you're pushing to
'ghc.haskell.org' instead of 'git.haskell.org'. Why?

Because ghc.haskell.org now uses a CDN (Content Delivery Network) to
cache and make the server a bit more responsive. But one of the
limitations of a CDN is they will not proxy your SSH access,
unfortunately. (We implemented this back on Sunday, I believe, so you
may only be seeing it now).

However, git.haskell.org remains off a CDN and will continue to do so,
meaning it will always be safe to push to via SSH.

I'll update the Git pages to reflect this.

On Thu, Oct 30, 2014 at 7:57 AM, Simon Peyton Jones
 wrote:
> Herbert, Austin
>
>
>
> I was in a fairly old repo, but one I have been using daily, and pushing to
> the central repo.  The pushurl was
>
> pushurl = ssh://g...@ghc.haskell.org/ghc.git
>
> That worked two days ago, but silently hangs now.
>
>
>
> But when I finally realised that it should be “git.haskell.org” it works
> fine.
>
>
> So something must have changed.  I’m certain I was pushing to
> ghc.haskell.org until a couple of days ago.  Strange, and may be useful
> knowledge for others.
>
>
>
> Anyway, no problem now. But the “Repositories” pages says nothing about what
> URL to use for pushing – and it really should!  That would be worth fixing.
>
>
> Thanks
>
>
>
> Simon
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: cabal sdist trouble with GHC from head

[Austin Seipp]

On Thu, Oct 23, 2014 at 8:47 AM, Sven Panne  wrote:
> 2014-10-23 15:01 GMT+02:00 Alan & Kim Zimmerman :
>> cabal has changed for HEAD, you need to install 1.21.1.0
>
> Hmmm, so we *force* people to update? o_O Perhaps I've missed an
> announcement, and I really have a hard time deducing this from the
> output on Travis CI. Is 1.21.1.0 backwards-compatible to previous
> GHCs? Or do I have to set up something more or less complicated
> depending on the GHC version (which would be unfortunate)?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

Just to be clear, Cabal will always support every major GHC version
going back several years. I think it even supports GHC 6.12 still and
Duncan tests with it. But, sometimes a GHC change may require you to
use a newer version of Cabal, for things to work.

So this just means that Cabal isn't necessarily *future compatible*
with future GHCs - they may change the package format, etc. But it is
backwards compatible with existing ones.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] wip/T9732: Generate two versions of pattern synonym matcher: * one where the continuation is lifted, * one where the continuation is unlifted. (423e9b2)

[Simon Peyton Jones]

|  $m?P :: forall (r :: ?) a. [T a] -> R(r) -> R(r) -> r
|  
|  where R(r) = Void# -> r  if r :: #
|  , r   otherwise
|  
|  Is there a way to do that? 

No indeed.

|  Now, to cut down on the amount of code generated, I guess we could
|  have
|  
|  $m?P :: forall (r :: ?) a. [T a] -> (Void# -> r) -> (Void# -> r) -> r
|  
|  and always compile pattern synonym match continuations into lambdas
|  over this dummy Void#, but I thought we also wanted to avoid that...

I think that's fine.  These matchers will usually be inlined and all the 
clutter will go away.

|  Note that if P were to have arguments, the same problem would still be
|  present with the fail continuation (but not the success one).

Yes, let's take advantage of that

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

Re: GHC Weekly News - 10/24/2014

[Austin Seipp]

Yes, it is orthogonal to any effort for a NCG for ARMv7 or ARMv8.

Note that ARM is a platform that would particularly benefit from this:
right now, building GHC on ARM is a bit... er, troublesome. There are
a lot of LLVM versions that don't work, or are patched by maintainers
(making it impossible to know what might work or not), or have simply
never been tested depending on the distro. I've had quite my share of
problems trying to get GHC/ARM to build on ARM/Linux, due to all kinds
of incompatibilities or bugs in the code generator for whatever verson
I was using.

I agree that for upstreams (Debian, Fedora, etc) the proposition is a
bit scary perhaps. But I think the significant number of advantages
outweigh the disadvantages quite handily, and as we go forward, I
still think it will be the only truly maintainable solution, at least
in the forseeable future.

I am also of course more than willing to help upstreams adapt to this
(for example, should Debian or Fedora wish to package their own LLVM,
I'd be more than willing to help identify a version that works and we
could give to users).

FWIW, I'm aiming for not requiring any extra patches to LLVM. I'd
prefer using a stable version, and any bugs we find should go
upstream.( GHC requiring extra LLVM patches would be a possibility,
but one of the last things we'd want possibly due to extra
complication.)

On Thu, Oct 30, 2014 at 5:24 AM, Jens Petersen  wrote:
> Thanks for the Weekly News that is really useful info.
>
> On 25 October 2014 09:00, Austin Seipp  wrote:
>>
>> Note: this post is available (with full hyperlinks) at
>> https://ghc.haskell.org/trac/ghc/blog/weekly20141024
>
>
>>
>>  - This past week, a discussion sort of organically started on the
>> `#ghc` IRC channel about the future of the LLVM backend. GHC's backend
>> is buggy, has no control over LLVM versions, and breaks frequently
>> with new versions. This all significantly impacts users, and relegates
>> the backend to a second class citizen. After some discussion, Austin
>> wrote up a proposal for a improved backend, and wrangled several other
>> people to help. The current plan is to try an execute this by GHC
>> 7.12, with the goal of making the LLVM backend Tier 1 for major
>> supported platforms.
>
>
> Is this effort orthogonal to NCG for armv7 and armv8?
>
> I am glad people are thinking about how to address this but
> "we ship and fix a version of LLVM for GHC" sounds a bit scary to me. :)
>
> Jens



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] wip/T9732: Generate two versions of pattern synonym matcher: * one where the continuation is lifted, * one where the continuation is unlifted. (423e9b2)

[Dr. ERDI Gergo]

On Thu, 30 Oct 2014, Simon Peyton Jones wrote:

No no! Let's not do that.  It's grotesque to generate identical code 
twice.  We must find a better way.


So the type of an open-kinded matcher function, for a pattern of type

pattern type P :: [T a]

would need to be something like

$m?P :: forall (r :: ?) a. [T a] -> R(r) -> R(r) -> r

where R(r) = Void# -> r  if r :: #
   , r   otherwise

Is there a way to do that? I couldn't think of anything better than to 
generate two versions:


$mP :: forall r a. [T a] -> r -> r -> r
$m#P :: forall (r :: #) a. [T a] -> (Void# -> r) -> (Void# -> r) -> r

Now, to cut down on the amount of code generated, I guess we could have

$m?P :: forall (r :: ?) a. [T a] -> (Void# -> r) -> (Void# -> r) -> r

and always compile pattern synonym match continuations into lambdas over 
this dummy Void#, but I thought we also wanted to avoid that...


Note that if P were to have arguments, the same problem would still be 
present with the fail continuation (but not the success one).

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

Re: Understanding core2core optimisation pipeline

[Nicolas Frisby]

I implemented -flate-dmd-anal last year

Here's some outdated notes about my initial implementation. I share it in
order to indicate what thoughts were in my mind at the time (eg re
motivation).

https://ghc.haskell.org/trac/ghc/wiki/Frisby2013Q1#LateStrictnessWW

Aha! More up-to-date info here, including links to some of the older,
motivating tickets.

https://ghc.haskell.org/trac/ghc/ticket/7782
https://ghc.haskell.org/trac/ghc/wiki/LateDmd

Also, I now suspect this pass is risky: I think it may enter unused
arguments. I realize I didn't understand that stuff well enough at the
time. This definitely deserves some attention if people are using the flag.

To answer your question directly: I do not recall explicitly considering
single-entry thunks when implementing -flate-dmd-anal.

HTH.


On Thu, Oct 30, 2014 at 7:15 AM, Jan Stolarek 
wrote:

> I'm resurrecting this 3-month old thread as I have some more questions
> about cardinality analysis.
>
> 1. I'm still a bit confused about terminology. Demand analysis, strictness
> analysis, cardinality
> analysis - do these three terms mean exactly the same thing? If no, then
> what are the
> differences?
>
> 2. First pass of full laziness is followed by floating in. At that stage
> we have not yet run the
> demand analysis and yet the code that does the floating-in checks whether
> a binder is one-shot
> (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This
> suggests that cardinality
> analysis is done earlier (but when?) and that demand analysis is not the
> same thing as
> cardinality analysis.
>
> 3. Does demand analyser perform any transformations? Or does it only
> annotate Core with demand
> information that can be used by subsequent passes?
>
> 4. BasicTypes module defines:
>
> data OneShotInfo = NoOneShotInfo -- ^ No information
>  | ProbOneShot   -- ^ The lambda is probably applied at
> most once
>  | OneShotLam-- ^ The lambda is applied at most once.
>
> Do I understand correctly that `NoOneShotInfo` really means no information,
> ie. a binding annotated with this might in fact be one shot? If so, then
> do we
> have means of saying that a binding is certainly not a one-shot binding?
>
> 5. What is the purpose of SetLevels.lvlMFE function?
>
> Janek
>
> > The wiki page just went live:
> >
> >
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline
> >
> > It's not yet perfect but it should be a good start.
> >
> > > Roughtly, a complete run of the simplifier means "run the simplifier
> > > repeatedly until nothing further happens".  The iterations are the
> > > successive iterations of this loop. Currently there's a (rather
> arbitrary)
> > > limit of four such iterations before we give up and declare victory.
> >
> > A limit or a default value for that limit?
> >
> > To Ilya:
> > > If you grep for the "late_dmd_anal" option variable in the
> compiler/simplCore/SimplCore.lhs
> > > module, you'll see that it triggers a phase close to the endo of
> getCoreToDo's tasks, which
> > > contains, in particular, the "CoreDoStrictness" pass. This is the
> "late" phase.
> >
> > The paper said that the late pass is run to detect single-entry thunks
> and the reason why it is
> > run late in the pipeline is that if it were run earlier this information
> could be invalidated
> > by the transformations. But in the source code I see that this late pass
> is followed by the
> > simplifier, which can invalidate the information. Also, the
> documentation for -flate-dmd-anal
> > says: "We found some opportunities for discovering strictness that were
> not visible earlier;
> > and optimisations like -fspec-constr can create functions with unused
> arguments which are
> > eliminated by late demand analysis". This says nothing about
> single-netry thunks. So, is the
> > single-entry thunk optimisation performed by GHC?
> >
> > Janek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] wip/T9732: Generate two versions of pattern synonym matcher: * one where the continuation is lifted, * one where the continuation is unlifted. (423e9b2)

[Simon Peyton Jones]

No no! Let's not do that.  It's grotesque to generate identical code twice.  We 
must find a better way.

Simon

|  -Original Message-
|  From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
|  Of g...@git.haskell.org
|  Sent: 30 October 2014 15:40
|  To: ghc-comm...@haskell.org
|  Subject: [commit: ghc] wip/T9732: Generate two versions of pattern
|  synonym matcher: * one where the continuation is lifted, * one where
|  the continuation is unlifted. (423e9b2)
|  
|  Repository : ssh://g...@git.haskell.org/ghc
|  
|  On branch  : wip/T9732
|  Link   :
|  http://ghc.haskell.org/trac/ghc/changeset/423e9b28930fb9e6dfcd4a20dd60
|  4ec488a2bb1d/ghc
|  
|  >---
|  
|  commit 423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d
|  Author: Dr. ERDI Gergo 
|  Date:   Thu Oct 30 23:07:50 2014 +0800
|  
|  Generate two versions of pattern synonym matcher:
|  * one where the continuation is lifted,
|  * one where the continuation is unlifted.
|  
|  
|  >---
|  
|  423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d
|   compiler/basicTypes/OccName.lhs |  5 +++--
|  compiler/basicTypes/PatSyn.lhs  | 21 -
|   compiler/deSugar/DsUtils.lhs|  2 +-
|   compiler/iface/BuildTyCl.lhs|  7 ---
|   compiler/iface/IfaceSyn.lhs |  8 ++--
|   compiler/iface/MkIface.lhs  |  4 +++-
|   compiler/iface/TcIface.lhs  |  4 +++-
|   compiler/typecheck/TcBinds.lhs  |  3 ++-
|  compiler/typecheck/TcPatSyn.lhs | 28 +---
|   9 files changed, 51 insertions(+), 31 deletions(-)
|  
|  Diff suppressed because of size. To see it, use:
|  
|  git diff-tree --root --patch-with-stat --no-color --find-copies-
|  harder --ignore-space-at-eol --cc
|  423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d
|  ___
|  ghc-commits mailing list
|  ghc-comm...@haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-commits
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Brandon Allbery]

On Thu, Oct 30, 2014 at 11:25 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> I'm happy to ask the IP lawyers in my family for some opinions on this but
> I think what we are doing now is fine.


As Joachim already noted, it's a bit late to switch course for GHC; you'd
have to track down every past contributor. (I've been involved with
projects that needed to do that; if at all possible, avoid it.)

The reality, as I understand it (note that I Am Not A Lawyer(tm) but have
experience with projects that have had to face the question), is that
there's complex interactions between copyright law and contract law (not to
mention questions of how contract law affects contributions to an open
project). And both have a certain "valid until proven otherwise" aspect,
which often makes it wisest to not change what's already working well
enough --- especially since even asking a lawyer "on the clock" can
potentially have legal implications on the whole project (but only if
someone actually challenges in court and brings it up). As a result, the
FUD's kinda built into the legal structure. :/

(My earlier response is not incompatible with this; the question I was
answering was why a project might go with a CLA. In reality, whether the
answer is *relevant* to a project is certainly open to question. One
difference between the situation with GHC and the situation with Scala or
Perl 6 is that the latter are also defining a language specification, which
may have implications if there is a plan to submit it to an official
standards body at some point. For ghc, that rests on the language
committee, not the GHC developers.)

If it really bothers you, probably best to ask someone like the EFF. Almost
certainly do *not* formally ask a lawyer (informal is fine) --- they are
going to concentrate on the worst case, mainly because even asking for a
formal evaluation suggests that there is a need to worry about the worst
case. Otherwise, leave well enough alone.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC on Windows (extended/broad discussion)

[Gintautas Miliauskas]

On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones 
wrote:

>   The people problem is tricky. At work, this would be the right time to
> do a video chat and at least see the faces of the other people involved.
> Would folks be interested in a Skype/Hangout sometime? It would be
> interesting to hear what interests / skills / resources / constraints we
> have between us.
>
>
>
> I think that’s a great idea, thanks.  It’s easier to work with people with
> whom you have formed a personal relationship, and a video conf is a good
> way to do that.
>

Let's try that. Shall we try to find a good timeslot? Sign up at
http://doodle.com/34e598zc7m8sbaqm

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

package hashes

[Simon Peyton Jones]

Edward

On branch wip/new-flatten-skolems-Oct14, I'm getting this test failure 
repeatably on test safePkgO1.  I'm pretty sure I have done nothing to mess with 
package hashes!

Any ideas?

Simon

=> safePkg01(normal) 108 of 120 [0, 0, 0]
cd ./check/pkg01 && $MAKE -s --no-print-directory safePkg01 
VANILLA=--enable-library-vanilla PROF=--disable-library-profiling 
DYN=--enable-sharedsafePkg01.run.stdout 2>safePkg01.run.stderr
Actual stdout output differs from expected:
--- ./check/pkg01/safePkg01.stdout   2014-10-29 15:09:16.0 +
+++ ./check/pkg01/safePkg01.run.stdout   2014-10-30 15:25:17.799094762 +
@@ -29,17 +29,17 @@
require own pkg trusted: True
 M_SafePkg6
-package dependencies: array-0.5.0.1@array_
+package dependencies: array-0.5.0.1 base-4.8.0.0*
trusted: trustworthy
require own pkg trusted: False
 M_SafePkg7
-package dependencies: array-0.5.0.1@array_
+package dependencies: array-0.5.0.1 base-4.8.0.0*
trusted: safe
require own pkg trusted: False
 M_SafePkg8
-package dependencies: array-0.5.0.1@array_
+package dependencies: array-0.5.0.1 base-4.8.0.0
trusted: trustworthy
require own pkg trusted: False

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

Re: RFC: Properly stated origin of code contributions

[Carter Schonwald]

Indeed. A cla is overkill for ghc. More over, a good CLA  merely documents
that I'm granting license under BSD compatible terms, ownership transfer is
inappropriate and abusive.

At MOST, "this work is my own and  I grant license for its use In ghc using
the BSD license" is plenty.  And even that might be overkill.

I'm happy to ask the IP lawyers in my family for some opinions on this but
I think what we are doing now is fine.
On Oct 30, 2014 9:51 AM, "Joachim Breitner" 
wrote:

> Hi,
>
>
> Am Donnerstag, den 30.10.2014, 09:04 -0400 schrieb Brandon Allbery:
> > On Thu, Oct 30, 2014 at 5:00 AM, Jan Stolarek 
> > wrote:
> > Projects like Scala and Clojure require filling in a
> > "Contributor [License] Agreement". I have not
> > bothered to investigate the exact purpose.
> >
> > In the absence of a license agreement, the contribution is usually
> > owned by the submitter and not the project (copyright, see Berne
> > convention). This doesn't scale very well. A signed CLA allows the
> > project to demonstrate that the submitter has agreed to transfer
> > ownership of the contribution to the project('s administrators).
>
> Given that the Linux kernel doesn’t require (paper-signed) CLAs, I do
> think it scales very well, and does not seem to scare off commercial
> users.
>
>
> > In the absence of a license agreement, the contribution is usually
> > owned by the submitter and not the project (copyright, see Berne
> > convention). This doesn't scale very well. A signed CLA allows the
> > project to demonstrate that the submitter has agreed to transfer
> > ownership of the contribution to the project('s administrators).
>
> As long we can properly assume that contributors license the code to us
> under the terms of the GHC license (which we seem to do), we got what we
> need. No need to hold the copyright in a single place. It’s too late for
> that anyways.
>
>
> Please avoid introducing unnecessary bureaucracy into the contributing
> process, especially not due to legal fear, cased from FUD and
> smattering.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Automating GHC build for Windows

[Gintautas Miliauskas]

Thanks for pushing this forward.

I wonder what's going on with DeleteFile. What is the step that's failing?
Can you post the log?

I also wonder why this issue is not arising on other Windows machines...

On Thu, Oct 30, 2014 at 12:18 AM, Páli Gábor János 
wrote:

> 2014-10-28 21:49 GMT+01:00 Gintautas Miliauskas :
> > Can you try running the offending command with -v to see which step
> > breaks?
>
> I have tried it, even together with building the GHC sources with a
> recent toolchain, but I did not get much forward.
>
> > I tried running it locally under strace but did not see any file renames
> > either.
>
> Although, I think I managed to find the place where some renaming
> happens.  That is `writeFileAtomic` in Cabal's
> Distribution.Simple.Utils module [1].  The bin-package-db library has
> a patched version of this function [2] that has a workaround for
> Windows.  After incorporating this change in Cabal, I was able to pass
> the previously problematic point in the build.  Unfortunately, this
> was not enough for the complete build, as a similar error (with
> DeleteFile that time) was raised.
>
> [1]
> https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Utils.hs#L1032
> [2]
> https://github.com/ghc/ghc/blob/master/libraries/bin-package-db/GHC/PackageDb.hs#L252
>



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

Re: Understanding core2core optimisation pipeline

[Jan Stolarek]

I'm resurrecting this 3-month old thread as I have some more questions about 
cardinality analysis.

1. I'm still a bit confused about terminology. Demand analysis, strictness 
analysis, cardinality 
analysis - do these three terms mean exactly the same thing? If no, then what 
are the 
differences?

2. First pass of full laziness is followed by floating in. At that stage we 
have not yet run the 
demand analysis and yet the code that does the floating-in checks whether a 
binder is one-shot 
(FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This suggests 
that cardinality 
analysis is done earlier (but when?) and that demand analysis is not the same 
thing as 
cardinality analysis.

3. Does demand analyser perform any transformations? Or does it only annotate 
Core with demand 
information that can be used by subsequent passes?

4. BasicTypes module defines:

data OneShotInfo = NoOneShotInfo -- ^ No information
 | ProbOneShot   -- ^ The lambda is probably applied at most 
once
 | OneShotLam-- ^ The lambda is applied at most once.

Do I understand correctly that `NoOneShotInfo` really means no information,
ie. a binding annotated with this might in fact be one shot? If so, then do we
have means of saying that a binding is certainly not a one-shot binding?

5. What is the purpose of SetLevels.lvlMFE function?

Janek

> The wiki page just went live:
>
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline
>
> It's not yet perfect but it should be a good start.
>
> > Roughtly, a complete run of the simplifier means "run the simplifier
> > repeatedly until nothing further happens".  The iterations are the
> > successive iterations of this loop. Currently there's a (rather arbitrary)
> > limit of four such iterations before we give up and declare victory.
>
> A limit or a default value for that limit?
>
> To Ilya:
> > If you grep for the "late_dmd_anal" option variable in the 
> > compiler/simplCore/SimplCore.lhs
> > module, you'll see that it triggers a phase close to the endo of 
> > getCoreToDo's tasks, which
> > contains, in particular, the "CoreDoStrictness" pass. This is the "late" 
> > phase.
>
> The paper said that the late pass is run to detect single-entry thunks and 
> the reason why it is
> run late in the pipeline is that if it were run earlier this information 
> could be invalidated
> by the transformations. But in the source code I see that this late pass is 
> followed by the
> simplifier, which can invalidate the information. Also, the documentation for 
> -flate-dmd-anal
> says: "We found some opportunities for discovering strictness that were not 
> visible earlier;
> and optimisations like -fspec-constr can create functions with unused 
> arguments which are
> eliminated by late demand analysis". This says nothing about single-netry 
> thunks. So, is the
> single-entry thunk optimisation performed by GHC?
>
> Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Joachim Breitner]

Hi,


Am Donnerstag, den 30.10.2014, 09:04 -0400 schrieb Brandon Allbery:
> On Thu, Oct 30, 2014 at 5:00 AM, Jan Stolarek 
> wrote:
> Projects like Scala and Clojure require filling in a
> "Contributor [License] Agreement". I have not
> bothered to investigate the exact purpose. 
> 
> In the absence of a license agreement, the contribution is usually
> owned by the submitter and not the project (copyright, see Berne
> convention). This doesn't scale very well. A signed CLA allows the
> project to demonstrate that the submitter has agreed to transfer
> ownership of the contribution to the project('s administrators).

Given that the Linux kernel doesn’t require (paper-signed) CLAs, I do
think it scales very well, and does not seem to scare off commercial
users.


> In the absence of a license agreement, the contribution is usually
> owned by the submitter and not the project (copyright, see Berne
> convention). This doesn't scale very well. A signed CLA allows the
> project to demonstrate that the submitter has agreed to transfer
> ownership of the contribution to the project('s administrators).

As long we can properly assume that contributors license the code to us
under the terms of the GHC license (which we seem to do), we got what we
need. No need to hold the copyright in a single place. It’s too late for
that anyways.


Please avoid introducing unnecessary bureaucracy into the contributing
process, especially not due to legal fear, cased from FUD and
smattering.

Greetings,
Joachim



-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Brandon Allbery]

On Thu, Oct 30, 2014 at 5:00 AM, Jan Stolarek 
wrote:

> Projects like Scala and Clojure require filling in a "Contributor
> [License] Agreement". I have not
> bothered to investigate the exact purpose.
>

In the absence of a license agreement, the contribution is usually owned by
the submitter and not the project (copyright, see Berne convention). This
doesn't scale very well. A signed CLA allows the project to demonstrate
that the submitter has agreed to transfer ownership of the contribution to
the project('s administrators).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

URL issue

[Simon Peyton Jones]

Herbert, Austin

I was in a fairly old repo, but one I have been using daily, and pushing to the 
central repo.  The pushurl was
pushurl = ssh://g...@ghc.haskell.org/ghc.git
That worked two days ago, but silently hangs now.

But when I finally realised that it should be "git.haskell.org" it works fine.

So something must have changed.  I'm certain I was pushing to ghc.haskell.org 
until a couple of days ago.  Strange, and may be useful knowledge for others.

Anyway, no problem now. But the "Repositories" pages says nothing about what 
URL to use for pushing - and it really should!  That would be worth fixing.

Thanks

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

Tests with compilation errors

[Gintautas Miliauskas]

Going through some validate.sh results, I found compilation errors due to
missing libraries, like this one:

=> stm052(normal) 4088 of 4108 [0, 21, 0]
cd ../../libraries/stm/tests &&
'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopt
s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm
 >stm052.comp.stderr 2>&1
Compile failed (status 256) errors were:

stm052.hs:10:8:
Could not find module ‘System.Random’
Use -v to see a list of the files searched for.

I was surprised to see that these are not listed in the test summary at the
end of the test run, but only counted towards the "X had missing libraries"
row. That setup makes it really easy to miss them, and I can't think of a
good reason to sweep such tests under the rug; a broken test is a failing
test.

How about at least listing such failed tests in the list of failed tests of
the end?

At least in this case the error does not seem to be due to some missing
external dependencies (which probably would not be a great idea anyway...).
The test does pass if I remove the "-no-user-package-db" argument. What was
the intention here? Does packaging work somehow differently on Linux? (I'm
currently testing on Windows.)

On a related note, how about separating test failures from failing
performance tests ("stat too good" / "stat not good enough")? The latter
are important, but they seem to be much more prone to fail without good
reason. Perhaps do some color coding of the test runner output? That would
also help.

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

Re: GHC Weekly News - 10/24/2014

[Jens Petersen]

Thanks for the Weekly News that is really useful info.

On 25 October 2014 09:00, Austin Seipp  wrote:

> Note: this post is available (with full hyperlinks) at
> https://ghc.haskell.org/trac/ghc/blog/weekly20141024
>


>  - This past week, a discussion sort of organically started on the
> `#ghc` IRC channel about the future of the LLVM backend. GHC's backend
> is buggy, has no control over LLVM versions, and breaks frequently
> with new versions. This all significantly impacts users, and relegates
> the backend to a second class citizen. After some discussion, Austin
> wrote up a proposal for a improved backend
> , and wrangled
> several other
> people to help. The current plan is to try an execute this by GHC
> 7.12, with the goal of making the LLVM backend Tier 1 for major
> supported platforms.
>

Is this effort orthogonal to NCG for armv7 and armv8?

I am glad people are thinking about how to address this but
"we ship and fix a version of LLVM for GHC" sounds a bit scary to me. :)

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

Re: cabal sdist trouble with GHC from head

[Sven Panne]

2014-10-29 23:55 GMT+01:00 Herbert Valerio Riedel :
> Fyi, there's a `cabal-install-head` package now[1] (may take a few
> minutes till its properly published in the PPA though); please test it
> and lemme know if it works as expected...
>
>  [1]: 
> https://launchpad.net/~hvr/+archive/ubuntu/ghc/+sourcepub/4539223/+listing-archive-extra

Thanks for uploading this. Nevertheless, GHC from head and cabal from
head still don't like each other:

  https://travis-ci.org/haskell-opengl/StateVar/jobs/39470537#L103

I get "cabal: Prelude.chr: bad argument: 3031027"... o_O
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Jan Stolarek]

> Comments?
+1

However:

> 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.
Projects like Scala and Clojure require filling in a "Contributor [License] 
Agreement". I have not 
bothered to investigate the exact purpose. My guess is that it is supposed to 
prevent situations 
like "un-authorized" commiting code into the project. (Meaning: employee of 
company M commits 
code into the project but then the company says that person was not allowed to 
do that, beacuse 
the code is patented or sth and requests that the code is withdrawn or sues the 
project.) Somehow 
I feel that introducing such contributor licenses into GHC would scare away 
some contributors. 
But then again doing that could prevent some potential problems.

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

RE: Properly stated origin of code contributions

[Simon Peyton Jones]

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

I agree with that. We could list the policy on 
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions, or a page linked from 
there.

One possibility would be to add a "Contributors" section to the GHC Team page 
https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, and ask anyone submitting a 
patch to add an entry describing themselves (including their real name) to that 
page.  By "contributor" I means someone who is submitting a patch but is not 
yet a committer.  We could have separate sub-pages for committers and 
contributors.  

That would give a way to celebrate contributors, as well as a way to identify 
them.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Herbert Valerio Riedel
|  Sent: 30 October 2014 08:13
|  To: ghc-devs
|  Subject: RFC: Properly stated origin of code contributions
|  
|  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/322810e32cb18d7749e255937437
|  ff2ef99dca3f
|  
|  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/Do
|  cumentation/SubmittingPatches
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

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

Problems compiling with llvm-3.5.0-2 on ARM

[Jarl Gunnar Flaten]

Hello,

(cf. reddit thread

)

I am trying to compile a simple "hello world" program (test.hs). When
compiling I am notified:

> [1 of 1] Compiling Main ( test.hs, test.o )
> You are using a new version of LLVM that hasn't been tested yet!
> We will try though...
> Linking test ...

But it seems to finish compiling fine, without further errors.
However, running the program (./test):

> test: schedule: re-entered unsafely.
>Perhaps a 'foreign import unsafe' should be 'safe'?

Isn't working. I'm not familiar enough with neither LLVM nor Haskell
to troubleshoot from either of these; I don't even know if the
messages are even related.

Any ideas for solutions? Any commands or tests I can perform to give
you more information?


Thanks,

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