That would be a neat solution - I'd second that...
On 14/03/17 11:13, Phil Ruffwind wrote:
I also dislike generated files in repos, but would like to point out
that there are a few pages out there that reference the link
https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
Certainly no complaints from me. I knew I was doing a Bad Thing when I
committed that file, but couldn't think of a good alternative, given the rarity
of finding an ott installation.
Thanks, Ben.
Richard
> On Mar 13, 2017, at 6:57 PM, Ben Gamari wrote:
>
> Hello
> I also dislike generated files in repos, but would like to point out
> that there are a few pages out there that reference the link
> https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
> directly; these would brake. But there is probably nothing we can
> easily do about that.
Hi,
Am Montag, den 13.03.2017, 18:57 -0400 schrieb Ben Gamari:
> I suggest that we remove the PDF from the repository but instead I can
> start including it in my nightly documentation builds. Any objections?
I also dislike generated files in repos, but would like to point out
that there are a
Edward Kmett writes:
> That, rather tangentially, reminds me: If we do start to teach the code
> generator about how to produce these sorts of things from simpler parts,
> e.g. via enabling something like LLVM's vectorization pass, or some
> internal future ghc compiler pass
Kill it! That's terrible practice indeed. Speaking of generated files, it's
time to check if our Unicode tables are up to date.
David FeuerWell-Typed, LLP
Original message From: Ben Gamari Date:
3/13/17 6:57 PM (GMT-05:00) To: GHC developers
Hello everyone,
Currently there is a typeset copy of the Core specification in the GHC
repository. This means any time someone changes the specification the
repository grows by around 300kB. While this isn't the end of the
world, it's generally considered bad form to put generated files under
That, rather tangentially, reminds me: If we do start to teach the code
generator about how to produce these sorts of things from simpler parts,
e.g. via enabling something like LLVM's vectorization pass, or some
internal future ghc compiler pass that checks for, say, Superword-Level
Parallelism
> On Mar 13, 2017, at 5:57 PM, Ben Gamari wrote:
>
> Richard, this is on Linux, yes?
Yes, it is. But I have now noticed other aspects of some very strange behavior
regarding the filesystem on my Linux server, so the problem may be unrelated to
GHC. (Example of other
Richard Eisenberg writes:
> Hi devs,
>
> When I try validating my patch, validation fails with
>
>> ...
>> Registering library for ghc-prim-0.5.0.0..
>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
>>
This was a fresh validation run, so make distclean won’t do it. And deleting
the file makes no difference. For what it’s worth, I ran with CPUS=1 (instead
of my usual CPUS=32) to avoid threading problems.
Any other suggestions?
Thanks!
Richard
> On Mar 13, 2017, at 10:07 AM, Ben Gamari
Hello everyone,
For the last few weeks Trac's password change functionality has been
disabled due to passwords being leaked through the ghc-tickets mailing
list.
I have updated the Trac configuration to fix this leakage and reenabled
this interface. Moreover, we shouldn't see any further email
Richard Eisenberg writes:
> Hi devs,
>
> When I try validating my patch, validation fails with
>
>> ...
>> Registering library for ghc-prim-0.5.0.0..
>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
>>
Richard Eisenberg wrote:
> /home/rae/ghc/ghc-valid/bindisttest/install
> > dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock
I'd try manually deleting that file.
Erik
--
--
Erik de Castro Lopo
14 matches
Mail list logo