Re: Wither Haskell Platform 2013.4.0.0
On Monday, October 14, 2013, Dag Odenhall wrote:
On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery
allber...@gmail.comjavascript:_e({}, 'cvml', 'allber...@gmail.com');
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
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 mark.lentcz...@gmail.comwrote: 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.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml', '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
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.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml', '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
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 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
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: 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 nicolas.fri...@gmail.comwrote: 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 rrnew...@gmail.com 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 drei...@gmail.comwrote: Hi, On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall dag.odenh...@gmail.comwrote: 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 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 rrnew...@gmail.com 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 nicolas.fri...@gmail.com 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 rrnew...@gmail.com 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 drei...@gmail.comwrote: Hi, On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall dag.odenh...@gmail.comwrote: 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: 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 ekm...@gmail.com 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 ekm...@gmail.com 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
