likewise! just having that precise tagged info for how to pick a stable
code state for ghc + associated libraries even if it wasn't a full dev
preview release would make me a lot less conservative about using HEAD ghc
more often / even as my default
On Wed, Mar 20, 2013 at 9:57 PM, Conrad Parker
On Thu, Mar 21, 2013 at 10:21:25AM +0800, John Lato wrote:
What would be ideal would be if this library API freeze coincided with
the snapshot (odd-numbered) release.
I was only thinking of about a 2 week period, and only on the stable
branch. Freezing the library APIs in HEAD after a
, and on future release plans in general. We've looked at all the
responses, and we think that the best plan is to continue to make major
releases annually, with minor patch-level releases between them.
Additionally, we may recommend particular snapshots, and provide binary
builds for all tier-1
Ian Lynagh i...@well-typed.com writes:
Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
one.
I think that could very useful, sort of like what the Linux kernel did before
they stopped.
I'm never sure if building from HEAD will produce a compiler I should use for
A 7.7 snapshot would be useful for me in a number of ways:
a) I often spend some time prior to recent GHC releases trying to build all
the various major packages, and often send in patches to maintainers
during that window (or at least the start of patches). Having a fixed
snapshot release that
Hello,
I think that there are a lot of useful features that are in HEAD that would
be useful to a wider audience than GHC devs, so a release before October
would certainly be useful. I don't think it is that important if it is
called 7.7.1 or 7.8.1 but I think that it needs to be a fixed
We've had long discussions about snapshot releases, and the tricky part
is that while we would like people to be able to try out new GHC
features, we don't want to add to the burden of library maintainers by
requiring them to update their libraries to work with a new GHC release
more than once a
On 20 March 2013 18:58, John Wiegley jo...@fpcomplete.com wrote:
Ian Lynagh i...@well-typed.com writes:
Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
one.
I think that could very useful, sort of like what the Linux kernel did before
they stopped.
I'm never sure
On Thu, Mar 21, 2013 at 8:08 AM, Ian Lynagh i...@well-typed.com wrote:
We've had long discussions about snapshot releases, and the tricky part
is that while we would like people to be able to try out new GHC
features, we don't want to add to the burden of library maintainers by
requiring
Hi all,
Thank you to everyone who gave us feedback on when we should release
7.8.1, and on future release plans in general. We've looked at all the
responses, and we think that the best plan is to continue to make major
releases annually, with minor patch-level releases between them
Hi all,
Just a quick note to let you know about our release plans:
We plan to put out a GHC 7.4.2 release candidate around the end of the
March. The final release will probably not happen until around the end
of April.
Thanks
Ian, on behalf of the GHC team
On Thu, Mar 22, 2012 at 6:49 AM, Ian Lynagh ig...@earth.li wrote:
Hi all,
Just a quick note to let you know about our release plans:
We plan to put out a GHC 7.4.2 release candidate around the end of the
March. The final release will probably not happen until around the end
of April
Hi all,
This is just to let you know our plans for the first release of the
up-coming 6.8 branch (which will be called 6.8.1).
We are aiming to have a release candidate by the end of August, with all
the high priority bugs milestoned for 6.8 fixed:
David Waern wrote:
Here's a quick summary of the major developments that we already have in
the 6.8 codebase:
- Associated data types, and the new FC intermediate language
- GHCi debugger (although there's an overhaul of the breakpoint support
almost
ready to go in)
- Coverage (HPC)
- GADTs +
Here's a quick summary of the major developments that we already have in
the 6.8 codebase:
- Associated data types, and the new FC intermediate language
- GHCi debugger (although there's an overhaul of the breakpoint support
almost
ready to go in)
- Coverage (HPC)
- GADTs + typeclasses
] On
| Behalf Of Neil Mitchell
| Sent: 17 April 2007 18:16
| To: Simon Marlow
| Cc: GHC Users Mailing List
| Subject: Re: Release plans
|
| Hi
|
| Release plans:
| - get external core working again
|
| Can't this happen entirely separate from any GHC releases? From what
| I've heard people were thinking
| What are the plans for the esc branch?
|
| Are the changing going to be merged?
(For others, Rene is referring to extended static checking for Haskell; see
http://www.cl.cam.ac.uk/~nx200/)
Dana is working hard on it right now. Yes, I very much hope that it'll be
merged back into the HEAD in
Sending to the right list this time, with some additions.
Just to show what kind of problems we are currently facing. The
following type checks in our EHC compiler and in Hugs, but not in the
GHC:
module Test where
data T s = forall x. T (s - (x - s) - (x, s, Int))
run :: (forall
it.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-
[EMAIL PROTECTED] On
| Behalf Of Neil Mitchell
| Sent: 17 April 2007 18:16
| To: Simon Marlow
| Cc: GHC Users Mailing List
| Subject: Re: Release plans
|
| Hi
|
| Release plans:
| - get external core working again
: Re: Release plans
|
| On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote:
| We'd like to solicit comments from the community on our plans for future
| GHC releases. The current situation is this:
|
| - 6.6.1 is nearly ready to go (perhaps this week, please test the RC!)
| - 6.6.2
Alfonso Acosta wrote:
On 4/16/07, Simon Marlow [EMAIL PROTECTED] wrote:
Are there features/bug-fixes that you really
want to see in 6.8?
How about dynamic libraries? (there are a few 6.8 tickets for that I think)
I'm not sure if this will be ready for 6.8, but of course if it is then it'll
Stefan O'Rear wrote:
What do you think of this plan? Are there features/bug-fixes that you
really want to see in 6.8?
Good code generation for loops. I understand they are rare in
practice, but it's kinda disheartening to write memset() and see in
the asm loop 11 memory references, 9 to the
| - left-to-right impredicative instantiation: runST $ foo
|
| This concerns me. With each ad-hoc extension of the type system, I
| worry that soon the GHC type system will become so byzantine and
| ill-specified that the type checker can only be cloned, not
| substantially improved on
On this
Just to show what kind of problems we are currently facing. The
following type checks in our EHC compiler and in Hugs, but not in the
GHC:
module Test where
data T s = forall x. T (s - (x - s) - (x, s, Int))
run :: (forall s . T s) - Int
run ts = case ts of
T g - let (x,_, b)
| Just to show what kind of problems we are currently facing. The
| following type checks in our EHC compiler and in Hugs, but not in the
| GHC:
|
| module Test where
|
| data T s = forall x. T (s - (x - s) - (x, s, Int))
|
| run :: (forall s . T s) - Int
| run ts = case ts of
| T g
| Yes, but where is it written that what cannot be expressed in system-
| F is type incorrect? We think it is still type safe, and it is an
| extrcat of a larger program that is quite useful (if we managed to
| compile it),
Indeed! Well-typed programs don't go wrong, but not every program that
Doaitse Swierstra wrote:
Just to show what kind of problems we are currently facing. The
following type checks in our EHC compiler and in Hugs, but not in the GHC:
module Test where
data T s = forall x. T (s - (x - s) - (x, s, Int))
run :: (forall s . T s) - Int
run ts = case ts of
On Apr 17, 2007, at 2:57 PM, Simon Peyton-Jones wrote:
| Just to show what kind of problems we are currently facing. The
| following type checks in our EHC compiler and in Hugs, but not in
the
| GHC:
|
| module Test where
|
| data T s = forall x. T (s - (x - s) - (x, s, Int))
|
| run ::
Hi
Release plans:
- get external core working again
Can't this happen entirely separate from any GHC releases? From what
I've heard people were thinking of wrapping this up in the next few
months. I personally need this to make my PhD work on more than just
Yhc :-)
Thanks
Neil
On Tue, Apr 17, 2007 at 06:15:49PM +0100, Neil Mitchell wrote:
Release plans:
- get external core working again
Can't this happen entirely separate from any GHC releases?
It will work in the HEAD as soon as it's done, but it won't be in a
released compiler until the release after
What are the plans for the esc branch?
Are the changing going to be merged?
Rene.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi
Release plans:
- get external core working again
Can't this happen entirely separate from any GHC releases?
It will work in the HEAD as soon as it's done, but it won't be in a
released compiler until the release after that.
AFAIWA the library in the past was entirely stand alone
glad someone cares. :)
Aaron
On Apr 17, 2007, at 10:15 AM, Neil Mitchell wrote:
Hi
Release plans:
- get external core working again
Can't this happen entirely separate from any GHC releases? From what
I've heard people were thinking of wrapping this up in the next few
months. I personally
Well, the work I'm doing on it right now includes modifying it to
work with System FC, which means it won't work with 6.6.
Aaron
On Apr 17, 2007, at 10:54 AM, Neil Mitchell wrote:
Hi
Release plans:
- get external core working again
Can't this happen entirely separate from any GHC
We'd like to solicit comments from the community on our plans for future GHC
releases. The current situation is this:
- 6.6.1 is nearly ready to go (perhaps this week, please test the RC!)
- 6.6.2 has ~35 outstanding tickets
- 6.8 has ~150 outstanding tickets
the default option would be to
On 4/16/07, Simon Marlow [EMAIL PROTECTED] wrote:
What do you think of this plan? Are there features/bug-fixes that you really
want to see in 6.8?
I'd rather see ghc 6.8 out early.
What about the implementation of associated/indexed type _synonyms_?
Cheers,
JP.
| What about the implementation of associated/indexed type _synonyms_?
working on it now. I v much hope it'll make the 6.8 release, but I don't want
to hold it up for that. Almost certainly *some* variant of indexed type
synonyms will be in though.
Simon
On 4/16/07, Simon Marlow [EMAIL PROTECTED] wrote:
Are there features/bug-fixes that you really
want to see in 6.8?
How about dynamic libraries? (there are a few 6.8 tickets for that I think)
___
Glasgow-haskell-users mailing list
On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote:
We'd like to solicit comments from the community on our plans for future
GHC releases. The current situation is this:
- 6.6.1 is nearly ready to go (perhaps this week, please test the RC!)
- 6.6.2 has ~35 outstanding tickets
I vote for 6.8.
Rene.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Mon, Apr 16, 2007 at 10:00:32AM -0700, David Roundy wrote:
Could you summarize the major tickets for 6.6.2?
The list milestoned or 6.6.2 is here:
http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedmilestone=6.6.2order=priority
Not all of them would
simonmarhaskell:
We'd like to solicit comments from the community on our plans for future
GHC releases. The current situation is this:
- 6.6.1 is nearly ready to go (perhaps this week, please test the RC!)
- 6.6.2 has ~35 outstanding tickets
- 6.8 has ~150 outstanding tickets
the
On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote:
- left-to-right impredicative instantiation: runST $ foo
This concerns me. With each ad-hoc extension of the type system, I
worry that soon the GHC type system will become so byzantine and
ill-specified that the type checker can only
On Apr 16, 2007, at 15:54 , Simon Marlow wrote:
- left-to-right impredicative instantiation: runST $ foo
Is this really a good idea? This will just make people complain that
€ (x € f = f x) doesn't work when you do foo € runST (or maybe it
does?).
-- Lennart
Duncan Coutts wrote:
Chris Parrott found that ghc-6.4.1 doesn't work with gcc 4.1 on amd64,
although it does work on x86.
The error manifests itself as link errors due to undefined symbols:
/var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o):(.data+0x48):
undefined
On Tue, 21 Mar 2006 23:31:34 +
Duncan Coutts [EMAIL PROTECTED] wrote:
Chris found that the problem is that gcc 4.1 is noticing that
StgRunIsImplementedInAssembler is not actually used anywhere. It is in
inline assembly in StgRunIsImplementedInAssembler that the global
symbols StgRun and
On 18 March 2006 18:32, Ian Lynagh wrote:
On Wed, Mar 15, 2006 at 04:24:14PM +, Simon Marlow wrote:
If you have anything else for 6.4.2, please let me know.
Just a small thing, but it looks like, while the HEAD has been changed
to send --help output to stdout, ghc-6.4.2.20060316 still
On Wed, Mar 15, 2006 at 04:24:14PM +, Simon Marlow wrote:
If you have anything else for 6.4.2, please let me know.
Just a small thing, but it looks like, while the HEAD has been changed
to send --help output to stdout, ghc-6.4.2.20060316 still has the
following in
Hi Folks,
This is a heads up for the forthcoming 6.4.2 release. Our rough
timescale is to go into release candidate testing in about a week, and
have two weeks of release candidates before the final release.
Here are the things we know about and plan to fix before the release:
On Wed, 2006-03-15 at 16:24 +, Simon Marlow wrote:
Hi Folks,
This is a heads up for the forthcoming 6.4.2 release. Our rough
timescale is to go into release candidate testing in about a week, and
have two weeks of release candidates before the final release.
Here are the things we
Simon Marlow wrote:
Hi Folks,
This is a heads up for the forthcoming 6.4.2 release. Our rough
timescale is to go into release candidate testing in about a week, and
have two weeks of release candidates before the final release.
Here are the things we know about and plan to fix before the
On 20 July 2004 01:43, Bernie Pope wrote:
Since you are working on the backend is there any chance that GHC
could support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be happy with a flag, such as '-debug-symbols' or somesuch,
that keeps source
On Tue, Jul 20, 2004 at 09:29:38AM +0100, Simon Marlow wrote:
On 20 July 2004 01:43, Bernie Pope wrote:
Since you are working on the backend is there any chance that GHC
could support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be happy
I'd like to see us support more debugging
information, preferably in a way that can be stripped from a binary.
The easy way would be as .stabs entries since that's what gdb uses.
However, stabs entries themselves are absolutely horrible (the design
obviously started simple and acquired a
This message is to keep everyone updated on our future release plans.
We are currently planning two new releases around the end of August: one
from the STABLE branch and one from the HEAD.
STABLE: 6.2.2
-
This will be the final release from the 6.2 branch, containing bugfixes
only
On 19 July 2004 14:20, Shae Matijs Erisson wrote:
- generalised algebraic data types (currently in development, might
not make it into the release).
What does this mean exactly?
http://research.microsoft.com/Users/simonpj/papers/gadt/index.htm
Ian Lynagh has built ghc-cvs debs, is
Simon Marlow [EMAIL PROTECTED] writes:
- completely new back-end (post-STG) based on a C-- intermediate
language, including a largely rewritten native code generator.
I'm looking forward to this.
- generalised algebraic data types (currently in development, might
not make it
Feedback welcome as usual - I've probably forgotten lots of stuff on
these lists.
Cheers,
Simon
Hi Simon,
Since you are working on the backend is there any chance that GHC could
support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be happy
58 matches
Mail list logo
