Re: api annotations test failures
It looks like it is related somehow to having PartialTypeSignatures enabled, having no other warnings/errors, and not going beyond parseSource. Then it sometimes outputs the typed hole warnings, and sometimes not. Alan On Fri, May 15, 2015 at 10:37 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: Interesting. The t10358.hs test is a direct clone of a number of others with just the filename to be processed changed. I have a queued TODO to harmonise this into a single module. In other words the build process for this test is identical to say t10357.hs, which runs just before t10358. Alan On Fri, May 15, 2015 at 10:13 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Joachim Breitner wrote: Hi, I observe this on travis: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: collect2: ld terminated with signal 9 [Killed] make[3]: *** [t10358] Error 1 I've seen this just recently on these tests. Looking at /var/log/messages showed the `ld` process had been killed by the OOM killer. My instance of this was on armhf/linux with only 2Gig of RAM and no swap. I have to recompile the kernel to get swap :-(. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GADT confusion
On 18/05/15 10:57, Alan Kim Zimmerman wrote: Hi all I am working on D836 and have the following test case data MaybeDefault v where SetTo4 :: forall v a. (( Eq v, Show v ) = v - MaybeDefault v - a - MaybeDefault [a]) GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` The question is, due to the parens, is the return type not the whole RHS? i.e. Similar to how in the signature map :: (a - b) - [a] - [b] the first paramater is a single function. I am sure I am just confused here. This is the wrong analogy, since (a - b) in map's type is in the negative position. The correct analogy would be the return type of map :: (a - b) - ([a] - [b]) You could argue it both ways. (But only one of them leads to the above declaration being correct, since the function type is not an instance of MaybeDefault.) Roman signature.asc Description: OpenPGP digital signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GADT confusion
Hi all I am working on D836 and have the following test case data MaybeDefault v where SetTo4 :: forall v a. (( Eq v, Show v ) = v - MaybeDefault v - a - MaybeDefault [a]) GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` The question is, due to the parens, is the return type not the whole RHS? i.e. Similar to how in the signature map :: (a - b) - [a] - [b] the first paramater is a single function. I am sure I am just confused here. Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string GPL can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of derived work, different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of LGPL (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: Native -XCPP Proposal
I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3! On Monday, May 18, 2015, Lars Kuhtz hask...@kuhtz.eu wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string GPL can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of derived work, different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of LGPL (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Non-deterministic package IDs are really bad in 7.10
On 05/14/2015 05:43 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. is NixOS sensitive to changes in the build directory. Debian is, and since 7.8 the build path creeps into the interface files and affects the hash: https://bugs.debian.org/785282 But you probably are not, otherwise you’d have complained when 7.8 was out, and not now :-) Greetings, Joachim Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ‘calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
