Re: [ANNOUNCE] 7.10.3 release candidate 2

The cert warning is merely because it's using the aws cert and that one isn't a wild card. I assume we can generally assume the aws cert isn't broken :) On Monday, November 9, 2015, Carter Schonwald wrote: > Why were you trying to do Haskell platform things ? > This

Re: [ANNOUNCE] 7.10.3 release candidate 2

I understand this isn't a Haskell Platform thing. I just uninstalled the Haskell Platform before installing the binary as I wanted to make sure I didn't have a mixture of both on my machine Before doing the last make install I had done: ./configure --prefix=/usr/local On Mon, Nov 9, 2015 at

Re: [ANNOUNCE] 7.10.3 release candidate 2

install into /opt works fine However the INSTALL file says `make show-install-setup' prints the details of where the different pieces of the bundle are heading when -- possibly helpful but this doesn't work: make show-install-setup make: *** No rule to make target `show-install-setup'. Stop.

Re: [ANNOUNCE] 7.10.3 release candidate 2

George Colpitts writes: > I get > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > make[1]: *** Waiting for unfinished jobs It looks like the build failed somewhere before this point. Could you provide a more complete log? Cheers, - Ben

Re: [ANNOUNCE] 7.10.3 release candidate 2

Download works with http When I try to download your build using https I get This Connection is Untrusted You have asked Firefox to connect securely to www.wellposed.com.s3.amazonaws.com, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will

Re: Questions on the RTS C API regarding threads and tasks

> Il giorno 09 nov 2015, alle ore 00:17, Edward Z. Yang ha > scritto: > > Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800: >> We don't have measurements, but we ruled out this possibility for >> performance reasons. Our idea is to make a thin Haskell wrapper

Re: [ANNOUNCE] 7.10.3 release candidate 2

Thanks Carter. I will check out your build Any ideas as to why mine failed? I am on OS 10.11.1 with Xcode 7.1 compiling using clang with make -j5 After the error shown below I typed make again and got: ... checking whether clang is gcc... yes checking compiler clang -m32 -O2 -pedantic -fPIC

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang

redid with just make rather than make -j5. I get ... chmod +x libraries/integer-gmp2/gmp/ln # Their cmd invocation only works on msys. On cygwin it starts # a cmd interactive shell. The replacement works in both environments. mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh

Re: [ANNOUNCE] 7.10.3 release candidate 2

Why were you trying to do Haskell platform things ? This isn't a Haskell platform build. Just configure --prefix=blsh and then make install On Monday, November 9, 2015, George Colpitts wrote: > install into /opt works fine > However the INSTALL file says > > `make

Re: too many lines too long

For me, a huge reason why the line length errors are annoying is because there will often be some existing line which is 80+, and I just need to change one word in it. Well, now that's a line length error. Now, I *could* refactor the line so that it's less than 80. But this (1) fluffs up the

Re: too many lines too long

I agree that being forceful about the 80-col limit would solve my problem. But I really dislike the idea. There will always be long-running patches. Volunteers can't be relied on to have time available to continue their work right away. And so I think this decision would increase barriers to

Re: too many lines too long

Something like this might be possible. It'd just require implementing a new arcanist linter, I think, and enabling it in .arclint In general I really sympathize with this. The problem 90% of people hit is that they touch a line that was *already* over 80 columns, so 'arc lint' warns them and gets

Re: too many lines too long

I also dislike the idea of automatically rejecting such code. I agree with Austin's argument that the contribution barrier is already too high and Richard's arguments, but in addition to those, I think it wouldn't be fair because some patches of people with push access won't be subject to the

Re: Questions on the RTS C API regarding threads and tasks

On Mon, Nov 9, 2015 at 6:02 AM, Nicola Gigante wrote: > Nothing actually, I was confused about what “unsafe” call means. In fact, as you've probably realized, the reason these calls are labeled unsafe is precisely because they don't yield the capability. An unsafe FFI

Re: [commit: ghc] master: Remove PatSynBuilderId (2208011)

I don't think this would work in the case where there are no fields initialised? Concretely, I am thinking of a case like this: https://phabricator.haskell.org/P72 If I understand right, rbinds would be an empty list so there would be no selector Id to get the relevant ConLike from. On Mon, Nov

Re: too many lines too long

Hi, I’d like to state a differing opinion: I don’t think highly of such a hard rule. A line should have the length that is most natural to it. Patches should be easy to review. Developers time is spent better than re-shuffling code to be short and still nicely formatted and aligned. I might be

too many lines too long

Hi devs, We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab I look through has a bunch of "line too long" lint errors. No one seems to do much about these. And Phab's very very loud indication of a lint error makes reviewing the code harder. I like the

RE: too many lines too long

In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window. Clearly there's a judgement call here. But I'd prefer 120 cols say. Simon -Original Message- From: ghc-devs

Re: too many lines too long

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

Matthew, | Remove PatSynBuilderId Thanks for doing this. But it can be simpler still! Suggestion: - remove the new 'labels' field from RecordCon; you only use it in dsExpr - In dsExpr, use the hsRecFieldSel of the first item in 'rbinds' to get a selector-Id - Inside that selector-Id

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

| I don't think this would work in the case where there are no fields | initialised? Oh yes, silly me. I was thinking that then we wouldn’t need to look at 'labels' at all, but that's not true. Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc ConLike). This makes it