Re: A modest proposal (re the Platform)

+1 On Jan 19, 2014 3:15 PM, "Mark Lentczner" wrote: > Looks like GHC 7.8 is pretty near release. > > And while I know that we really like to have a GHC out for a while, and > perhaps see the .1 release, before we incorporate it into the Platform, > this GHC, while

Re: More aggressive dictionary removal?

The best way I know is to put INLINABLE on all functions with dictionaries that you want removed. That's what we do in e.g. containers. The pragma is perhaps a bit misnamed, as it doesn't only imply that we make the source of the function available for inlining, but also that we specialize the

Re: More aggressive dictionary removal?

I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the case

Re: Birthday greetings

Happy birthday! On Tue, Jan 19, 2016 at 9:31 AM, raichoo wrote: > Happy Birthday! > > Thanks for all your work, I'm very happy with Haskell and GHC, especially > now that I > can use it at work :D. > > I've been digging through GHC for months now, hoping to contribute >

Re: -XStrict: Why some binders are not made strict?

; I quite like this design. It's not clear to me that anything useful > is gained by forcing y and z in M3 before evaluating the body "...". > > > > > > > > > So Roman's design makes sense, but so does the implemented design > (modulo any bugs). The troub

Re: -XStrict: Why some binders are not made strict?

015 04:34 PM, Johan Tibell wrote: > > I'm snowed under but I promise I will try to reply soon! To think about > > in the mean time: what do existing strict languages with pattern > > matching do? > > Well, strict languages do not have lazy data to force to begin with,

Re: Does the Strict extension make monadic bindings strict?

I believe this is just a bug, since the desugaring ought to be strict in the \x. On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan wrote: > I think this is a problem/bug in the implementation. In the "function > definitions" section of the wiki page it says the argument

Taking a step back

on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment

Re: Converting unboxed sum types in StgCmm

-> > > > > ds2 is the thing that contains either an Int or a char; ds1 is the tag > that distinguishes htem. > > > > Simon > > > > *From:* Johan Tibell [mailto:johan.tib...@gmail.com] > *Sent:* 14 September 2015 17:03 > *To:* Ryan Newton; Simo

Re: Converting unboxed sum types in StgCmm

but I’m pretty sure I’m not wrong in a >> fundamental way. >> > > Yes, the only thing the code generator needs to do with types is convert > them to PrimReps (see idPrimRep), and all GC pointer types have the same > PrimRep (PtrRep). > > Cheers > Simon > > >

Re: Converting unboxed sum types in StgCmm

data type; the AltCons will be DataAlts | PrimAlt TyCon -- Primitive data type; the AltCons will be LitAlts or do I also have to capture which alternative was used here? Why do we capture the arity in *tuple* case here? On Mon, Sep 14, 2015 at 6:21 AM, Johan Tibell <johan.tib...@gmail.

Re: Converting unboxed sum types in StgCmm

I've given this a yet some more thought. Given this simple core program: f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int [GblId, Arity=1, Str=DmdType] f = \ (ds_dmE :: (#|#) Int Char) -> case ds_dmE of _ [Occ=Dead] { (#_|#) x_amy -> x_amy; (#|_#) ipv_smK -> patError @ Int

Re: Converting unboxed sum types in StgCmm

needs > to know, really, is which things are pointers. Detailed type info like > “are you a Char or a Bool” is strictly jam; indeed never used I think. (I > could be wrong but I’m pretty sure I’m not wrong in a fundamental way. > > > > SImon > > > > *From:* Johan Tibe

Converting unboxed sum types in StgCmm

Hi! The original idea for implementing the backend part of the unboxed sums proposal was to convert from the core representation to the actual data representation (i.e. a tag followed by some pointer and non-pointer fields) in the unarise stg-to-stg

Re: Converting unboxed sum types in StgCmm

I wonder if rewriting any aliased pointer field as Any in Stg and any non-pointer field as Word# would work. I suspect that not all non-pointer fields (e.g. Double# on 32-bit) can be represented as Word#. On Wed, Sep 9, 2015 at 3:22 PM, Johan Tibell <johan.tib...@gmail.com> wrote:

RFC: Unpacking sum types

I have a draft design for unpacking sum types that I'd like some feedback on. In particular feedback both on: * the writing and clarity of the proposal and * the proposal itself. https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes -- Johan ___

Re: RFC: Unpacking sum types

ntly put unboxed tuples in data types now. I'm not certain > if they would cover all cases, though (like the strictness concerns > above). > > -- Dan > > > On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell <johan.tib...@gmail.com> > wrote: > > I have a draft design for un

Re: ArrayArrays

e > >> motivating factors for me doing this. It is rather astoundingly > difficult to > >> beat the performance of HashMap, so I had to start cheating pretty > badly. ;) > >> > >> -Edward > >> > >> On Sat, Aug 29, 2015 at 5:45 PM, Johan Tibell <jo

