Re: More GND + role inference woes
Yuck.
But, many, many thanks for discovering this now instead of later.
For various silly reasons, I didn't have a platform (i.e. a recent enough HEAD
in the right state, etc.) for me to explore this today (Monday). But, I should
have the time and ability to look closer on Tuesday.
If it's really as bad as you say, we'll need to think carefully about how to
proceed. I have various thoughts about how to fix the problem, but none would
be ready for 7.8 by a long shot. So, do we issue warnings (that a GND, or
perhaps a use of `coerce` might not be safe) in 7.8? How would a user disable
these warnings?
Anyway, more tomorrow.
Richard
On Oct 13, 2013, at 6:01 PM, Edward Kmett wrote:
> I didn't think I was using GND much at all, but apparently I was wrong.
>
> After Ben's initial foray into building linear, I went and looked at the
> other applications of GeneralizedNewtypeDeriving in my code and found that in
> parsers, all of the derived instances for the supplied parser transformers
> fail.
>
> This also affects any attempt to use GND to do deriving for any monad
> transformer stack that isn't fully instantiated to concrete terms. This is
> actually a very common idiom to avoid writing boilerplate on top of
> transformers:
>
> newtype T m a = T { runT : StateT MyState (ReaderT MyEnv) m a }
> deriving (Functor, Monad, Applicative, MonadState MyState, MonadReader
> MyEnv, ...)
>
> As I rummage through more of my code, I actually can't find any instances of
> GND that do still work that aren't of the form:
>
> newtype Foo a = Foo { runFoo :: a } deriving ...
>
> Literally every other example I have of GND in the code I maintain has
> something in it that causes it to run afoul of the new roles machinery.
>
> I'd say the problem is more widespread than we thought.
>
> -Edward
>
>
> On Sun, Oct 13, 2013 at 5:26 PM, Edward Kmett wrote:
> Ben Gamari was trying to update my linear package to work with GHC HEAD.
>
> Along the way he noted an example of the new GND+role inference machinery
> failing rather spectacularly.
>
> http://hackage.haskell.org/package/linear-1.3/docs/src/Linear-Affine.html#Point
>
> Note the number of classes that the current proposal would force us to hand
> implement.
>
> =(
>
> -Edward
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
The issue with such an explicit false is that it requires more magic on behalf of the compiler. It would have to be filled in whenever an explicit `instance Eq Blah` was written. Recall that deriving instance Eq Blah can occur after the data type declaration site and may have to be used for many more complicated recursive data types, so it isn't sufficient to fill in at the data type declaration. -Edward On Mon, Oct 14, 2013 at 11:41 PM, Ryan Newton wrote: > But what stops the user from defining their own instances if they in fact > did not derive it? > > The explicit "False" in Pedro's formulation seems to serve this purpose. > > > > On Mon, Oct 14, 2013 at 11:20 PM, Nicolas Frisby > wrote: > >> The formulation as a type family seems to conflict with the open-world >> principle. Would a class-based encoding instead be sufficient? >> >> -- the proposed, special wired-in class >> class Derives (t :: k1) (c :: k2) >> >> -- GHC would infer these from Pedro's example's declarations >> instance Derives MyData Eq >> instance Derives MyData Generic >> instance Derives MyData Show >> >> NB that there is no instance Derives MyData Ord, but standalone deriving >> could yield one "later" >> >> On Mon, Oct 14, 2013 at 10:02 PM, Ryan Newton wrote: >> >>> Hey, that's an awesome formulation! Thanks Pedro. >>> >>> Any idea how much work this would be to implement in GHC, if it did >>> garner approval? >>> >>> >>> On Tue, Oct 8, 2013 at 3:48 AM, José Pedro Magalhães >>> wrote: >>> Hi, On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall wrote: > Here‘s a thought: doesn’t Generic already have an unused phantom type > that's only there “just in case we need to add something in the future”? > No, it doesn't. Just a thought: what if we had a type family type family Derives (t :: k1) (c :: k2) :: Bool which would automatically be instantiated by GHC appropriately? E.g., if the user had the following code: data MyData = MyData deriving (Eq, Generic) deriving instance Show MyData instance Ord MyData GHC would automatically instantiate: type instance Derives MyData Eq = True type instance Derives MyData Generic = True type instance Derives MyData Show= True type instance Derives MyData Ord = False Would this be something Ryan could use for detecting safe instances for LVish? Cheers, Pedro ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
But what stops the user from defining their own instances if they in fact did not derive it? The explicit "False" in Pedro's formulation seems to serve this purpose. On Mon, Oct 14, 2013 at 11:20 PM, Nicolas Frisby wrote: > The formulation as a type family seems to conflict with the open-world > principle. Would a class-based encoding instead be sufficient? > > -- the proposed, special wired-in class > class Derives (t :: k1) (c :: k2) > > -- GHC would infer these from Pedro's example's declarations > instance Derives MyData Eq > instance Derives MyData Generic > instance Derives MyData Show > > NB that there is no instance Derives MyData Ord, but standalone deriving > could yield one "later" > > On Mon, Oct 14, 2013 at 10:02 PM, Ryan Newton wrote: > >> Hey, that's an awesome formulation! Thanks Pedro. >> >> Any idea how much work this would be to implement in GHC, if it did >> garner approval? >> >> >> On Tue, Oct 8, 2013 at 3:48 AM, José Pedro Magalhães >> wrote: >> >>> Hi, >>> >>> On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall wrote: >>> Here‘s a thought: doesn’t Generic already have an unused phantom type that's only there “just in case we need to add something in the future”? >>> No, it doesn't. >>> >>> Just a thought: what if we had a type family >>> >>> type family Derives (t :: k1) (c :: k2) :: Bool >>> >>> which would automatically be instantiated by GHC appropriately? E.g., if >>> the user had the following code: >>> >>> data MyData = MyData deriving (Eq, Generic) >>> deriving instance Show MyData >>> instance Ord MyData >>> >>> GHC would automatically instantiate: >>> >>> type instance Derives MyData Eq = True >>> type instance Derives MyData Generic = True >>> type instance Derives MyData Show= True >>> type instance Derives MyData Ord = False >>> >>> Would this be something Ryan could use for detecting safe instances for >>> LVish? >>> >>> >>> Cheers, >>> Pedro >>> >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
The formulation as a type family seems to conflict with the open-world principle. Would a class-based encoding instead be sufficient? -- the proposed, special wired-in class class Derives (t :: k1) (c :: k2) -- GHC would infer these from Pedro's example's declarations instance Derives MyData Eq instance Derives MyData Generic instance Derives MyData Show NB that there is no instance Derives MyData Ord, but standalone deriving could yield one "later" On Mon, Oct 14, 2013 at 10:02 PM, Ryan Newton wrote: > Hey, that's an awesome formulation! Thanks Pedro. > > Any idea how much work this would be to implement in GHC, if it did garner > approval? > > > On Tue, Oct 8, 2013 at 3:48 AM, José Pedro Magalhães wrote: > >> Hi, >> >> On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall wrote: >> >>> Here‘s a thought: doesn’t Generic already have an unused phantom type >>> that's only there “just in case we need to add something in the future”? >>> >> No, it doesn't. >> >> Just a thought: what if we had a type family >> >> type family Derives (t :: k1) (c :: k2) :: Bool >> >> which would automatically be instantiated by GHC appropriately? E.g., if >> the user had the following code: >> >> data MyData = MyData deriving (Eq, Generic) >> deriving instance Show MyData >> instance Ord MyData >> >> GHC would automatically instantiate: >> >> type instance Derives MyData Eq = True >> type instance Derives MyData Generic = True >> type instance Derives MyData Show= True >> type instance Derives MyData Ord = False >> >> Would this be something Ryan could use for detecting safe instances for >> LVish? >> >> >> Cheers, >> Pedro >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
Hey, that's an awesome formulation! Thanks Pedro. Any idea how much work this would be to implement in GHC, if it did garner approval? On Tue, Oct 8, 2013 at 3:48 AM, José Pedro Magalhães wrote: > Hi, > > On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall wrote: > >> Here‘s a thought: doesn’t Generic already have an unused phantom type >> that's only there “just in case we need to add something in the future”? >> > No, it doesn't. > > Just a thought: what if we had a type family > > type family Derives (t :: k1) (c :: k2) :: Bool > > which would automatically be instantiated by GHC appropriately? E.g., if > the user had the following code: > > data MyData = MyData deriving (Eq, Generic) > deriving instance Show MyData > instance Ord MyData > > GHC would automatically instantiate: > > type instance Derives MyData Eq = True > type instance Derives MyData Generic = True > type instance Derives MyData Show= True > type instance Derives MyData Ord = False > > Would this be something Ryan could use for detecting safe instances for > LVish? > > > Cheers, > Pedro > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
Yes, but it doesn't work for people still using Xcode 4.6! Might it be more correct, albeit hacky aesthetically, to have the clang wrapper actually call GCC, because in Xcode 5 its just a wrapper around clang, and in Xcode 4.6 we need to use GCC rather than clang anyways? That said, that might be the best overall approach. Though it does entail packaging the clang wrapper with ghc / hp for ghc 7.6 on OS X On Monday, October 14, 2013, Luke Iannini wrote: > To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really > not that big: > 7.6.3 passes "-x c" when running the c compiler in preprocessor mode. > Clang requires "-x assembler-with-cpp" to be compatible with the GHC > codebase. > > So the workaround Austin Seipp helped me cook up is to simply wrap clang, > detect it's being run in preprocessor mode (i.e. look for the args "-E > -undef -traditional"), and make sure it gets passed -x assembler-with-cpp. > > You can see the entirety of it here: > > https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.hs > > I wrote the workaround as a a Haskell script, but someone with basic > bash-fu could easily write it as a shell script. > > 7.6.3's settings file just has to be pointed at that wrapper instead of > directly at clang and then everything works flawlessly with Xcode 5's > clang, on 10.8 and 10.9 alike. > > Cheers > Luke > > On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > > I guess my point is there's a number of work arounds that are easy for a > power user to support, but should NOT be the default setup or config > required for new users. > > Eg: brew also provides an installer for apple-gcc42 and you could then > point your ghc settings file to. > > That said, it's not a solution we probably want to encourage by default, > it definitely took me a while to cook up sane directions, and some of those > directions/approaches apparently become useless if you update to OS X 10.9. > (I think partly because the default C++ std libs on Mac shift, so you can't > easily build GCC on mavericks currently allegedly ) > > On Monday, October 14, 2013, Edward Kmett wrote: > > As I do most of my development on a Mac I confess I currently live in fear > of accidentally clicking on the XCode 5 upgrade button and winding up in an > unsupported configuration. That makes me very leery of option C, where > developers like me are treading on egg-shells around system updates for the > next 6 months. > > -Edward > > > > On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner > wrote: > > It wasn't my intention to open up the whole question of scheduled > releases. HP has a regular release schedule, and there were many good > discussions leading up to it. As for the timing of those releases, last > time we looked into this there was no good release time that worked for all > the common Linux distro's release schedules. Perhaps GNOME has figured this > one out - they release stable end of September and end of March. We could > aim to glide toward that. > > Back to this release: > > GHC 7.8 won't be ready for inclusion in an HP for quite some time. We > haven't even seen the first release yet! If it has stabilized by end of > February, then it could make it into the next HP (assuming we don't move > the schedule up to match GNOME). But I think realistically, one shouldn't > expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If > the community wants to see closer tracking, then we probably need to start > talking about a different way of producing GHC - with both stable and > experimental releases happening... when this idea has been raised in the > past, GHC central hasn't had the person-power to do it.]* > * > * > The next Mac OS X is indeed right around the corner (no official date from > Apple, just "this Autumn") - the GM release candidate of both OS X > Mavericks and Xcode 5 are already in developers (and my) hands. My > understanding is that current HP just won't work on it - which means we > really should get something out to support it. > > SO, back to concrete ideas: > > *A) Minor release* > > *• Minor rev:* since GHC and most packages haven't changed, and we won't > be adding anything, just roll it as normal now. > *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC > 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 > > *—or—* > *B) Delay release* > > *• New packages:* running the normal process, just a month late > > *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is > needed to support Xcode 5 > > *—or—* > *C) Skip a release* > > *• Go for 7.8:* push everyone (GHC central, library maintainers) to get > 7.8 stable ASAP > > *• Big Push for Packages:* use the time to push for a significant > increase in the packages in the Platform > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Xcode 5 support for GHC iOS
Hi all, Just wanted to let you know I've finished updating GHC iOS to support Xcode 5. The new scripts are at https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find updated instructions at http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . Please let me know if you have any trouble! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really not that big: 7.6.3 passes "-x c" when running the c compiler in preprocessor mode. Clang requires "-x assembler-with-cpp" to be compatible with the GHC codebase. So the workaround Austin Seipp helped me cook up is to simply wrap clang, detect it's being run in preprocessor mode (i.e. look for the args "-E -undef -traditional"), and make sure it gets passed -x assembler-with-cpp. You can see the entirety of it here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.hs I wrote the workaround as a a Haskell script, but someone with basic bash-fu could easily write it as a shell script. 7.6.3's settings file just has to be pointed at that wrapper instead of directly at clang and then everything works flawlessly with Xcode 5's clang, on 10.8 and 10.9 alike. Cheers Luke On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > I guess my point is there's a number of work arounds that are easy for a > power user to support, but should NOT be the default setup or config > required for new users. > > Eg: brew also provides an installer for apple-gcc42 and you could then > point your ghc settings file to. > > That said, it's not a solution we probably want to encourage by default, > it definitely took me a while to cook up sane directions, and some of those > directions/approaches apparently become useless if you update to OS X 10.9. > (I think partly because the default C++ std libs on Mac shift, so you can't > easily build GCC on mavericks currently allegedly ) > > On Monday, October 14, 2013, Edward Kmett wrote: > >> As I do most of my development on a Mac I confess I currently live in >> fear of accidentally clicking on the XCode 5 upgrade button and winding up >> in an unsupported configuration. That makes me very leery of option C, >> where developers like me are treading on egg-shells around system updates >> for the next 6 months. >> >> -Edward >> >> >> >> On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner > > wrote: >> >>> It wasn't my intention to open up the whole question of scheduled >>> releases. HP has a regular release schedule, and there were many good >>> discussions leading up to it. As for the timing of those releases, last >>> time we looked into this there was no good release time that worked for all >>> the common Linux distro's release schedules. Perhaps GNOME has figured this >>> one out - they release stable end of September and end of March. We could >>> aim to glide toward that. >>> >>> Back to this release: >>> >>> GHC 7.8 won't be ready for inclusion in an HP for quite some time. We >>> haven't even seen the first release yet! If it has stabilized by end of >>> February, then it could make it into the next HP (assuming we don't move >>> the schedule up to match GNOME). But I think realistically, one shouldn't >>> expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If >>> the community wants to see closer tracking, then we probably need to start >>> talking about a different way of producing GHC - with both stable and >>> experimental releases happening... when this idea has been raised in the >>> past, GHC central hasn't had the person-power to do it.]* >>> * >>> * >>> The next Mac OS X is indeed right around the corner (no official date >>> from Apple, just "this Autumn") - the GM release candidate of both OS X >>> Mavericks and Xcode 5 are already in developers (and my) hands. My >>> understanding is that current HP just won't work on it - which means we >>> really should get something out to support it. >>> >>> SO, back to concrete ideas: >>> >>> *A) Minor release* >>> >>> *• Minor rev:* since GHC and most packages haven't changed, and we >>> won't be adding anything, just roll it as normal now. >>> *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC >>> 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 >>> >>> *—or—* >>> *B) Delay release* >>> >>> *• New packages:* running the normal process, just a month late >>> >>> *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is >>> needed to support Xcode 5 >>> >>> *—or—* >>> *C) Skip a release* >>> >>> *• Go for 7.8:* push everyone (GHC central, library maintainers) to get >>> 7.8 stable ASAP >>> >>> *• Big Push for Packages:* use the time to push for a significant >>> increase in the packages in the Platform >>> >>> *• Release in March: *aiming to sync with GNOME, assuming they're on to >>> something! >>> >>> >>> As attractive as some aspects of C are, it leaves anyone with a Mac out >>> in the cold for six months: They either can't upgrade, or can't Haskell. >>> >>> A requires duplicate effort (mostly on my part), but is otherwise >>> mechanical... and not that exciting. >>> >>> B deviates from our schedule, but if GHC can roll a 7.6.4, might get us >>> an HP with some new packages. >>> >>> — Mark >>> >>> >>>
Re: Wither Haskell Platform 2013.4.0.0
I guess my point is there's a number of work arounds that are easy for a power user to support, but should NOT be the default setup or config required for new users. Eg: brew also provides an installer for apple-gcc42 and you could then point your ghc settings file to. That said, it's not a solution we probably want to encourage by default, it definitely took me a while to cook up sane directions, and some of those directions/approaches apparently become useless if you update to OS X 10.9. (I think partly because the default C++ std libs on Mac shift, so you can't easily build GCC on mavericks currently allegedly ) On Monday, October 14, 2013, Edward Kmett wrote: > As I do most of my development on a Mac I confess I currently live in fear > of accidentally clicking on the XCode 5 upgrade button and winding up in an > unsupported configuration. That makes me very leery of option C, where > developers like me are treading on egg-shells around system updates for the > next 6 months. > > -Edward > > > > On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner > 'mark.lentcz...@gmail.com');> > > wrote: > >> It wasn't my intention to open up the whole question of scheduled >> releases. HP has a regular release schedule, and there were many good >> discussions leading up to it. As for the timing of those releases, last >> time we looked into this there was no good release time that worked for all >> the common Linux distro's release schedules. Perhaps GNOME has figured this >> one out - they release stable end of September and end of March. We could >> aim to glide toward that. >> >> Back to this release: >> >> GHC 7.8 won't be ready for inclusion in an HP for quite some time. We >> haven't even seen the first release yet! If it has stabilized by end of >> February, then it could make it into the next HP (assuming we don't move >> the schedule up to match GNOME). But I think realistically, one shouldn't >> expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If >> the community wants to see closer tracking, then we probably need to start >> talking about a different way of producing GHC - with both stable and >> experimental releases happening... when this idea has been raised in the >> past, GHC central hasn't had the person-power to do it.]* >> * >> * >> The next Mac OS X is indeed right around the corner (no official date >> from Apple, just "this Autumn") - the GM release candidate of both OS X >> Mavericks and Xcode 5 are already in developers (and my) hands. My >> understanding is that current HP just won't work on it - which means we >> really should get something out to support it. >> >> SO, back to concrete ideas: >> >> *A) Minor release* >> >> *• Minor rev:* since GHC and most packages haven't changed, and we won't >> be adding anything, just roll it as normal now. >> *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC >> 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 >> >> *—or—* >> *B) Delay release* >> >> *• New packages:* running the normal process, just a month late >> >> *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is >> needed to support Xcode 5 >> >> *—or—* >> *C) Skip a release* >> >> *• Go for 7.8:* push everyone (GHC central, library maintainers) to get >> 7.8 stable ASAP >> >> *• Big Push for Packages:* use the time to push for a significant >> increase in the packages in the Platform >> >> *• Release in March: *aiming to sync with GNOME, assuming they're on to >> something! >> >> >> As attractive as some aspects of C are, it leaves anyone with a Mac out >> in the cold for six months: They either can't upgrade, or can't Haskell. >> >> A requires duplicate effort (mostly on my part), but is otherwise >> mechanical... and not that exciting. >> >> B deviates from our schedule, but if GHC can roll a 7.6.4, might get us >> an HP with some new packages. >> >> — Mark >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
It's worth noting that it's possible to have a working setup with Xcode 5, it just requires having your own additional build of GCC locally (indeed, that's my current setup), though this will likely have crazy linker errors if I'm not careful :-) when linking a c++ lib built with clang. On Monday, October 14, 2013, Edward Kmett wrote: > As I do most of my development on a Mac I confess I currently live in fear > of accidentally clicking on the XCode 5 upgrade button and winding up in an > unsupported configuration. That makes me very leery of option C, where > developers like me are treading on egg-shells around system updates for the > next 6 months. > > -Edward > > > > On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner > 'mark.lentcz...@gmail.com');> > > wrote: > >> It wasn't my intention to open up the whole question of scheduled >> releases. HP has a regular release schedule, and there were many good >> discussions leading up to it. As for the timing of those releases, last >> time we looked into this there was no good release time that worked for all >> the common Linux distro's release schedules. Perhaps GNOME has figured this >> one out - they release stable end of September and end of March. We could >> aim to glide toward that. >> >> Back to this release: >> >> GHC 7.8 won't be ready for inclusion in an HP for quite some time. We >> haven't even seen the first release yet! If it has stabilized by end of >> February, then it could make it into the next HP (assuming we don't move >> the schedule up to match GNOME). But I think realistically, one shouldn't >> expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If >> the community wants to see closer tracking, then we probably need to start >> talking about a different way of producing GHC - with both stable and >> experimental releases happening... when this idea has been raised in the >> past, GHC central hasn't had the person-power to do it.]* >> * >> * >> The next Mac OS X is indeed right around the corner (no official date >> from Apple, just "this Autumn") - the GM release candidate of both OS X >> Mavericks and Xcode 5 are already in developers (and my) hands. My >> understanding is that current HP just won't work on it - which means we >> really should get something out to support it. >> >> SO, back to concrete ideas: >> >> *A) Minor release* >> >> *• Minor rev:* since GHC and most packages haven't changed, and we won't >> be adding anything, just roll it as normal now. >> *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC >> 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 >> >> *—or—* >> *B) Delay release* >> >> *• New packages:* running the normal process, just a month late >> >> *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is >> needed to support Xcode 5 >> >> *—or—* >> *C) Skip a release* >> >> *• Go for 7.8:* push everyone (GHC central, library maintainers) to get >> 7.8 stable ASAP >> >> *• Big Push for Packages:* use the time to push for a significant >> increase in the packages in the Platform >> >> *• Release in March: *aiming to sync with GNOME, assuming they're on to >> something! >> >> >> As attractive as some aspects of C are, it leaves anyone with a Mac out >> in the cold for six months: They either can't upgrade, or can't Haskell. >> >> A requires duplicate effort (mostly on my part), but is otherwise >> mechanical... and not that exciting. >> >> B deviates from our schedule, but if GHC can roll a 7.6.4, might get us >> an HP with some new packages. >> >> — Mark >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the next 6 months. -Edward On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner wrote: > It wasn't my intention to open up the whole question of scheduled > releases. HP has a regular release schedule, and there were many good > discussions leading up to it. As for the timing of those releases, last > time we looked into this there was no good release time that worked for all > the common Linux distro's release schedules. Perhaps GNOME has figured this > one out - they release stable end of September and end of March. We could > aim to glide toward that. > > Back to this release: > > GHC 7.8 won't be ready for inclusion in an HP for quite some time. We > haven't even seen the first release yet! If it has stabilized by end of > February, then it could make it into the next HP (assuming we don't move > the schedule up to match GNOME). But I think realistically, one shouldn't > expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If > the community wants to see closer tracking, then we probably need to start > talking about a different way of producing GHC - with both stable and > experimental releases happening... when this idea has been raised in the > past, GHC central hasn't had the person-power to do it.]* > * > * > The next Mac OS X is indeed right around the corner (no official date from > Apple, just "this Autumn") - the GM release candidate of both OS X > Mavericks and Xcode 5 are already in developers (and my) hands. My > understanding is that current HP just won't work on it - which means we > really should get something out to support it. > > SO, back to concrete ideas: > > *A) Minor release* > > *• Minor rev:* since GHC and most packages haven't changed, and we won't > be adding anything, just roll it as normal now. > *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC > 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 > > *—or—* > *B) Delay release* > > *• New packages:* running the normal process, just a month late > > *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is > needed to support Xcode 5 > > *—or—* > *C) Skip a release* > > *• Go for 7.8:* push everyone (GHC central, library maintainers) to get > 7.8 stable ASAP > > *• Big Push for Packages:* use the time to push for a significant > increase in the packages in the Platform > > *• Release in March: *aiming to sync with GNOME, assuming they're on to > something! > > > As attractive as some aspects of C are, it leaves anyone with a Mac out in > the cold for six months: They either can't upgrade, or can't Haskell. > > A requires duplicate effort (mostly on my part), but is otherwise > mechanical... and not that exciting. > > B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an > HP with some new packages. > > — Mark > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
good to know! (i'm out of date on my python knowledge) I think we're getting pretty far afield. speaking as someone who's played "OS X support guru/*grunt*" for people dealing with GHC 7.6 + xcode 5 quite a bit for the past 2-5 months, I don't care about what the release is, as long as we clearly communicate to people 1) xcode 5 + ghc 7.6.3 have issues which require menial intervention and following directions to fix (I even sent out an email giving direction http://www.haskell.org/pipermail/haskell-cafe/2013-September/110320.html ). The directions i listed don't cover every *correct* way to work around the issues, they merely list the solutions that are easy to communicate and follow. 2) how to cope while we get a patched ghc/HP ready (by following directions) 3) get a patched GHC/HP out. nearly every day I'm helping someone on IRC deal with this issue, and I strongly suspect that thats the tip of the iceberg. We need to have clear information / warning to people who are installing 7.6 ghc or current haskell platform on OS X about this issue, if we fail to make information about these issues available to new users, some will just give up on bizarre CPP errors and move on. Which i consider unacceptable :) I don't care what solution we do, just that we fix this issue proactively. while we prep to sort this out, can we at least more clearly link to this issues information on the GHC / HP download pages? I'm really really really really tired of playing support on this issue after a few months of it it stopped being fun a month ago when it started happening to people who can't patch their own GHC. We need to deal with this. Also i'm a bit buried with my own stuff this month so i'm worried some people wont' get helped! -Carter On Mon, Oct 14, 2013 at 2:55 AM, Bob Ippolito wrote: > On Monday, October 14, 2013, Dag Odenhall wrote: > >> On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery >> wrote: >> >> Nope. Arch is a rolling release distribution whose policy is directly >>> opposed to the "stable release" philosophy of the Platform. They will >>> package latest versions of everything, not a "stable release". You *cannot* >>> satisfy their requirements with the Platform; ignore them. >> >> I would say it depends on what you mean by “latest”, since one answer >> could be “latest haskell-platform”. Does Arch Linux ship the latest Python >> packages, even if an older version is included in the stdlib of the latest >> Python release? >> > There isn't a separate "Python" and "Python Platform". Packages that ship > with Python are maintained in Python's repository. Those that are > also maintained separately usually have another package/module name > altogether so both can be installed without interfering with one another. > > -bob > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
