RE: GHC contribution guidelines and infrastructure talk on 6th September at HIW?
| On Saturday 6th September is the Haskell Implementers Workshop. There | has been plenty of discussion over the last 12 months about making | contributions to GHC less formidable. Is this story going to be told at | HIW? A talk about revised contribution guidelines and helpful tool | support might engage those sat on, or peering over, the fence. I think that's a great idea. Maybe Simon M, or Joachim, or Austin, or Herbert? Of some coalition thereof Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Rob | Stewart | Sent: 17 July 2014 19:19 | To: ghc-devs@haskell.org | Subject: GHC contribution guidelines and infrastructure talk on 6th | September at HIW? | | Hi, | | On Saturday 6th September is the Haskell Implementers Workshop. There | has been plenty of discussion over the last 12 months about making | contributions to GHC less formidable. Is this story going to be told at | HIW? A talk about revised contribution guidelines and helpful tool | support might engage those sat on, or peering over, the fence. | | This might include: | | * Phabricator code review demonstration. | * Continuous integration infrastructure. | * Trac demonstration, e.g. how to contribute to design discussions. | * Wiki navigation, and important new pages born in recent months. | * GHC coding guidelines, e.g. using notes and haddock documentation. | * Git policies, e.g. use of submodules. | * What GHC needs.. Windows testers? | * Old contribution guidelines that no longer apply. | | Is HIW on 6th September a good place to give a GHC contributions and | infrastructure talk? | | -- | Rob | ___ | 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: Building GHC under Wine?
I might be misremembering, but I believe someone (Ross Paterson?) used to do this a while ago. I can't think of any good reasons it *shouldn't* work. Cheers, Simon On 15/07/2014 23:55, Joachim Breitner wrote: Hi, I feel sorry for Simon always repeatedly stuck with an unbuildable tree, and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it likely to catch the kind of problems that Simon is getting? If so, maybe it runs fast enough to be also tested by travis on every commit? (This mail is to find out if people have tried it before. If not, I’ll give it a quick shot.) Greetings, Joachim ¹ we surely can use it: http://www.haskell.org/haskellwiki/GHC_under_Wine ___ 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: Building GHC under Wine?
Hi, Am Freitag, den 18.07.2014, 08:38 +0100 schrieb Simon Marlow: I might be misremembering, but I believe someone (Ross Paterson?) used to do this a while ago. I can't think of any good reasons it *shouldn't* work. Then, next question: Is it likely to find windows building failures, are are the failures usually of the kind that would not occur in a not-quite-a-real-windows environment? 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: GHC contribution guidelines and infrastructure talk on 6th September at HIW?
Hi, Am Freitag, den 18.07.2014, 07:25 + schrieb Simon Peyton Jones: | On Saturday 6th September is the Haskell Implementers Workshop. There | has been plenty of discussion over the last 12 months about making | contributions to GHC less formidable. Is this story going to be told at | HIW? A talk about revised contribution guidelines and helpful tool | support might engage those sat on, or peering over, the fence. I think that's a great idea. Maybe Simon M, or Joachim, or Austin, or Herbert? Of some coalition thereof I agree, and I’d be available for it, or for joining a coalition. 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: a little phrustrated
Excerpts from Jan Stolarek's message of 2014-07-17 08:35:19 +0100: 1. Complaining about any untracked or uncommited changes in the source tree. This is mostly annoying. How can I tell arcanist to ignore such changes? Rant: I really don't like tools that try to be smarter than me and prohibit from doing what I want them to do. OK, I finally gave in and took a look at the Phabricator source code. Short answer: It's hard-coded, you can't disable the check Medium answer: It's pretty easy to disable, just uncomment the two 'throw new ArcanistUsageException' lines in src/workflow/ArcanistBaseWorkflow.php which complain about staging/committing before proceeding Long answer: Arcanist lint will still run on your working tree, so you are going to get spurious lint results. Oof! Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Windows breakage -- again
Thank you all for pursuing this. I gather that you know what is going on, so
no further info needed from me. Yell if it is otherwise.
Meanwhile, is the fix imminent, or should we revert Johan’s patch?
Simon
From: Niklas Larsson [mailto:metanik...@gmail.com]
Sent: 16 July 2014 19:58
To: Johan Tibell; Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows breakage -- again
I get the same failure when I try to build HEAD. Turns out the error occurs on
the 32-bit Windows build, and my successful build was a 64-bit build. My 64-bit
build still succeeds.
Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit.
Niklas
2014-07-16 14:48 GMT+02:00 Niklas Larsson
metanik...@gmail.commailto:metanik...@gmail.com:
I have built ghc on windows after that was added with no issue.
I can take a look this evening and see how HEAD works for me.
The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth,
there is an issue on trac to upgrade it.
-- Niklas
Från: Johan Tibellmailto:johan.tib...@gmail.com
Skickat: 2014-07-16 09:57
Till: Simon Peyton Jonesmailto:simo...@microsoft.com
Kopia: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
Ämne: Re: Windows breakage -- again
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you
wish. I will try to re-add the primop again after I figure out what's wrong.
On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell
johan.tib...@gmail.commailto:johan.tib...@gmail.com wrote:
I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a
gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1]
says:
Not all operations are supported by all target processors. If a particular
operation cannot be implemented on the target processor, a warning will be
generated and a call an external function will be generated. The external
function will carry the same name as the builtin, with an additional suffix
`_n' where n is the size of the data type.
I'm a bit surprised by this error for two reasons:
* A call to that symbol should only be generated if the CPU doesn't support
the atomic instructions. What CPU model does Windows report that you have?
* gcc should define such a symbol. For me the following test program compiles:
#include stdint.h
uint8_t test(uint8_t* ptr, uint8_t val) {
return __sync_fetch_and_add_1(ptr, val);
}
int main(void) {
uint8_t n;
return test(n, 1);
}
Does that compile for you? Which version of GCC do we end up using on Windows?
The reported symbol (___sync_fetch_and_add_1) has three leading underscores,
that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and
see if it's indeed GCC that generates a reference to that symbol?
1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Aargh! The Windows build has broken – again. I can’t build GHC on my laptop
any more.
A clean ‘sh validate’ finishes as below. What on earth is
`___sync_fetch_and_add_1'?
Can anyone help? Thanks!
Simon
inplace/bin/ghc-stage2.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-Werror -Wall -H64m -O0-package-name vector-0.10.9.1 -hide-all-packages -i
-ilibraries/vector/. -ilibraries/vector/dist-install/build
-ilibraries/vector/dist-install/build/autogen
-Ilibraries/vector/dist-install/build
-Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include
-Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include
-optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package
base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package
primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint
-fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir
libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build
-stubdir libraries/vector/dist-install/build -c
libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o
libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o
Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package
`ghc-prim'
ghc-stage2.exe:
C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o:
unknown symbol `___sync_fetch_and_add_1'
libraries/vector/ghc.mk:5http://ghc.mk:5: recipe for target
'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed
make[1]: ***
[libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error
1
I
___
ghc-devs mailing list
ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
SV: Windows breakage -- again
I posted a working and tested patch last night. Please feel free to commit it,
I haven't the rights to do it.
Niklas
- Ursprungligt meddelande -
Från: Simon Peyton Jones simo...@microsoft.com
Skickat: 2014-07-18 15:55
Till: Niklas Larsson metanik...@gmail.com; Johan Tibell
johan.tib...@gmail.com
Kopia: ghc-devs@haskell.org ghc-devs@haskell.org
Ämne: RE: Windows breakage -- again
Thank you all for pursuing this. I gather that you know what is going on, so
no further info needed from me. Yell if it is otherwise.
Meanwhile, is the fix imminent, or should we revert Johan’s patch?
Simon
From: Niklas Larsson [mailto:metanik...@gmail.com]
Sent: 16 July 2014 19:58
To: Johan Tibell; Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows breakage -- again
I get the same failure when I try to build HEAD. Turns out the error occurs on
the 32-bit Windows build, and my successful build was a 64-bit build. My 64-bit
build still succeeds.
Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit.
Niklas
2014-07-16 14:48 GMT+02:00 Niklas Larsson metanik...@gmail.com:
I have built ghc on windows after that was added with no issue.
I can take a look this evening and see how HEAD works for me.
The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth,
there is an issue on trac to upgrade it.
-- Niklas
Från: Johan Tibell
Skickat: 2014-07-16 09:57
Till: Simon Peyton Jones
Kopia: ghc-devs@haskell.org
Ämne: Re: Windows breakage -- again
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you
wish. I will try to re-add the primop again after I figure out what's wrong.
On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell johan.tib...@gmail.com wrote:
I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a
gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1]
says:
Not all operations are supported by all target processors. If a particular
operation cannot be implemented on the target processor, a warning will be
generated and a call an external function will be generated. The external
function will carry the same name as the builtin, with an additional suffix
`_n' where n is the size of the data type.
I'm a bit surprised by this error for two reasons:
* A call to that symbol should only be generated if the CPU doesn't support
the atomic instructions. What CPU model does Windows report that you have?
* gcc should define such a symbol. For me the following test program compiles:
#include stdint.h
uint8_t test(uint8_t* ptr, uint8_t val) {
return __sync_fetch_and_add_1(ptr, val);
}
int main(void) {
uint8_t n;
return test(n, 1);
}
Does that compile for you? Which version of GCC do we end up using on Windows?
The reported symbol (___sync_fetch_and_add_1) has three leading underscores,
that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and
see if it's indeed GCC that generates a reference to that symbol?
1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Aargh! The Windows build has broken – again. I can’t build GHC on my laptop
any more.
[Hela det ursprungliga meddelandet tas inte med.]___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Update Cabal submodule to HEAD (1.21)
Hi Edward, your commit makes the builders fail: [28 of 79] Compiling Distribution.Simple.Utils ( libraries/Cabal/Cabal/Distribution/Simple/Utils.hs, bootstrapping/Distribution/Simple/Utils.o ) libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:382:46: `Process.delegate_ctlc' is not a (visible) constructor field name libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:408:46: `Process.delegate_ctlc' is not a (visible) constructor field name make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 https://s3.amazonaws.com/archive.travis-ci.org/jobs/30289010/log.txt Please fix! Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Thanks Niklas, this is now committed.
On Fri, Jul 18, 2014 at 9:21 AM, Niklas Larsson metanik...@gmail.com wrote:
I posted a working and tested patch last night. Please feel free to commit
it, I haven't the rights to do it.
Niklas
Från: Simon Peyton Jones
Skickat: 2014-07-18 15:55
Till: Niklas Larsson; Johan Tibell
Kopia: ghc-devs@haskell.org
Ämne: RE: Windows breakage -- again
Thank you all for pursuing this. I gather that you know what is going on,
so no further info needed from me. Yell if it is otherwise.
Meanwhile, is the fix imminent, or should we revert Johan’s patch?
Simon
From: Niklas Larsson [mailto:metanik...@gmail.com]
Sent: 16 July 2014 19:58
To: Johan Tibell; Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows breakage -- again
I get the same failure when I try to build HEAD. Turns out the error occurs
on the 32-bit Windows build, and my successful build was a 64-bit build. My
64-bit build still succeeds.
Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit.
Niklas
2014-07-16 14:48 GMT+02:00 Niklas Larsson metanik...@gmail.com:
I have built ghc on windows after that was added with no issue.
I can take a look this evening and see how HEAD works for me.
The standard gcc in the tarballs is 4.6.3, which is getting long in the
tooth, there is an issue on trac to upgrade it.
-- Niklas
Från: Johan Tibell
Skickat: 2014-07-16 09:57
Till: Simon Peyton Jones
Kopia: ghc-devs@haskell.org
Ämne: Re: Windows breakage -- again
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you
wish. I will try to re-add the primop again after I figure out what's wrong.
On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a
gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1]
says:
Not all operations are supported by all target processors. If a
particular operation cannot be implemented on the target processor, a
warning will be generated and a call an external function will be generated.
The external function will carry the same name as the builtin, with an
additional suffix `_n' where n is the size of the data type.
I'm a bit surprised by this error for two reasons:
* A call to that symbol should only be generated if the CPU doesn't support
the atomic instructions. What CPU model does Windows report that you have?
* gcc should define such a symbol. For me the following test program
compiles:
#include stdint.h
uint8_t test(uint8_t* ptr, uint8_t val) {
return __sync_fetch_and_add_1(ptr, val);
}
int main(void) {
uint8_t n;
return test(n, 1);
}
Does that compile for you? Which version of GCC do we end up using on
Windows?
The reported symbol (___sync_fetch_and_add_1) has three leading underscores,
that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and
see if it's indeed GCC that generates a reference to that symbol?
1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Aargh! The Windows build has broken – again. I can’t build GHC on my
laptop any more.
[Hela det ursprungliga meddelandet tas inte med.]
___
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: Update Cabal submodule to HEAD (1.21)
The reason for this is that the builders do not have a sufficiently recent version of process, which Cabal has upgraded to depend on. Probably 'cabal update cabal install process' should bring it up to date and make it working. Unfortunately, the build system bypasses Cabal for the bootstrap build of Cabal, so the version dependency range is not checked. I suppose if you /really/ wanted to we could add a macro to disable ctl-c support and pass it on the zeroboot. BTW, I noticed the builders are still bootstrapping from 7.4. Since 7.8 was stabilized recently, we're going to be retiring support for bootstrapping from 7.4 soon. Upgrade! Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Thread status constants
Hi, I found these: https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f65692867825/includes/rts/Constants.h#L194 They go only 0-14, so there's some long chains of branches and stuff in hot paths that could be cleaned up into single -masked branches by changing these into a set of flags. And then I saw these: https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 Where does 16 and 17 come from -- I couldn't find them in the header files anywhere? Kyle ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