Re: ArrayArrays

I'd also be interested to chat at ICFP to see if I can use this for my HAMT implementation. On Sat, Aug 29, 2015 at 3:07 PM, Edward Kmett ekm...@gmail.com wrote: Sounds good to me. Right now I'm just hacking up composable accessors for typed slots in a fairly lens-like fashion, and treating

Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing

attractive. I don’t understand. Can you describe the problem more precisely, perhaps with an example? S *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 25 August 2015 10:42 *To:* ghc-devs@haskell.org *Subject:* OVERLAPPABLE/OVERLAPPING

Re: MonadFail proposal (MFP): Moving fail out of Monad

On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky dluposchain...@googlemail.com wrote: I think there are two important consequences of MonadFail. First of all, we can all safely write failable patterns if we so desire. Second, the compiler can ensure other people's codebases do not lie

Re: MonadFail proposal (MFP): Moving fail out of Monad

On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka r...@ro-che.info wrote: On 10/06/15 14:22, Johan Tibell wrote: On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky dluposchain...@googlemail.com mailto:dluposchain...@googlemail.com wrote: I think there are two important

Re: MonadFail proposal (MFP): Moving fail out of Monad

Thanks for putting this together. The proposal says: As a consequence, in current Haskell, you can not use Monad-polymorphic code safely, because although it claims to work for all Monads, it might just crash on you. This kind of implicit non-totality baked into the class is terrible. Is this

Re: StrictData and the parser

On Thu, Jun 4, 2015 at 10:30 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700: Looks to me like it's confused about whether a ~ is part of an equality constraint or is a laziness annotation. The former would be illegal at that

Re: Branchless implementation for literal case – is it worth it?

On Apr 19, 2015 09:44, Joachim Breitner m...@joachim-breitner.de wrote: Dear devs, in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that code like f :: Int - Bool f a = case a of 1 - True 5 - True 8 -

Re: HP 2015.2.0.0 and GHC 7.10

cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: *Hey you* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be

Re: Cabal and simultaneous installations of the same package

On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones simo...@microsoft.com wrote: But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort

FYI: Cabal-1.22.1.0 has been released

We will probably want to ship that with GHC 7.10. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC support for the new record package

On Tue, Jan 27, 2015 at 3:12 AM, Simon Peyton Jones simo...@microsoft.com wrote: | 1. What are the IV instances provided in base? These could give | selector functions, lenses, both or neither. My instinct: just selector functions. Leave lenses for a lens package. +1

Re: GHC support for the new record package

I really like this proposal (except I would bike shed about the syntax for record selector to be dot, like in the majority of languages.) On Fri, Jan 23, 2015 at 3:41 PM, Simon Peyton Jones simo...@microsoft.com wrote: | I just | noticed that it effectively gives us a syntax for

RE: [commit: ghc] master: 32-bit performance wibbles (387f1d1)

Don't worry about the merge commit. On Jan 22, 2015 11:57 AM, Simon Peyton Jones simo...@microsoft.com wrote: BOTHER! I have no idea how my commit, which was meant to change two all.T files, also ended up adding libraries/haskell98. I'll revert and re-commit. I also inadvertently did 'git

Re: GHC support for the new record package

On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote: On 21/01/2015 16:01, Johan Tibell wrote: My thoughts mostly mirror those of Adam and Edward. 1) I want something that is backwards compatible. Backwards compatible in what sense? Extension flags provide backwards

Re: GHC support for the new record package

My thoughts mostly mirror those of Adam and Edward. 1) I want something that is backwards compatible. 2) Anonymous records are nice to have, but I don't want to have all records be anonymous (and have to jump through newtype hoops to get back non-anonymous records.) 3) I don't think it's a good

Re: Clarification of HsBang and isBanged

