- ghc-devs - Haskell.org

Re: We need to add role annotations for 7.8
by Richard Eisenberg 27 Mar '14

27 Mar '14

Not for more than a passing mention. Using the name of the module to control the default makes me unhappy (should choice of name be relevant in the correctness / interpretation of a program?). Other heuristics (presence of constrained functions) seem quite fragile. Of everything said so far, I think the closest suggestion is to use constrained datatypes (like `data Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which are silly) into something new and different, and so I personally don't think it's really viable. Following Mark's idea of breaking this problem up into more manageable chunks, I would want us to think about two separate (and conflicting, often) users: 1. Users of today's Haskell who have to update their code. 2. Users of Haskell in 10 years. Would users in group (2) like these heuristics? I doubt it. I think users in group (2) would probably most like a default of nominal with role annotations (in some concrete syntax). But, users in group (1) would hate a nominal default, so we have a compromise. Richard On Mar 26, 2014, at 11:40 AM, Casey McCann <cam(a)uptoisomorphism.net> wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >> Hi Mark, >> >> I appreciate your analysis in terms of classes of users -- I think that is >> helpful for framing the discussion. >> >> About transitivity: I think we're in the clear here. Let's say package A >> exports types missing role annotations. If package B imports package A and >> wants to have the full safety afforded by roles, that is no problem >> whatsoever. Package B has annotations on its types (which may use package >> A's types) that may restrict certain parameters to be nominal, as >> appropriate. If package A had role annotations, it's quite possible that >> package B could omit some annotations (as role inference propagates nominal >> roles), but there is no problem inherent in this. (Indeed, if package A adds >> annotations in the future, package B would have redundant, but harmless, >> annotations.) So, I disagree with Mark's "partially" below -- I think we're >> fully OK in this regard. >> >> About heuristics: we briefly considered some, though there's no >> documentation of this anywhere. Specifically, we thought about giving >> nominal roles to parameters used in class constraints. The problem is, in >> the actual datatype definition, the constraints tend not to appear? Should >> we look around for other functions with constraints? That seems likely to be >> more confusing than helpful. Furthermore, I strongly don't like the idea of >> using heuristics to infer a feature such as this -- it can cause strange >> behavior and is hard to specify. >> >> Richard >> >> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: >> >> Thank you to everyone who has been helping me understand this issue in >> greater depth. >> >> tl;dr: As long as we don't expect any libraries beyond to core to annotate, >> I'm cool. This presumes that the extra safety isn't, in practice, dependent >> on transitive adoption by libraries. It also implies that representational >> is the only possible default, and that there can be no migration from it. >> >> My approach to thinking about this is guided by thinking about supporting an >> eco-system with 1000s of libraries (hackage), a few dozen of which are >> heavily promoted (the platform), and a small set that are closely tied to >> the compiler (the core). The availability, speed of release, motivation, and >> even skill of the the developers varies widely over that range. >> >> I also think about the various "stances" of different developers: >> >> End developer: makes use of libraries, but just builds apps >> Internal developer: makes libraries for internal use in a project >> Casual library writer: makes libraries, primarily for their own needs, but >> distributed on hackage >> Popular library writer: actively maintains libraries which are widely used >> Core library writer: maintainer of a core package that stays in lock step >> with the compiler >> >> Then, I think about, for each of these, what is the effect on a new feature >> on them, their existing code, and future code? Does it affect them only if >> they are using the feature? If they aren't using the feature? For library >> writers, how does the feature affect clients? If a client wants to use a >> feature, under what conditions does the library need to do something? This >> last issue of the "transitivity" the feature is often the biggest concern. >> >> Given that... onto type roles: >> >> The default of representational is the only option, because a default of >> nominal would require far too many developers to have to update their code. >> I don't believe that we can ever migrate to nominal as default. >> >> The feature implies that any abstract data type that uses a type parameter >> in certain ways needs annotate to get the full safety afforded now afforded. >> However, without annotation, the data type is still no worse off than it was >> before (there is added safety, but not perhaps relevant to the stand point >> of the library writer). Further, this (pre-existing) non-safety isn't likely >> a huge concern. Making sure the docs take the tone that most developers need >> to nothing, and when developers need to be concerned seems like an important >> way to ensure the right outcome. >> >> A key question here is transitivity: Is it possible for module A to not >> annotate a type, and then have module B by a different author use the type >> in A in another abstract type, that is annotated, and get the benefit. Seems >> the answer is "partially". If the answer were "no", then use of the feature >> would be dependent on transitive adoption, and that is where the big burden >> on developers comes from. >> >> The degree to which we believe this "partially" is important: If we are >> willing to believe that the only library writers we care about doing this >> are those in the core, then fine. In this case we shouldn't feel compelled >> to suggest to library writers that they annotate, ever. I'm good with this. >> If the team here thinks otherwise, that we need to start a campaign to get >> every library writer to eventually annotate, then I have deep objections. >> >> I read the paper, and understand how the authors felt the syntax options >> were all less than perfect, and choose what they did. But that choice, >> perhaps unwittingly, the implication that it forces -XCPP on all libraries >> except perhaps some of the core. This is because they all need to support >> previous compilers. So, a one line annotation has turned into an ugly beast, >> and perhaps added -XCPP where there was none, which is really unfortunate. >> (I, like many, consider it a defeat when one has to resort to -XCPP.) >> >> It seems to me that the paper didn't really consider less-perfect, heuristic >> solutions. It might have had significantly less impact on library writers >> were some heuristic (no constructors exported? has any type constraint on >> the parameter? etc..) might have allowed most data types to go without >> annotation at the cost of a few (where nominal was incorrectly inferred) >> requiring immediate action. In this situation, a non-language feature >> (pragma or other device) might have been more palatable. >> >> Finally, on the choice of terms, nominal, representational, and phantom all >> seem like clear, self-explanatory choices to me. >> >> - Mark >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >>

2 1

Re: We need to add role annotations for 7.8
by Carter Schonwald 26 Mar '14

26 Mar '14

I think something like that is on the table, at least for a future ghc release. I'm not sure if it made it into the patches for 7.8.1. But this was actually suggested on the relevant ticket last week. (I'm Afk otherwise id dig up the link) On Wednesday, March 26, 2014, Casey McCann <cam(a)uptoisomorphism.net> wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > > Hi Mark, > > > > I appreciate your analysis in terms of classes of users -- I think that > is > > helpful for framing the discussion. > > > > About transitivity: I think we're in the clear here. Let's say package A > > exports types missing role annotations. If package B imports package A > and > > wants to have the full safety afforded by roles, that is no problem > > whatsoever. Package B has annotations on its types (which may use package > > A's types) that may restrict certain parameters to be nominal, as > > appropriate. If package A had role annotations, it's quite possible that > > package B could omit some annotations (as role inference propagates > nominal > > roles), but there is no problem inherent in this. (Indeed, if package A > adds > > annotations in the future, package B would have redundant, but harmless, > > annotations.) So, I disagree with Mark's "partially" below -- I think > we're > > fully OK in this regard. > > > > About heuristics: we briefly considered some, though there's no > > documentation of this anywhere. Specifically, we thought about giving > > nominal roles to parameters used in class constraints. The problem is, in > > the actual datatype definition, the constraints tend not to appear? > Should > > we look around for other functions with constraints? That seems likely > to be > > more confusing than helpful. Furthermore, I strongly don't like the idea > of > > using heuristics to infer a feature such as this -- it can cause strange > > behavior and is hard to specify. > > > > Richard > > > > On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > > > > Thank you to everyone who has been helping me understand this issue in > > greater depth. > > > > tl;dr: As long as we don't expect any libraries beyond to core to > annotate, > > I'm cool. This presumes that the extra safety isn't, in practice, > dependent > > on transitive adoption by libraries. It also implies that > representational > > is the only possible default, and that there can be no migration from it. > > > > My approach to thinking about this is guided by thinking about > supporting an > > eco-system with 1000s of libraries (hackage), a few dozen of which are > > heavily promoted (the platform), and a small set that are closely tied to > > the compiler (the core). The availability, speed of release, motivation, > and > > even skill of the the developers varies widely over that range. > > > > I also think about the various "stances" of different developers: > > > > End developer: makes use of libraries, but just builds apps > > Internal developer: makes libraries for internal use in a project > > Casual library writer: makes libraries, primarily for their own needs, > but > > distributed on hackage > > Popular library writer: actively maintains libraries which are widely > used > > Core library writer: maintainer of a core package that stays in lock step > > with the compiler > > > > Then, I think about, for each of these, what is the effect on a new > feature > > on them, their existing code, and future code? Does it affect them only > if > > they are using the feature? If they aren't using the feature? For library > > writers, how does the feature affect clients? If a client wants to use a > > feature, under what conditions does the library need to do something? > This > > last issue of the "transitivity" the feature is often the biggest > concern. > > > > Given that... onto type roles: > > > > The default of representational is the only option, because a default of > > nominal would require far too many developers to have to update their > code. > > I don't believe that we can ever migrate to nominal as default. > > > > The feature implies that any abstract data type that uses a type > parameter > > in certain ways needs annotate to get the full safety afforded now > afforded. > > However, without annotation, the data type is still no worse off than it > was > > before (there is added safety, but not perhaps relevant to the stand > point > > of the library writer). Further, this (pre-existing) non-safety isn't > likely > > a huge concern. Making sure the docs take the tone that most developers > need > > to nothing, and when developers need to be concerned seems like an > important > > way to ensure the right outcome. > > > > A key question here is transitivity: Is it possible for module A to not > > annotate a type, and then have module B b> > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org <javascript:;> > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <javascript:;> > http://www.haskell.org/mailman/listinfo/libraries >

1 0

RE: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)
by Simon Peyton Jones 26 Mar '14

26 Mar '14

Do us naïve users need to change our workflow with these submodule changes? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 23 March 2014 09:50 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Convert haddock into a proper submodule | (re #8545) (34b0721) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/34b072177b687c8fcc24f87293beae0 | 752e82d32/ghc | | >--------------------------------------------------------------- | | commit 34b072177b687c8fcc24f87293beae0752e82d32 | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Thu Mar 20 09:20:06 2014 +0100 | | Convert haddock into a proper submodule (re #8545) | | This should help contribute content to | | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules | | Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> | | | >--------------------------------------------------------------- | | 34b072177b687c8fcc24f87293beae0752e82d32 | .gitignore | 1 - | .gitmodules | 3 +++ | packages | 2 +- | utils/haddock | 1 + | 4 files changed, 5 insertions(+), 2 deletions(-) | | diff --git a/.gitignore b/.gitignore | index 93feea3..e60382b 100644 | --- a/.gitignore | +++ b/.gitignore | @@ -71,7 +71,6 @@ _darcs/ | /libraries/unix/ | /libraries/utf8-string/ | /nofib/ | -/utils/haddock/ | /utils/hsc2hs/ | | # ---------------------------------------------------------------------- | ------- | diff --git a/.gitmodules b/.gitmodules | index d83bfd0..99893a4 100644 | --- a/.gitmodules | +++ b/.gitmodules | @@ -54,3 +54,6 @@ | path = libraries/random | url = ../packages/random.git | ignore = untracked | +[submodule "utils/haddock"] | + path = utils/haddock | + url = ../haddock.git | diff --git a/packages b/packages | index 616dfc1..2683c99 100644 | --- a/packages | +++ b/packages | @@ -47,7 +47,7 @@ | ghc-tarballs windows ghc-tarballs.git | - | libffi-tarballs - libffi-tarballs.git | - | utils/hsc2hs - hsc2hs.git | - | -utils/haddock - haddock.git | - | +utils/haddock - - | - | libraries/array - packages/array.git | - | libraries/base - packages/base.git | - | libraries/binary - - | https://github.com/kolmodin/binary.git | diff --git a/utils/haddock b/utils/haddock | new file mode 160000 | index 0000000..725faca | --- /dev/null | +++ b/utils/haddock | @@ -0,0 +1 @@ | +Subproject commit 725faca5ee670f80359321adc112408880e9c073 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

3 4

Re: We need to add role annotations for 7.8
by Herbert Valerio Riedel 25 Mar '14

25 Mar '14

On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote: [...] > You might wanna pull the break before the release. Fwiw, reverting the new syntax at this point also has an effect on already officially released libraries such as http://hackage.haskell.org/package/containers-0.5.5.1 which started using the new non-pragma annotation[1]; so this would require new hackage uploads (and maybe hackage-deprecations)... just saying... [1]: http://hdiff.luite.com/cgit/containers/commit?id=0.5.5.0

1 0

RE: We need to add role annotations for 7.8
by Simon Peyton Jones 25 Mar '14

25 Mar '14

When Brandon says “potential bugs/unsafety and all” he means GeneralisedNewtypeDeriving (GND). That already exists, and already allows you to do bad things (Trac #1496 among others). See the thread on https://ghc.haskell.org/trac/ghc/ticket/8827, starting especially at comment 17 for more discussion and some insightful comments. As Edward (on the ticket) and Brandon (here) point out, going to “nominal by default” will be very safe but it’ll break many Haskell packages which use GND. This is really a library/user question, not a GHC one. We can implement whatever default you want. But GHC 7.8 is about to be released and this debate has been going on for some weeks, at high intensity on ghc-devs, plus Richard specifically advertised it to the libraries list back in November<http://www.haskell.org/pipermail/libraries/2013-November/021707.html>, and again a couple of weeks ago<http://www.haskell.org/pipermail/libraries/2014-March/022321.html>. I think the status quo is not unreasonable. One question you might want to debate is whether, as Brandon suggests, you want to move to “nominal by default” in due course. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Brandon Allbery Sent: 24 March 2014 14:28 To: Mark Lentczner Cc: GHC Development Mailing List; libraries(a)haskell.org Libraries Subject: Re: We need to add role annotations for 7.8 On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner <mark.lentczner(a)gmail.com<mailto:mark.lentczner@gmail.com>> wrote: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell(a)gmail.com<mailto:johan.tibell@gmail.com>> wrote: I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b(a)gmail.com<mailto:allbery.b@gmail.com>> wrote: Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. Am I reading these pair of statements correctly? It seems to imply to me that every parameterized type that uses a type constraint on a parameter must be reviewed and possibly annotated to work correctly, one way or the other! No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

5 7

module ‘free-4.6.1:Main’ is defined in multiple files
by Mateusz Kowalczyk 24 Mar '14

24 Mar '14

Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon™ (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone git@github.com:ekmett/free.git && cd free 4. cabal install --only-dependencies --enable-documentation && cabal configure && cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K.

2 1

Merge CmpNat and CmpSymbol in 7.8
by Iavor Diatchki 24 Mar '14

24 Mar '14

Hi, based on requests from a couple of people I added a couple of type-level functions for type nats and type symbols. Could we get these merged in 7.8? The relevant commits are: In GHC: 5e4bdb5fc5e741522cbb787731422da3f12aa398 Implement ordering comparisons for type-level naturals and symbols. In base: 5edb063688e73ec00fd1f61ac0e8317dd122f44a Comments only. c1d3546420ee482bbbd9f15d45a6e8a26304d419 Add functions for comparing type-level Nats and Symbols. Thanks! -Iavor

1 0

Re: We need to add role annotations for 7.8
by Mark Lentczner 24 Mar '14

24 Mar '14

On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery <allbery.b(a)gmail.com>wrote: > No; if the default is representational, everything works as it did in > earlier versions, potential bugs/unsafety and all. If the default is > immediately switched to nominal, *then* every affected type must be > reviewed immediately. > Now I'm confused about the current state of the default.... But it doesn't matter either way: The Platform is expected to work cohesively with the GHC release, and either of these defaults spells a huge amount of work for the Platform. > My counter-proposal was to have 7.8 default to representational to give > library maintainers a release cycle to add the necessary annotations, then > switch the default to nominal in 7.10 to get the additional safety. > This is unworkable. How much conditional code do you want library writers to have to have? Library writers strive to have code which works with n prior releases where n is commonly 3. Having code that works with 7.6, 7.8, and 7.10 would be a nighmare! On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > perhaps there should be some mechanism to specify to ghc 7.8 whether a > compile should default to representational or nominal so that authors have > a way to test their code / look for problems. > Also unworkable... now we need a conditional flag for the state of the default so the code can be written to work with either based on a GHC flag? And how is that supposed to work with already compiled dependencies (sandboxed or not)? Is cabal now to take this flag into account? the Package manager signatures too? The major problem with this feature is that it is massively global in scope. This is extremely rare for GHC extensions (Safe comes to mind)... and with good reason: It is very very expensive. The motivating case here, a compiler checked safe zero-cost coerce, seems way out of proportion to the cost: Careful review of every library abstract type, and addition of *three+* lines of source (remember, this must be CPP guarded, so you have to add CPP extension on to every file, too).

2 1

Re: We need to add role annotations for 7.8
by Mark Lentczner 24 Mar '14

24 Mar '14

Speaking from the vantage point of platform.... This pair of comments (emphasis mine) have my alarm index on high: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell(a)gmail.com>wrote: > I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If > the default is representational, every package author will need to be aware > of this feature and update their packages.* That's quite a high cost. > On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > *Nominal default breaks everything that uses newtype deriving and doesn't > have role annotations, doesn't it?* Representational default means things > behave in 7.8 as they did in earlier GHCs. > Am I reading these pair of statements correctly? It seems to imply to me that *every* parameterized type that uses a type constraint on a parameter *must* be reviewed and possibly annotated to work correctly, one way or the other! Seems so: On Fri, Mar 14, 2014 at 7:22 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > So, the best thing we came up with is this: Libraries that wish to export > abstract data types must do two things: > 1. Manage export lists carefully. > *2. Use role annotations.* > This is huge order, and one that will produce significant strain on the ecosystem. For one, this will set back Haskell Platform months: We have 250k lines of Haskell by 30+ authors that will need to be reviewed and updated. And all of this is so that data types can be coerced more safely? While I'm all for safely, the number of places where coercion is that important seems very small... and this addition to the language and burden on the libraries very high. If this feature cannot be added safely without reviewing 1/4 million lines of library code (not to mention all of hackage)... Then I think it isn't ready and shouldn't be released in 7.8. - Mark

2 1

Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
by Jost Berthold 24 Mar '14

24 Mar '14

Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find "STD_HDR_SIZE" I ran the nm command manually on the generated o file (includes/dist-derivedconstants/header/tmp.o) and saw that the output follows pattern _derivedConstantBlaBlah_Blah C 000001b so it does not match the four-word pattern in the patch. Is this a problem with my setup, or does it fail for other people on Windows as well? Thanks, Jost On 03/23/2014 08:46 AM, ghc-commits-request(a)haskell.org wrote: > Message: 6 > Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC) > From: git(a)git.haskell.org > To: ghc-commits(a)haskell.org > Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a > POSIX way (fixes #8781) (e7563ec) > Message-ID: <20140323020150.1DCE82406B(a)ghc.haskell.org> > Content-Type: text/plain; charset=utf-8 > > Repository : ssh://git@git.haskell.org/ghc > > On branch : ghc-7.8 > Link : http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972… > >> --------------------------------------------------------------- > > commit e7563ec2e03740074903036bf129fc972b623c23 > Author: Karel Gardas <karel.gardas(a)centrum.cz> > Date: Sat Mar 22 22:33:05 2014 +0100 > > change deriveConstants to use nm in a POSIX way (fixes #8781) > > The patch provided by Christian Maeder <Christian.Maeder(a)dfki.de> > > Signed-off-by: Karel Gardas <karel.gardas(a)centrum.cz> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc) > > >> --------------------------------------------------------------- > > e7563ec2e03740074903036bf129fc972b623c23 > utils/deriveConstants/DeriveConstants.hs | 30 ++++++++++-------------------- > 1 file changed, 10 insertions(+), 20 deletions(-) > > diff --git a/utils/deriveConstants/DeriveConstants.hs b/utils/deriveConstants/DeriveConstants.hs > index 10df61c..54ee6a1 100644 > --- a/utils/deriveConstants/DeriveConstants.hs > +++ b/utils/deriveConstants/DeriveConstants.hs > @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram > oFile = tmpdir </> "tmp.o" > writeFile cFile cStuff > execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", oFile]) > - xs <- readProcess nmProgram [oFile] "" > + xs <- readProcess nmProgram ["-P", oFile] "" > let ls = lines xs > ms = map parseNmLine ls > m = Map.fromList $ catMaybes ms > @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram > doWanted (ClosurePayloadMacro {}) = [] > doWanted (FieldTypeGcptrMacro {}) = [] > > - -- parseNmLine parses nm output that looks like > - -- "0000000b C derivedConstantMAX_Vanilla_REG" > + -- parseNmLine parses "nm -P" output that looks like > + -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X > + -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU > + -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris > -- and returns ("MAX_Vanilla_REG", 11) > - parseNmLine xs0 = case break (' ' ==) xs0 of > - (x1, ' ' : xs1) -> > - case break (' ' ==) xs1 of > - (x2, ' ' : x3) -> > - case readHex x1 of > - [(size, "")] -> > - case x2 of > - "C" -> > - let x3' = case x3 of > - '_' : rest -> rest > - _ -> x3 > - in case stripPrefix prefix x3' of > - Just name -> > - Just (name, size) > - _ -> Nothing > - _ -> Nothing > - _ -> Nothing > + parseNmLine xs0 = case words xs0 of > + [x0, x1, x2, x3] -> case stripPrefix prefix $ dropWhile (== '_') x0 of > + Just name -> case readHex $ if x1 == "C" then x2 else x3 of > + [(size, "")] -> Just (name, size) > _ -> Nothing > + _ -> Nothing > _ -> Nothing > > -- If an Int value is larger than 2^28 or smaller

5 10