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 wiggle room to miss this target. > The number 80 is with us for historical reasons, but I know I'm not the only > one who still routinely uses 80-column buffers. +1 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/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 wiggle room to miss this target. The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers. Richard On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote: > 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 [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard > Eisenberg > Sent: 09 November 2015 21:03 > To: ghc-devs Devs > Subject: 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 ideal of 80-character lines. I aim for this ideal in my patches, > falling short sometimes, of course. But I think the current setting of > requiring everyone to "explain" away their overlong lines during `arc diff` > and then trying hard to ignore the lint errors during code review is wrong. > And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong > lines before and after the patch. If there are more after, have the last > thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be > less annoying. :) > > What do others think? > > Thanks, > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 in the minority here, and of course I’ll be adhering to any hard requirements agreed on by broad consensus, but note that the support for an 80-line regime is not unanimous. Oh, and obviously dropping this requirement would also solve Richard’s problems with the linter :-) 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: 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 ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 automatic lint checks. 100-col lines will make it to the code base even if only by mistake. It'll be annoying to new contributors and won't solve the problem. Personally I'm trying to be very careful, and in my patches I usually do a lint pass at the end to fix all long lines. But I'm OK if some patches with 100-col lines occasionally make it to the master. 2015-11-09 16:21 GMT-05:00 Richard Eisenberg : > 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 > contributing and increase merge conflicts for a cause that, frankly, isn't > terribly important. (To repeat: I *do* want 80-col lines. I just want an > amazing compiler more.) > > Richard > > On Nov 9, 2015, at 4:15 PM, Austin Seipp wrote: > >> 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 annoyed, but they don't want to fix or >> split up a bunch of stuff to avoid it. It's an issue of having to do >> 'boring work' which nobody likes, and seems very tedious, regardless >> of the mechanism of how they do the change. >> >> Really, I'm more inclined to begin a policy of rejecting reviews that >> do not pass the linter. Exceptions can be made, but in general we need >> to start *enforcing it* with the red button I think. And it would >> require us to be more diligent about merging patches quickly to reduce >> the scope of merge conflicts (because fixing an 80col violation >> normally, almost always, adds more LOC). >> >> However, there are people who in general think the contribution >> barrier is already too high, and I fear that enforcing this with a >> hard rule may make people 'give up' because it seems like a pointless >> thing to mandate to block their changes. I'm not sure how people feel >> about that, but it is worth keeping in mind the developer economics. >> >> I hope suggesting the possibility of being more forceful against 80col >> violations doesn't derail this too much. :) >> >> On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: >>> 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 ideal of 80-character lines. I aim for this ideal in my patches, >>> falling short sometimes, of course. But I think the current setting of >>> requiring everyone to "explain" away their overlong lines during `arc diff` >>> and then trying hard to ignore the lint errors during code review is wrong. >>> And it makes us all inured to more serious lint errors. >>> >>> How about this: after `arc diff` is run, it will count the number of >>> overlong lines before and after the patch. If there are more after, have >>> the last thing `arc diff` outputs be a stern telling-off of the dev, along >>> the lines of >>> Before your patch, 15 of the edited lines were over 80 characters. Now, a whopping 28 of them are. Can't you do better? Please? >>> >>> Would this be ignored more or followed more? Who knows. But it would sure >>> be less annoying. :) >>> >>> What do others think? >>> >>> Thanks, >>> Richard >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/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://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: 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 contributing and increase merge conflicts for a cause that, frankly, isn't terribly important. (To repeat: I *do* want 80-col lines. I just want an amazing compiler more.) Richard On Nov 9, 2015, at 4:15 PM, Austin Seipp wrote: > 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 annoyed, but they don't want to fix or > split up a bunch of stuff to avoid it. It's an issue of having to do > 'boring work' which nobody likes, and seems very tedious, regardless > of the mechanism of how they do the change. > > Really, I'm more inclined to begin a policy of rejecting reviews that > do not pass the linter. Exceptions can be made, but in general we need > to start *enforcing it* with the red button I think. And it would > require us to be more diligent about merging patches quickly to reduce > the scope of merge conflicts (because fixing an 80col violation > normally, almost always, adds more LOC). > > However, there are people who in general think the contribution > barrier is already too high, and I fear that enforcing this with a > hard rule may make people 'give up' because it seems like a pointless > thing to mandate to block their changes. I'm not sure how people feel > about that, but it is worth keeping in mind the developer economics. > > I hope suggesting the possibility of being more forceful against 80col > violations doesn't derail this too much. :) > > On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: >> 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 ideal of 80-character lines. I aim for this ideal in my patches, >> falling short sometimes, of course. But I think the current setting of >> requiring everyone to "explain" away their overlong lines during `arc diff` >> and then trying hard to ignore the lint errors during code review is wrong. >> And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of >> overlong lines before and after the patch. If there are more after, have the >> last thing `arc diff` outputs be a stern telling-off of the dev, along the >> lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be >> less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 annoyed, but they don't want to fix or split up a bunch of stuff to avoid it. It's an issue of having to do 'boring work' which nobody likes, and seems very tedious, regardless of the mechanism of how they do the change. Really, I'm more inclined to begin a policy of rejecting reviews that do not pass the linter. Exceptions can be made, but in general we need to start *enforcing it* with the red button I think. And it would require us to be more diligent about merging patches quickly to reduce the scope of merge conflicts (because fixing an 80col violation normally, almost always, adds more LOC). However, there are people who in general think the contribution barrier is already too high, and I fear that enforcing this with a hard rule may make people 'give up' because it seems like a pointless thing to mandate to block their changes. I'm not sure how people feel about that, but it is worth keeping in mind the developer economics. I hope suggesting the possibility of being more forceful against 80col violations doesn't derail this too much. :) On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg wrote: > 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 ideal of 80-character lines. I aim for this ideal in my patches, > falling short sometimes, of course. But I think the current setting of > requiring everyone to "explain" away their overlong lines during `arc diff` > and then trying hard to ignore the lint errors during code review is wrong. > And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong > lines before and after the patch. If there are more after, have the last > thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > >> Before your patch, 15 of the edited lines were over 80 characters. >> Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be > less annoying. :) > > What do others think? > > Thanks, > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 diffs with non-semantic noise, and (2) makes merge conflicts a lot more likely. I think the counts thing could help for this case. But now suppose there's an existing line which is just barely under 80, and you need to do a mechanical substitution which pushes it over. Yes, I /could/ reindent it, but it's a huge timesink for no very good reason. Usually the best way to eliminate a long line is to refactor the entire region of code, e.g. splitting out helper functions or whatnot. Edward Excerpts from Richard Eisenberg's message of 2015-11-09 13:02:48 -0800: > 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 ideal of 80-character lines. I aim for this ideal in my patches, > falling short sometimes, of course. But I think the current setting of > requiring everyone to "explain" away their overlong lines during `arc diff` > and then trying hard to ignore the lint errors during code review is wrong. > And it makes us all inured to more serious lint errors. > > How about this: after `arc diff` is run, it will count the number of overlong > lines before and after the patch. If there are more after, have the last > thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > > > Before your patch, 15 of the edited lines were over 80 characters. > > Now, a whopping 28 of them are. Can't you do better? Please? > > Would this be ignored more or followed more? Who knows. But it would sure be > less annoying. :) > > What do others think? > > Thanks, > Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 ideal of 80-character lines. I aim for this ideal in my patches, falling short sometimes, of course. But I think the current setting of requiring everyone to "explain" away their overlong lines during `arc diff` and then trying hard to ignore the lint errors during code review is wrong. And it makes us all inured to more serious lint errors. How about this: after `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of > Before your patch, 15 of the edited lines were over 80 characters. > Now, a whopping 28 of them are. Can't you do better? Please? Would this be ignored more or followed more? Who knows. But it would sure be less annoying. :) What do others think? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 call that blocks will block the Haskell capability -- this not only starves that CPU for actual work, it will eventually block the whole program once the RTS tries to do a round of stop-the-world GC. As Edward pointed out, you're better off just relying on the concurrency primitives Haskell already gives you unless you find they're too slow. Another thing you can try is the unagi-chan library on Hackage ( https://hackage.haskell.org/package/unagi-chan), which offers versions of blocking and non-blocking producer-consumer queues that claim to be much faster than the ones that come with the standard library. Greg -- Gregory Collins ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; export SHELLOPTS; \ PATH=`pwd`:$PATH; \ export PATH; \ cd gmpbuild && \ CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ --enable-shared=no \ --host=x86_64-apple-darwin --build=x86_64-apple-darwin /bin/sh: SHELLOPTS: readonly variable checking build system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking host system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/sh: SHELLOPTS: readonly variable checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking whether clang is gcc... yes checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 char spilling checking ABI=32 checking whether clang is gcc... yes *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *configure: error: could not find a working compiler, see config.log for details* *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* *make: *** [all] Error 2* On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari wrote: > 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 > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 9:51 AM, Carter Schonwald wrote:
> 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 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.
>>
>> I installed in /opt as I didn't want to overwrite my current ghc. It
>> would be nice if there was an uninstall target for make.
>>
>> I removed /opt/bin/* and /opt/lib/* as there were only ghc files there.
>> Then I did an uninstall-hs (uninstall of Haskell Platform)
>> Then install into the default (/usr/local) I get:
>>
>> /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1"
>> install: /usr/local/share/man/man1/ghc.1: No such file or directory
>> make[1]: *** [install_man] Error 71
>> make: *** [install] Error 2
>>
>> I then did
>>
>> ls -l /usr/local/share/man/man1/ghc.1
>> lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35
>> /usr/local/share/man/man1/ghc.1 ->
>> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1
>>
>> then
>>
>> rm /usr/local/share/man/man1/ghc.1
>>
>> and then "make install" worked
>>
>> However cabal install hlint didn't work because it couldn't install
>> text-1.2.1.3:
>>
>> cabal install text
>> ...
>>
>> Data/Text.hs:203:8:
>> Could not find module ‘Control.DeepSeq’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:208:8:
>> Could not find module ‘Data.Char’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:209:8:
>> Could not find module ‘Data.Data’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:211:8:
>> Could not find module ‘Control.Monad’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:212:8:
>> Could not find module ‘Control.Monad.ST’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> ...
>>
>>
>> ghc-pkg list
>> /usr/local/lib/ghc-7.10.2.20151105/package.conf.d:
>> Cabal-1.22.4.0
>> array-0.5.1.0
>> base-4.8.2.0
>> bin-package-db-0.0.0.0
>> binary-0.7.5.0
>> rts-1.0
>> bytestring-0.10.6.0
>> containers-0.5.6.2
>> deepseq-1.4.1.1
>> directory-1.2.2.0
>> filepath-1.4.0.0
>> (ghc-7.10.2.20151105)
>> ghc-prim-0.4.0.0
>> haskeline-0.7.2.1
>> hoopl-3.10.0.2
>> hpc-0.6.0.2
>> integer-gmp-1.0.0.0
>> pretty-1.1.2.0
>> process-1.2.3.0
>> template-haskell-2.10.0.0
>> terminfo-0.4.0.1
>> time-1.5.0.1
>> transformers-0.4.2.0
>> unix-2.7.1.0
>> xhtml-3000.2.1
>>
>> ghc-pkg check
>>
>> Similar problems with cabal install vector
>>
>>
>>
>> On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> nope, my error was a bad copy and paste :)
>>>
>>> heres a link to my build (uses the GCC style rts build, which should be
>>> more performant than the default clang one last i checked, also has html
>>> docs and should work OS X >= 10.7)
>>>
>>>
>>> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>>>
>>> (http:// also works)
>>>
>>>
>>> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>>> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>>>
>>>
>>> for those who want to check the check the sha sum
>>>
>>>
>>>
>>> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts <
>>> george.colpi...@gmail.com> wrote:
>>>
I get
make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
make[1]: *** Waiting for unfinished jobs
checking whether byte ordering is bigendian... no
checking assembler .cfi pseudo-op support... yes
checking for _ prefix in compiled symbols... yes
checking whether .eh_frame section should be read-only... expr: syntax
error
no
checking for __attribute__((visibility("hidd
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 >> around a tiny bit of highly optimized C code. What's the performance >> of locking on MVars? > > I still don't know what it is you're trying to do. If you have a tiny > bit of optimized C code that runs quickly, then you should just make > an unsafe FFI call to it (as for as Haskell's runtime is concerned, > it's just a "fat instruction”). > I’m sorry, I know my description was too vague. The reason is that we have a blind review pending on a paper and I had instructions of not to talk about what we are doing. Anyway, your reply is nevertheless very clear. >> While we are at it: are primops callable directly from C? I suppose >> calling conventions are different. > > Anything is "callable" from C, but yes, you have to do the right > calling convention. Primops are not easily callable from C. > Ok, that’s what I meant. >> A question comes to mind: you mentioned "safe" calls. >> Are unsafe calls different regarding the detaching of the capability? > > An unsafe call does not detach the capability. > Ok, thanks for the confirmation of this fact. >> Also: would a patch to make this possible be accepted? >> In particular: >> - add a way to make a "ultraunsafe" foreign call that do not loose the >> ownership of the calling thread. > > I don't see what the difference between this and an unsafe foreign call > is. > Nothing actually, I was confused about what “unsafe” call means. >> - add a BlockedOnExplicitSleep flag for tso->why_blocked >> (And in turn this means managing a different blocking queue, right?) >> - export something to reliably put in sleep and resume threads >> in this way. >> >> Is this feasible? Would it be a good idea? > > I still don't see why you can't just block the thread on an MVar > (removing it from the main run queues), and then when you want to > resume it write to the MVar. It'll have an added bonus that you'll > automatically handle masking/async exceptions correctly. > > If you find the MVar implementation is too slow, then maybe you > can think about making an optimized implementation which doesn't > use any synchronization / is inline in the TSO so no allocation > is necessary. But in my opinion this is putting the cart before > the horse. > Yes, that seems simple and fast enough. You’re right that we should measure before making assumptions about hypothetical poor performance. Thank you for your help > Edward Greetings, Nicola ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 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 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.
>>
>> I installed in /opt as I didn't want to overwrite my current ghc. It
>> would be nice if there was an uninstall target for make.
>>
>> I removed /opt/bin/* and /opt/lib/* as there were only ghc files there.
>> Then I did an uninstall-hs (uninstall of Haskell Platform)
>> Then install into the default (/usr/local) I get:
>>
>> /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1"
>> install: /usr/local/share/man/man1/ghc.1: No such file or directory
>> make[1]: *** [install_man] Error 71
>> make: *** [install] Error 2
>>
>> I then did
>>
>> ls -l /usr/local/share/man/man1/ghc.1
>> lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35
>> /usr/local/share/man/man1/ghc.1 ->
>> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1
>>
>> then
>>
>> rm /usr/local/share/man/man1/ghc.1
>>
>> and then "make install" worked
>>
>> However cabal install hlint didn't work because it couldn't install
>> text-1.2.1.3:
>>
>> cabal install text
>> ...
>>
>> Data/Text.hs:203:8:
>> Could not find module ‘Control.DeepSeq’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:208:8:
>> Could not find module ‘Data.Char’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:209:8:
>> Could not find module ‘Data.Data’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:211:8:
>> Could not find module ‘Control.Monad’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> Use -v to see a list of the files searched for.
>>
>> Data/Text.hs:212:8:
>> Could not find module ‘Control.Monad.ST’
>> Perhaps you haven't installed the profiling libraries for package
>> ‘base-4.8.2.0’?
>> ...
>>
>>
>> ghc-pkg list
>> /usr/local/lib/ghc-7.10.2.20151105/package.conf.d:
>> Cabal-1.22.4.0
>> array-0.5.1.0
>> base-4.8.2.0
>> bin-package-db-0.0.0.0
>> binary-0.7.5.0
>> rts-1.0
>> bytestring-0.10.6.0
>> containers-0.5.6.2
>> deepseq-1.4.1.1
>> directory-1.2.2.0
>> filepath-1.4.0.0
>> (ghc-7.10.2.20151105)
>> ghc-prim-0.4.0.0
>> haskeline-0.7.2.1
>> hoopl-3.10.0.2
>> hpc-0.6.0.2
>> integer-gmp-1.0.0.0
>> pretty-1.1.2.0
>> process-1.2.3.0
>> template-haskell-2.10.0.0
>> terminfo-0.4.0.1
>> time-1.5.0.1
>> transformers-0.4.2.0
>> unix-2.7.1.0
>> xhtml-3000.2.1
>>
>> ghc-pkg check
>>
>> Similar problems with cabal install vector
>>
>>
>>
>> On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> nope, my error was a bad copy and paste :)
>>>
>>> heres a link to my build (uses the GCC style rts build, which should be
>>> more performant than the default clang one last i checked, also has html
>>> docs and should work OS X >= 10.7)
>>>
>>>
>>> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>>>
>>> (http:// also works)
>>>
>>>
>>> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>>> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>>>
>>>
>>> for those who want to check the check the sha sum
>>>
>>>
>>>
>>> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts <
>>> george.colpi...@gmail.com> wrote:
>>>
I get
make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
make[1]: *** Waiting for unfinished jobs
checking whether byte ordering is bigendian... no
checking assembler .cfi pseudo-op support... yes
checking for _ prefix in compiled symbols... yes
checking whether .eh_frame section should be read-only... expr: syntax
error
no
checking for __attribute__((visibility("hidden")))... no
checking that generated files are newer than configure... done
configure: creating ./config.status
>>>
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 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.
>
> I installed in /opt as I didn't want to overwrite my current ghc. It would
> be nice if there was an uninstall target for make.
>
> I removed /opt/bin/* and /opt/lib/* as there were only ghc files there.
> Then I did an uninstall-hs (uninstall of Haskell Platform)
> Then install into the default (/usr/local) I get:
>
> /usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1"
> install: /usr/local/share/man/man1/ghc.1: No such file or directory
> make[1]: *** [install_man] Error 71
> make: *** [install] Error 2
>
> I then did
>
> ls -l /usr/local/share/man/man1/ghc.1
> lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35
> /usr/local/share/man/man1/ghc.1 ->
> /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1
>
> then
>
> rm /usr/local/share/man/man1/ghc.1
>
> and then "make install" worked
>
> However cabal install hlint didn't work because it couldn't install
> text-1.2.1.3:
>
> cabal install text
> ...
>
> Data/Text.hs:203:8:
> Could not find module ‘Control.DeepSeq’
> Perhaps you haven't installed the profiling libraries for package
> ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’?
> Use -v to see a list of the files searched for.
>
> Data/Text.hs:208:8:
> Could not find module ‘Data.Char’
> Perhaps you haven't installed the profiling libraries for package
> ‘base-4.8.2.0’?
> Use -v to see a list of the files searched for.
>
> Data/Text.hs:209:8:
> Could not find module ‘Data.Data’
> Perhaps you haven't installed the profiling libraries for package
> ‘base-4.8.2.0’?
> Use -v to see a list of the files searched for.
>
> Data/Text.hs:211:8:
> Could not find module ‘Control.Monad’
> Perhaps you haven't installed the profiling libraries for package
> ‘base-4.8.2.0’?
> Use -v to see a list of the files searched for.
>
> Data/Text.hs:212:8:
> Could not find module ‘Control.Monad.ST’
> Perhaps you haven't installed the profiling libraries for package
> ‘base-4.8.2.0’?
> ...
>
>
> ghc-pkg list
> /usr/local/lib/ghc-7.10.2.20151105/package.conf.d:
> Cabal-1.22.4.0
> array-0.5.1.0
> base-4.8.2.0
> bin-package-db-0.0.0.0
> binary-0.7.5.0
> rts-1.0
> bytestring-0.10.6.0
> containers-0.5.6.2
> deepseq-1.4.1.1
> directory-1.2.2.0
> filepath-1.4.0.0
> (ghc-7.10.2.20151105)
> ghc-prim-0.4.0.0
> haskeline-0.7.2.1
> hoopl-3.10.0.2
> hpc-0.6.0.2
> integer-gmp-1.0.0.0
> pretty-1.1.2.0
> process-1.2.3.0
> template-haskell-2.10.0.0
> terminfo-0.4.0.1
> time-1.5.0.1
> transformers-0.4.2.0
> unix-2.7.1.0
> xhtml-3000.2.1
>
> ghc-pkg check
>
> Similar problems with cabal install vector
>
>
>
> On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
> carter.schonw...@gmail.com
> > wrote:
>
>> nope, my error was a bad copy and paste :)
>>
>> heres a link to my build (uses the GCC style rts build, which should be
>> more performant than the default clang one last i checked, also has html
>> docs and should work OS X >= 10.7)
>>
>>
>> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>>
>> (http:// also works)
>>
>>
>> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>>
>>
>> for those who want to check the check the sha sum
>>
>>
>>
>> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts <
>> george.colpi...@gmail.com
>> > wrote:
>>
>>> I get
>>>
>>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
>>> make[1]: *** Waiting for unfinished jobs
>>> checking whether byte ordering is bigendian... no
>>> checking assembler .cfi pseudo-op support... yes
>>> checking for _ prefix in compiled symbols... yes
>>> checking whether .eh_frame section should be read-only... expr: syntax
>>> error
>>> no
>>> checking for __attribute__((visibility("hidden")))... no
>>> checking that generated files are newer than configure... done
>>> configure: creating ./config.status
>>> config.status: creating include/Makefile
>>> config.status: creating include/ffi.h
>>> config.status: creating Makefile
>>> config.status: creating testsuite/Makefile
>>> config.status: creating man/Makefile
>>> config.status: creating libffi.pc
>>> config.status: creating fficonfig.h
>>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
>
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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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.
I installed in /opt as I didn't want to overwrite my current ghc. It would
be nice if there was an uninstall target for make.
I removed /opt/bin/* and /opt/lib/* as there were only ghc files there.
Then I did an uninstall-hs (uninstall of Haskell Platform)
Then install into the default (/usr/local) I get:
/usr/bin/install -c -m 644 docs/man/ghc.1 "/usr/local/share/man/man1"
install: /usr/local/share/man/man1/ghc.1: No such file or directory
make[1]: *** [install_man] Error 71
make: *** [install] Error 2
I then did
ls -l /usr/local/share/man/man1/ghc.1
lrwxr-xr-x 1 gcolpitts admin 81 Oct 11 17:35
/usr/local/share/man/man1/ghc.1 ->
/Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/share/man/man1/ghc.1
then
rm /usr/local/share/man/man1/ghc.1
and then "make install" worked
However cabal install hlint didn't work because it couldn't install
text-1.2.1.3:
cabal install text
...
Data/Text.hs:203:8:
Could not find module ‘Control.DeepSeq’
Perhaps you haven't installed the profiling libraries for package
‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’?
Use -v to see a list of the files searched for.
Data/Text.hs:208:8:
Could not find module ‘Data.Char’
Perhaps you haven't installed the profiling libraries for package
‘base-4.8.2.0’?
Use -v to see a list of the files searched for.
Data/Text.hs:209:8:
Could not find module ‘Data.Data’
Perhaps you haven't installed the profiling libraries for package
‘base-4.8.2.0’?
Use -v to see a list of the files searched for.
Data/Text.hs:211:8:
Could not find module ‘Control.Monad’
Perhaps you haven't installed the profiling libraries for package
‘base-4.8.2.0’?
Use -v to see a list of the files searched for.
Data/Text.hs:212:8:
Could not find module ‘Control.Monad.ST’
Perhaps you haven't installed the profiling libraries for package
‘base-4.8.2.0’?
...
ghc-pkg list
/usr/local/lib/ghc-7.10.2.20151105/package.conf.d:
Cabal-1.22.4.0
array-0.5.1.0
base-4.8.2.0
bin-package-db-0.0.0.0
binary-0.7.5.0
rts-1.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.1.1
directory-1.2.2.0
filepath-1.4.0.0
(ghc-7.10.2.20151105)
ghc-prim-0.4.0.0
haskeline-0.7.2.1
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
pretty-1.1.2.0
process-1.2.3.0
template-haskell-2.10.0.0
terminfo-0.4.0.1
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
ghc-pkg check
Similar problems with cabal install vector
On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> nope, my error was a bad copy and paste :)
>
> heres a link to my build (uses the GCC style rts build, which should be
> more performant than the default clang one last i checked, also has html
> docs and should work OS X >= 10.7)
>
>
> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>
> (http:// also works)
>
>
> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>
>
> for those who want to check the check the sha sum
>
>
>
> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote:
>
>> I get
>>
>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
>> make[1]: *** Waiting for unfinished jobs
>> checking whether byte ordering is bigendian... no
>> checking assembler .cfi pseudo-op support... yes
>> checking for _ prefix in compiled symbols... yes
>> checking whether .eh_frame section should be read-only... expr: syntax
>> error
>> no
>> checking for __attribute__((visibility("hidden")))... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> config.status: creating include/Makefile
>> config.status: creating include/ffi.h
>> config.status: creating Makefile
>> config.status: creating testsuite/Makefile
>> config.status: creating man/Makefile
>> config.status: creating libffi.pc
>> config.status: creating fficonfig.h
>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
>> config.status: executing buildir commands
>> config.status: create top_srcdir/Makefile guessed from local Makefile
>> config.status: build in x86_64-apple-darwin (HOST=)
>> config.status: executing depfiles commands
>> config.status: executing libtool commands
>> config.status: executing include commands
>> config.status: executing src commands
>> # wc on OS X has spaces in its output, which libffi's Makefile
>> # doesn't expect, so we tweak it to sed them out
>
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 present trusted
identification to prove that you are going to the right place. However,
this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean
that someone is trying to impersonate the site, and you shouldn't continue.
www.wellposed.com.s3.amazonaws.com uses an invalid security certificate.
The certificate is only valid for the following names:
*.s3.amazonaws.com, s3.amazonaws.com
(Error code: ssl_error_bad_cert_domain)
If you understand what's going on, you can tell Firefox to start trusting
this site's identification. Even if you trust the site, this error could
mean that someone is tampering with your connection.
Don't add an exception unless you know there's a good reason why this site
doesn't use trusted identification.
On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> nope, my error was a bad copy and paste :)
>
> heres a link to my build (uses the GCC style rts build, which should be
> more performant than the default clang one last i checked, also has html
> docs and should work OS X >= 10.7)
>
>
> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>
> (http:// also works)
>
>
> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>
>
> for those who want to check the check the sha sum
>
>
>
> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote:
>
>> I get
>>
>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
>> make[1]: *** Waiting for unfinished jobs
>> checking whether byte ordering is bigendian... no
>> checking assembler .cfi pseudo-op support... yes
>> checking for _ prefix in compiled symbols... yes
>> checking whether .eh_frame section should be read-only... expr: syntax
>> error
>> no
>> checking for __attribute__((visibility("hidden")))... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> config.status: creating include/Makefile
>> config.status: creating include/ffi.h
>> config.status: creating Makefile
>> config.status: creating testsuite/Makefile
>> config.status: creating man/Makefile
>> config.status: creating libffi.pc
>> config.status: creating fficonfig.h
>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
>> config.status: executing buildir commands
>> config.status: create top_srcdir/Makefile guessed from local Makefile
>> config.status: build in x86_64-apple-darwin (HOST=)
>> config.status: executing depfiles commands
>> config.status: executing libtool commands
>> config.status: executing include commands
>> config.status: executing src commands
>> # wc on OS X has spaces in its output, which libffi's Makefile
>> # doesn't expect, so we tweak it to sed them out
>> mv libffi/build/Makefile libffi/build/Makefile.orig
>> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig >
>> libffi/build/Makefile
>> "touch" libffi/stamp.ffi.static-shared.configure
>> make: *** [all] Error 2
>>
>> Is that the same error you are getting?
>>
>>
>> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> I'm having trouble setting the make file flags to make the Mac build use
>>> the intree gmp. I'm going to dig into this a bit more this evening.
>>>
>>>
>>> On Sunday, November 8, 2015, Ben Gamari wrote:
>>>
Ben Gamari writes:
> Ben Gamari writes:
>
>> Hello everyone,
>>
>> We are pleased to announce the second release candidate for GHC
7.10.3:
>>
>> https://downloads.haskell.org/~ghc/7.10.3-rc2/
>>
> It has been brought to my attention that the configure script in this
> source tarballs is out of date. Because of this `configure` will
> still fail on OS X. Reports suggest that there may be other issues
> unrelated to the configure issue on OS X as well.
>
Further testing suggests that perhaps the only issue is the out-of-date
`configure` script. Mac OS X users with `autotools` installed should be
able to run `./boot` in the source tree to bring `configure` up-to-date,
at which point this release candidate should be buildable.
I'll cut an -rc3 with a fixed `configure` script today.
Cheers,
- Ben
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
___
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 -fomit-frame-pointer ...
no, gnupro alpha ev6 char spilling
checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no,
gnupro alpha ev6 char spilling
configure: error: could not find a working compiler, see config.log for
details
make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
make: *** [all] Error 2
On Mon, Nov 9, 2015 at 12:07 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> nope, my error was a bad copy and paste :)
>
> heres a link to my build (uses the GCC style rts build, which should be
> more performant than the default clang one last i checked, also has html
> docs and should work OS X >= 10.7)
>
>
> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
>
> (http:// also works)
>
>
> shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
> 003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce
>
>
> for those who want to check the check the sha sum
>
>
>
> On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts > wrote:
>
>> I get
>>
>> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
>> make[1]: *** Waiting for unfinished jobs
>> checking whether byte ordering is bigendian... no
>> checking assembler .cfi pseudo-op support... yes
>> checking for _ prefix in compiled symbols... yes
>> checking whether .eh_frame section should be read-only... expr: syntax
>> error
>> no
>> checking for __attribute__((visibility("hidden")))... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> config.status: creating include/Makefile
>> config.status: creating include/ffi.h
>> config.status: creating Makefile
>> config.status: creating testsuite/Makefile
>> config.status: creating man/Makefile
>> config.status: creating libffi.pc
>> config.status: creating fficonfig.h
>> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
>> config.status: executing buildir commands
>> config.status: create top_srcdir/Makefile guessed from local Makefile
>> config.status: build in x86_64-apple-darwin (HOST=)
>> config.status: executing depfiles commands
>> config.status: executing libtool commands
>> config.status: executing include commands
>> config.status: executing src commands
>> # wc on OS X has spaces in its output, which libffi's Makefile
>> # doesn't expect, so we tweak it to sed them out
>> mv libffi/build/Makefile libffi/build/Makefile.orig
>> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig >
>> libffi/build/Makefile
>> "touch" libffi/stamp.ffi.static-shared.configure
>> make: *** [all] Error 2
>>
>> Is that the same error you are getting?
>>
>>
>> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> I'm having trouble setting the make file flags to make the Mac build use
>>> the intree gmp. I'm going to dig into this a bit more this evening.
>>>
>>>
>>> On Sunday, November 8, 2015, Ben Gamari wrote:
>>>
Ben Gamari writes:
> Ben Gamari writes:
>
>> Hello everyone,
>>
>> We are pleased to announce the second release candidate for GHC
7.10.3:
>>
>> https://downloads.haskell.org/~ghc/7.10.3-rc2/
>>
> It has been brought to my attention that the configure script in this
> source tarballs is out of date. Because of this `configure` will
> still fail on OS X. Reports suggest that there may be other issues
> unrelated to the configure issue on OS X as well.
>
Further testing suggests that perhaps the only issue is the out-of-date
`configure` script. Mac OS X users with `autotools` installed should be
able to run `./boot` in the source tree to bring `configure` up-to-date,
at which point this release candidate should be buildable.
I'll cut an -rc3 with a fixed `configure` script today.
Cheers,
- Ben
>>> ___
>>> 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: [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 like ConPatOut in HsPat. Then the (Located id) field is redundant (we can get it from the ConLike), but that’s only true after typechecking, so maybe simpler to keep both. It amounts to moving the call to conLikeFieldLabels from tcExpr (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think it'd be better. Simon | | 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 9, 2015 at 10:20 AM, Simon Peyton Jones | wrote: | > 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 you'll find RecSelId IdInfo; you can use that to | > get the labels. | > | > Would that work? | > | > Simon | > | > | -Original Message- | > | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On | > | Behalf Of g...@git.haskell.org | > | Sent: 07 November 2015 23:50 | > | To: ghc-comm...@haskell.org | > | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) | > | | > | Repository : ssh://g...@git.haskell.org/ghc | > | | > | On branch : master | > | Link : | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | > | | > | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab | > | 3b4%2fgh | > | | > | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3e | > | be4c08d2 | > | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKc | > | BoN17ALE | > | MES4qFLtEuWiJakOotW0IUM%3d | > | | > | >--- | > | | > | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | Author: Matthew Pickering | > | Date: Sat Nov 7 23:46:03 2015 + | > | | > | Remove PatSynBuilderId | > | | > | Summary: | > | It was only used to pass field labels between the typechecker and | > | desugarer. Instead we add an extra field the RecordCon to carry | this | > | information. | > | | > | Reviewers: austin, goldfire, bgamari | > | | > | Reviewed By: bgamari | > | | > | Subscribers: thomie | > | | > | Differential Revision: https://phabricator.haskell.org/D1443 | > | | > | GHC Trac Issues: #11057 | > | | > | | > | >--- | > | | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | compiler/basicTypes/Id.hs | 11 +-- | > | compiler/basicTypes/IdInfo.hs | 3 --- | > | compiler/deSugar/Coverage.hs | 5 +++-- | > | compiler/deSugar/DsExpr.hs | 4 +--- | > | compiler/deSugar/DsMeta.hs | 2 +- | > | compiler/hsSyn/Convert.hs | 4 +++- | > | compiler/hsSyn/HsExpr.hs | 4 +++- | > | compiler/hsSyn/PlaceHolder.hs | 2 ++ | > | compiler/parser/RdrHsSyn.hs| 4 ++-- | > | compiler/rename/RnExpr.hs | 6 +++--- | > | compiler/typecheck/TcExpr.hs | 5 +++-- | > | compiler/typecheck/TcHsSyn.hs | 4 ++-- | > | compiler/typecheck/TcPatSyn.hs | | > | 14 ++ | > | 13 files changed, 30 insertions(+), 38 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 | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | > | ___ | > | ghc-commits mailing list | > | ghc-comm...@haskell.org | > | | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail | > | .haskell | > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | > | | > | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb406 | > | 8a4d3ebe | > | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFF | > | BiglS%2b | > | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 9, 2015 at 10:20 AM, Simon Peyton Jones wrote: > 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 you'll find RecSelId IdInfo; you can use that to > get the labels. > > Would that work? > > Simon > > | -Original Message- > | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of > | g...@git.haskell.org > | Sent: 07 November 2015 23:50 > | To: ghc-comm...@haskell.org > | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) > | > | Repository : ssh://g...@git.haskell.org/ghc > | > | On branch : master > | Link : > | > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. > | > org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab3b4%2fgh > | > c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe4c08d2 > | > e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKcBoN17ALE > | MES4qFLtEuWiJakOotW0IUM%3d > | > | >--- > | > | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | Author: Matthew Pickering > | Date: Sat Nov 7 23:46:03 2015 + > | > | Remove PatSynBuilderId > | > | Summary: > | It was only used to pass field labels between the typechecker and > | desugarer. Instead we add an extra field the RecordCon to carry this > | information. > | > | Reviewers: austin, goldfire, bgamari > | > | Reviewed By: bgamari > | > | Subscribers: thomie > | > | Differential Revision: https://phabricator.haskell.org/D1443 > | > | GHC Trac Issues: #11057 > | > | > | >--- > | > | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | compiler/basicTypes/Id.hs | 11 +-- > | compiler/basicTypes/IdInfo.hs | 3 --- > | compiler/deSugar/Coverage.hs | 5 +++-- > | compiler/deSugar/DsExpr.hs | 4 +--- > | compiler/deSugar/DsMeta.hs | 2 +- > | compiler/hsSyn/Convert.hs | 4 +++- > | compiler/hsSyn/HsExpr.hs | 4 +++- > | compiler/hsSyn/PlaceHolder.hs | 2 ++ > | compiler/parser/RdrHsSyn.hs| 4 ++-- > | compiler/rename/RnExpr.hs | 6 +++--- > | compiler/typecheck/TcExpr.hs | 5 +++-- > | compiler/typecheck/TcHsSyn.hs | 4 ++-- compiler/typecheck/TcPatSyn.hs | > | 14 ++ > | 13 files changed, 30 insertions(+), 38 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 22080113f02f6644e2a0e3ce8adb1502346ab3b4 > | ___ > | ghc-commits mailing list > | ghc-comm...@haskell.org > | > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | > commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe > | > 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFFBiglS%2b > | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 you'll find RecSelId IdInfo; you can use that to get the labels. Would that work? Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 07 November 2015 23:50 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Remove PatSynBuilderId (2208011) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fchangeset%2f22080113f02f6644e2a0e3ce8adb1502346ab3b4%2fgh | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe4c08d2 | e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SQ%2fUVBd2qpKcBoN17ALE | MES4qFLtEuWiJakOotW0IUM%3d | | >--- | | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | Author: Matthew Pickering | Date: Sat Nov 7 23:46:03 2015 + | | Remove PatSynBuilderId | | Summary: | It was only used to pass field labels between the typechecker and | desugarer. Instead we add an extra field the RecordCon to carry this | information. | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D1443 | | GHC Trac Issues: #11057 | | | >--- | | 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | compiler/basicTypes/Id.hs | 11 +-- | compiler/basicTypes/IdInfo.hs | 3 --- | compiler/deSugar/Coverage.hs | 5 +++-- | compiler/deSugar/DsExpr.hs | 4 +--- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 4 +++- | compiler/hsSyn/HsExpr.hs | 4 +++- | compiler/hsSyn/PlaceHolder.hs | 2 ++ | compiler/parser/RdrHsSyn.hs| 4 ++-- | compiler/rename/RnExpr.hs | 6 +++--- | compiler/typecheck/TcExpr.hs | 5 +++-- | compiler/typecheck/TcHsSyn.hs | 4 ++-- compiler/typecheck/TcPatSyn.hs | | 14 ++ | 13 files changed, 30 insertions(+), 38 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 22080113f02f6644e2a0e3ce8adb1502346ab3b4 | ___ | ghc-commits mailing list | ghc-comm...@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c761b0bb4068a4d3ebe | 4c08d2e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BnsSFmFFBiglS%2b | ZyKRkye9LUDZyIh7lDkRoyCLDvb9U%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