but the latter is source code specified. · Why isn't this information split over two data types. Because there’s a bit of overlap. See comments with HsSrcBang Simon *From:* Johan Tibell [mailto:johan.tib...@gmail.com] *Sent:* 08 January 2015 07:36 *To:* ghc-devs@haskell.org *Cc

Re: Clarification of HsBang and isBanged

have -funbox-strict-fields? On Sun, Jan 11, 2015 at 6:28 PM, Johan Tibell johan.tib...@gmail.com wrote: Those comments and the renaming really help. Here are a couple of more questions I got after exploring some more: DsMeta.repBangTy look wrong to me: repBangTy :: LBangType Name - DsM

Re: Clarification of HsBang and isBanged

or mismatched brackets) -- Johan On Sun, Jan 11, 2015 at 8:11 PM, Johan Tibell johan.tib...@gmail.com wrote: Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into account either. Should it? reifyStrict :: DataCon.HsSrcBang - TH.Strict reifyStrict HsNoBang

Re: Deprecating functions

We could file a tracking bug against the 7.14 milestone. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I want to deprecate some Template Haskell functions in

Re: warn-redundant-constraints present as errors

I think using the words error and warning makes sense. For example, this is how Clang (LLVM) does it: format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument printf(%.*d); ^ t.c:7:39: error: invalid operands to binary expression ('int'

Re: Deprecating functions

On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka r...@ro-che.info wrote: On 09/01/15 12:02, Jan Stolarek wrote: We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet. Just curious, is there a way to keep these functions for

Re: Deprecating functions

On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Why hide them? DEPRECATEd entities have the deprecation-message shown in discouraging red letters (including any hyperlinks to their replacements) in the generated Haddock documentation... I think Java's (!)

Re: Shipping core libraries with debug symbols

probably upstream this patch. Shipping libraries with debug symbols should be fine, as long as they can be stripped - Peter, does stripping remove everything that -g creates? Cheers, Simon On 02/01/2015 23:18, Johan Tibell wrote: Hi! We are now able to generate DWARF debug info, by passing

Re: Deprecating functions

On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with (...) That's why I want to deprecate them first and give users one release cycle to switch to new

Re: Deprecating functions

On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I think Java's (!) policy for deprecation is good I think it's not. It keeps the library code a mess and many times I have seen users using functions that have been deprecated for years just because it's easier to

Re: Shipping core libraries with debug symbols

anyways. We can always re-introduce the data for higher -gn levels. Greetings, Peter On 05/01/2015 00:59, Johan Tibell wrote: What about keeping exactly what -g1 keeps for gcc (i.e. functions, external variables, and line number tables)? On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann sc

Re: Clarification of HsBang and isBanged

annotations with a missing !, considered banged? On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell johan.tib...@gmail.com wrote: HsBang is defined as: -- HsBang describes what the *programmer* wrote -- This info is retained in the DataCon.dcStrictMarks field data HsBang

Re: Clarification of HsBang and isBanged

before now. Alan On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell johan.tib...@gmail.com wrote: I also note that the definition of isBanged is confusing: isBanged :: HsBang - Bool isBanged HsNoBang = False isBanged (HsUserBang Nothing bang) = bang isBanged

Clarification of HsBang and isBanged

HsBang is defined as: -- HsBang describes what the *programmer* wrote -- This info is retained in the DataCon.dcStrictMarks field data HsBang = HsUserBang -- The user's source-code request (Maybe Bool) -- Just True{-# UNPACK #-}

Re: Redundant constraints

I think this probably makes sense, especially since you can silence the warning when you intend to add an unnecessary constraint. I had one thought though: consider an abstract data type with functions that operates over it. I might want to require e.g Ord in the definition of a function so I

Re: Shipping core libraries with debug symbols

properly this would most certainly affect debuggers. Greetings, Peter On 03/01/2015 21:22, Johan Tibell wrote: How much debug info (as a percentage) do we currently generate? Could we just keep it in there in the release? ___ ghc-devs mailing

Re: Cabal 1.22 RC ready to test

On Sat, Jan 3, 2015 at 2:36 AM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Hi, On 3 January 2015 at 03:36, Johan Tibell johan.tib...@gmail.com wrote: If I don't hear anything the next few days I will make the release. The test suite doesn't compile with GHC HEAD on Travis

Re: Shipping core libraries with debug symbols

inconsequential data from .debug_info. In contrast to other programming languages, we just don't have that much debug information in the first place. Well, at least not yet. Greetings, Peter [1] https://gcc.gnu.org/wiki/DebugFission On 03/01/2015 00:18, Johan Tibell wrote: Hi! We are now

Re: Cabal 1.22 RC ready to test

/cabal On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell johan.tib...@gmail.com wrote: It might be as simple as bumping the Cabal submodule in GHC to match the upstream 1.22 branch. On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote: On 3 January 2015 at 15:05, Johan

Re: Cabal 1.22 RC ready to test

It might be as simple as bumping the Cabal submodule in GHC to match the upstream 1.22 branch. On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote: On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com wrote: The error (https://travis-ci.org/haskell/cabal/jobs

Re: Shipping core libraries with debug symbols

Brandon, If we just built GHC with debug symbols enabled, everything should just work from a packaging perspective? On Fri, Jan 2, 2015 at 7:26 PM, Brandon Allbery allber...@gmail.com wrote: On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com wrote: I believe other compilers

Shipping core libraries with debug symbols

Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

Try cabal install --allow-newer=base -j3 cabal-install Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the upper bound on the base dependency if 1.20 is indeed compatible with the latest base. On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts george.colpi...@gmail.com

Cabal 1.22 RC now available

I've just uploaded the Cabal-1.22.0.0 RC: http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz I know it's a bit late, but if you could update the GHC 7.10 branch to use it (Git tag: Cabal-v1.22.0.0-rc) that would be great. When do you need the actual release to happen, so it's out before GHC

Right way to turn off dynamic linking in build.mk

Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)

Re: Last call for 7.8.4

I will make the actual cabal 1.18 release today as the RCs looked good. On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp aus...@well-typed.com wrote: Hello *, I've just pushed a final round of patches to the 7.8 branch, including the notorious Cabal fix for the -fPIC bug that was discussed

Re: Last call for 7.8.4

Cabal 1.18.1.5 is out. On Mon, Dec 15, 2014 at 5:16 PM, Johan Tibell johan.tib...@gmail.com wrote: I will make the actual cabal 1.18 release today as the RCs looked good. On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp aus...@well-typed.com wrote: Hello *, I've just pushed a final round

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

at 4:52 AM, Ben Gamari bgamari.f...@gmail.com wrote: Johan Tibell johan.tib...@gmail.com writes: I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz https

Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

to an https page, even though cabal-install doesn't support it. On Fri, Dec 12, 2014 at 2:22 AM, Johan Tibell johan.tib...@gmail.com wrote: I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5

Re: Linker change in GHC 7.8 leads to widespread issues

If someone can figure out what the right fix is and if it happens to be in Cabal I'd be happy to merge any changes. On Tue, Dec 2, 2014 at 10:43 PM, Miëtek Bak mie...@bak.io wrote: On 2014-12-02, at 21:31, Carter Schonwald carter.schonw...@gmail.com wrote: whats an example of such a

Re: Windows build broken again: urgent

In general I think a good course of action when this happens is: * Use git bisect to find the offending commit. This works now because we moved to submodules. * Revert the commit. * Push the patch to master and notify the author. This style of early rollback will become more important as we grow

Re: Windows build broken again: urgent

it for me. Herbert suggested some commits to revert. I’ll try that first *From:* Johan Tibell [mailto:johan.tib...@gmail.com] *Sent:* 01 December 2014 09:45 *To:* Herbert Valerio Riedel *Cc:* ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones *Subject:* Re: Windows build broken again

Re: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)

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, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link :

