I also wonder if it would be nice for Phabricator to upload
documentation/artifacts somewhere. Maybe I should implement this, for
the Continuous Integration builds on Phab.
The main thing is I don't want the build to get all spammy with a
million emails, like it did before. But maybe that's workar
Ok, that explains it. Thanks!
On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow wrote:
> On 15/09/2014 17:50, Ryan Yates wrote:
>
>> I'm starting to get to the bottom of something that has been puzzling me
>> for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497
>> [1] introduced th
Mateusz,
I had a moment to take a look at your patch. Here are some hints:
> * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
> tickyVectoredReturn need to be added. Unfortunately I'm not familiar with
> the code enough to find the right place to insert them.
I think that you s
Agreed. For example, the HTTP standard has moved away from X-prefixed
headers for similar reasons.
On Thu, Nov 6, 2014 at 2:13 PM, Jan Stolarek wrote:
> > What about standardizing on an 'experimental' prefix such as
> -fx-use-rpaths
> > or -fx-kill-oneshot? These flags would not be added to the
> What about standardizing on an 'experimental' prefix such as -fx-use-rpaths
> or -fx-kill-oneshot? These flags would not be added to the user guide and
> their intent clear when actually using them.
As already stated in an earlier reply I think we should have documentation for
the sake of other
Simon Marlow wrote:
> isn't -ddump-simpl-phases useful? what's the other way to do that?
-dverbose-core2core + -ddump-simple-stats
Johan Tibell wrote:
> I think this flag is useful for debugging e.g. why something didn't
> optimize the way you thought.
Well, you can get that information using fla
> Sometimes we add flags that are for experimentation or development
> purposes and not intended for user consumption, and these tend not to be
> added to the User's Guide. I suspect many of the flags you mention fall
> into this category. I suggest for these we have a specific comment in
> the s
> * it is slightly tricky to find it. Starting from
> https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is
> also availble” link about daily builds, and then the link from the
> summary. Ok if one knows where to look, but hard to discover by itself.
Yeah, I had the same problem in
2014-11-06 13:27 GMT+01:00 Joachim Breitner :
> a while ago someone said that we have daily builds of the documentation.
> But...
I guess that was me, but I cannot do the Windows builds any more,
because the Cabal library update broken the build for me. (See my
previous mails on the subject, even
What about standardizing on an 'experimental' prefix such as -fx-use-rpaths
or -fx-kill-oneshot? These flags would not be added to the user guide and
their intent clear when actually using them.
On Thu, Nov 6, 2014 at 10:28 AM, Simon Marlow wrote:
> On 06/11/2014 12:06, Jan Stolarek wrote:
>
>>
Hi Simon,
with
Am Mittwoch, den 05.11.2014, 18:15 + schrieb g...@git.haskell.org:
> commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf
> Author: Simon Marlow
> Date: Tue Nov 4 21:31:00 2014 +
>
> Fix a couple of inaccurate stack checks
I observe a 5% runtime performance regression
Hi,
Am Donnerstag, den 06.11.2014, 12:32 + schrieb Simon Peyton Jones:
> | * it is slightly tricky to find it. Starting from
> | https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is
> | also availble” link about daily builds, and then the link from the
> | summary. Ok if
On 15/09/2014 17:50, Ryan Yates wrote:
I'm starting to get to the bottom of something that has been puzzling me
for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497
[1] introduced the GC write barrier for TVars. Not fully understanding
things and reading the commit message to b
| * it is slightly tricky to find it. Starting from
| https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is
| also availble” link about daily builds, and then the link from the
| summary. Ok if one knows where to look, but hard to discover by
| itself.
Where would you expect
I think this flag is useful for debugging e.g. why something didn't
optimize the way you thought.
On Nov 6, 2014 1:05 PM, wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch : master
> Link :
> http://ghc.haskell.org/trac/ghc/changeset/ad8457f93807e3b7a9a24867ed69dc93662a29e
On 06/11/2014 12:06, Jan Stolarek wrote:
Devs,
I have some important information for everyone.
TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please
make absolutely sure that your changes are described in the User's Guide. See
Note [Updating flag description in
Hi,
a while ago someone said that we have daily builds of the documentation.
But...
* it is slightly tricky to find it. Starting from
https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the “Guilde is
also availble” link about daily builds, and then the link from the
summary. Ok if one knows
Devs,
I have some important information for everyone.
TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please
make absolutely sure that your changes are described in the User's Guide. See
Note [Updating flag description in the User's Guide] in DynFlags.
TL;DR2 Your
On Tue, Nov 04, 2014 at 09:52:23AM +, Simon Peyton Jones wrote:
> We don’t have "vectored returns" any more, so you can drop that one.
Thanks!
>
> For "magic eight" there are some native-wordsize constants defined already.
> E.g. see how PrelRules.wordSizeInBits is computed.
As far as I und
Hi Edward,
Thank you for your mail.
On 2014-11-05 18:37 (Wednesday), "Edward Z. Yang" writes:
> Hello Gergely,
>
> You added a function loadInterfaceForModule which has the exact same
> type as loadModuleInterface, except when debugging is on it has an extra
> check to ensure you don't try to lo
| Oh, and the reason you have the debug RTS in your compiler is because
| `-ticky` implies `-debug
Interesting. I didn't know that. Is that a good idea? Wouldn't it be better
to make them independent?
Simon
| -Original Message-
| From: ghc-tickets [mailto:ghc-tickets-boun...@hask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I want to be able to write essentially this function:
f :: (a -> d) -> (b, c) -> (d, d)
f g (x, y) = (g x, g y)
What do we need here for this to work?
Well, given 'g :: a -> d', we need 'a' ~ 'b' ~ 'c' from the
constraints of 'g'. So let 'g = show
On 6 November 2014 00:49, Carter Schonwald
wrote:
> TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4
> or older
>
Can we expect 3.5 (3.6) to work with ghc-7.10?
(FWIW helloworld seems to work ok with ghc-7.8.3 on x86_64, but not on
ARMv7.)
Or anyone have any patches?
J
23 matches
Mail list logo