Re: ANN: Updating flag description in the User's Guide

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 jan.stola...@p.lodz.pl wrote: What about standardizing on an 'experimental' prefix such as -fx-use-rpaths or -fx-kill-oneshot? These flags would

Re: Call Arity, oneShot or both

Thanks for the interesting analysis Joachim. I wouldn't trust nofib's runtime numbers (but the allocation ones should be good). The tests don't run long enough and the way we don't handle typical noise issues (e.g. clock resolution, benchmark length, etc) well enough. I'd love to see some numbers

Re: `arc` changes my commit messages

This is probably the biggest shortcoming of Phab. If you don't want this merging behavior you need to make a separate Phab review *per commit*. When I use arc I usually use git to rewrite the message after the review to something less messy. On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg

Re: RFC: Source-markup language for GHC User's Guide

Same here. My interaction with the user guide is infrequent enough that it doesn't matter much to me. On Wed, Oct 8, 2014 at 10:49 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Therefore I'd like to hear your opinion on migrating away from the current Docbook XML markup to some other

Re: Tentative high-level plans for 7.10.1

On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones simo...@microsoft.com wrote: | 8960 looks rather serious and potentially makes all of 7.8 a no-go | for some users. I think this is the big issue. If you look at all the related bugs linked from #8960, lots of users are affected. I think

Re: Tentative high-level plans for 7.10.1

is a show stopper i.e. it affects lots of people/core libraries and doesn't really have a good workaround, as turning of SpecConstr will most likely make e.g. vector too slow. On Tue, Oct 7, 2014 at 11:23 AM, Johan Tibell johan.tib...@gmail.com wrote: On Tue, Oct 7, 2014 at 10:12 AM, Simon

Re: Tentative high-level plans for 7.10.1

On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote: The danger, of course, is that people aren't very enthusiastic about bug-fixing older versions of a compiler, but for

Re: Show instance for SrcSpan

Aside: I really miss derived Show instances in GHC. The Outputable class is only really useful if you already know how things work. If you e.g. want to see the AST used to represent some piece of Haskell code, in all its glory, the Outputable instances aren't useful because they elide too much

Re: GitHub pull requests

At least for cabal there was a large uptick in contributions once we moved to GitHub. On Sun, Oct 5, 2014 at 7:03 AM, Ben Gamari bgamari.f...@gmail.com wrote: Richard Eisenberg e...@cis.upenn.edu writes: I've just finished reading this:

Re: Tentative high-level plans for 7.10.1

On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp aus...@well-typed.com wrote: - Cull and probably remove the 7.8.4 milestone. - Simply not enough time to address almost any of the tickets in any reasonable timeframe before 7.10.1, while also shipping them. - Only one, probably

Re: Windows build broken (again)

We need to get a windows build not up for phabricator that stops breaking changes from getting submitted. On Oct 2, 2014 10:40 PM, Simon Peyton Jones simo...@microsoft.com wrote: Sigh. The testsuite fails utterly on Windows, with thousands of identical errors = tc012(normal) 3039 of

Re: Permitting trailing commas for record syntax ADT declarations

The reason to support trailing commas are entirely related to engineering and not language expressiveness. Having trailing commas means that diff tools and version control systems work better. This is why most languages support them. ___ ghc-devs mailing

Re: Permitting trailing commas for record syntax ADT declarations

Sounds good to me. On Thu, Sep 25, 2014 at 11:18 AM, Simon Peyton Jones simo...@microsoft.com wrote: There’s a danger of disappearing into a bikeshed here. I think it’s clear that: · If we have it at all, ExtraCommas should be a {-# LANGUAGE ExtraCommas #-} extension, like any

Re: Permitting trailing commas for record syntax ADT declarations

I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones. One could argue that perhaps the HaskellXX standard might pick up this new pragma and thus making it unnecessary

Re: Permitting trailing commas for record syntax ADT declarations

+1 I think this makes sense and we should allow trailing commas wherever the syntax allows it without adding ambiguity (e.g. tuple sections prevent trailing commas for tuple declarations.) P.S. Last time we tried to discuss something like this (on libraries@ I believe) the whole discussion

Re: Permitting trailing commas for record syntax ADT declarations

On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote: Forwarding this my reply to the ML as well, On 22/09/14 14:27, David Luposchainsky wrote: +1. While you're at it, you may also want to consider

Re: Permitting trailing commas for record syntax ADT declarations

with it, but fails without ·develop a patch Easy really! I doubt it’s controversial. Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 22 September 2014 14:28 *To:* Alexander Berntsen *Cc:* ghc-devs@haskell.org *Subject:* Re: Permitting

Re: AMP performance effect

On Fri, Sep 12, 2014 at 3:52 PM, Joachim Breitner m...@joachim-breitner.de wrote: nothing overly exciting, but since I am running this ghcspeed thing, I guess I should inform you about changes, just to get some practice doing that :-) I'm very much in support of doing this. Once we think

Re: Does the 'stage=2' setting not work anymore in build.mk?

I think make maintainer-clean removes it. I find this hidden pieces of state annoying. It has definitely tripped me up in the past. Perhaps we can have make clean remove it? On Fri, Aug 29, 2014 at 2:14 PM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Fri, 29 Aug 2014, Edward Z. Yang wrote: OK,

Re: Windows build fails -- again!

I think reverting the patch (and notifying the author) is an OK course of action if it's affecting other people's work. I believe it's common practice at many other places. The patch can always be replied later, after fixing it. P.S. We should re-open the bug if we revert the patch (i.e. by git

Re: Windows build fails -- again!

f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably to blame. Found by running `git log -SsetIOManagerControlFd`. The -S flag is a good way to find when a symbol is added/removed. On Wed, Aug 20, 2014 at 12:16 AM, Simon Peyton Jones simo...@microsoft.com wrote: Aaargh! My windows build is

Re: HEADS UP: Running cabal install with the latest GHC

Edward made some changes so that GHC 7.10 is backwards compatible with older cabals (older cabals just can't use the new goodies, that's all), which means that we won't need an earlier release. I'm still aiming for another major release before 7.10? When's 7.10 scheduled before? On Fri, Aug 8,

How's the integration of DWARF support coming along?

Hi, How's the integration of DWARF support coming along? It's probably one of the most important improvements to the runtime in quite some time since unlocks *two* important features, namely * trustworthy profiling (using e.g. Linux perf events and other low-overhead, code preserving, sampling

Re: How's the integration of DWARF support coming along?

On Wed, Aug 13, 2014 at 5:07 PM, Tuncer Ayaz tuncer.a...@gmail.com wrote: On Wed, Aug 13, 2014 at 5:02 PM, Johan Tibell wrote: Hi, How's the integration of DWARF support coming along? It's probably one of the most important improvements to the runtime in quite some time since unlocks

Re: How's the integration of DWARF support coming along?

Ömer Sinan Ağacan omeraga...@gmail.com: Will generated stack traces be different that --- Ömer Sinan Ağacan http://osa1.net 2014-08-13 19:56 GMT+03:00 Johan Tibell johan.tib...@gmail.com: Yes, it doesn't use any code modification so it doesn't have runtime overhead (except when

Re: How's the integration of DWARF support coming along?

://arashrouhani.com/papers/master-thesis.pdf On 2014-08-13 17:02, Johan Tibell wrote: Hi, How's the integration of DWARF support coming along? It's probably one of the most important improvements to the runtime in quite some time since unlocks *two* important features, namely

Re: Moving Haddock *development* out of GHC tree

The biggest disadvantage in my mind is that you're setting yourself up for a potentially huge merge just before the GHC release and might block the GHC release until that merge is done (assuming that haddock is still shipped with GHC). ___ ghc-devs

Re: Moving Haddock *development* out of GHC tree

On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones simo...@microsoft.com wrote: The biggest disadvantage in my mind is that you're setting yourself up for a potentially huge merge just before the GHC release and might block the GHC release until that merge is done (assuming that haddock is

wORD_SIZE vs platformWordSize of targetPlatform

Hi, We seem to have two ways to get the same piece of information. We can get the target (?) word size as wORD_SIZE but there's also the platformWordSize field in the Platform data type, which is held as targetPlatform in DynFlags. Which one should I use? Most code uses wORD_SIZE. -- Johan

Improving the Int/Word story inside GHC

Inside GHC we mostly use Int instead of Word, even when we want to represent non-negative values, such as sizes of things or indices into things. This is now causing some grief in https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary case test fails with a segfault because a n

Re: Improving the Int/Word story inside GHC

Simon M, is the intention of ByteOff and WordOff that they should be able to represent negative quantities as well? If so we might need to split it into ByteOff (still an Int) and ByteIndex (a Word) to have a type for indexing into arrays. On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang

Re: Improving the Int/Word story inside GHC

, they were when I introduced them! SImon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 07 August 2014 12:21 *To:* Simon Marlow *Cc:* ghc-devs@haskell.org *Subject:* Re: Improving the Int/Word story inside GHC Simon M, is the intention

Re: Improving the Int/Word story inside GHC

introduced them! SImon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 07 August 2014 12:21 *To:* Simon Marlow *Cc:* ghc-devs@haskell.org *Subject:* Re: Improving the Int/Word story inside GHC Simon M

  1   2   3   >