On Thu, 2013-03-21 at 12:16 +, Ian Lynagh wrote:
> 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
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 sna
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 Parke
On Thu, Mar 21, 2013 at 8:08 AM, Ian Lynagh 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 them to update the
On 20 March 2013 18:58, John Wiegley wrote:
>> Ian Lynagh 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 wi
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 y
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 version,
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 m
> Ian Lynagh 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
getting real work
Hi Ian,
I think it would make sense to post this on haskell-cafe. I think we can expect
larger response
from there than from glasgow-haskell-users.
Janek
Dnia wtorek, 19 marca 2013, Ian Lynagh napisał:
> Hi all,
>
> Thank you to everyone who gave us feedback on when we should release
> 7.8.1,
On Mon, 2008-03-10 at 08:23 +, Neil Mitchell wrote:
> Hi
>
> > You could still have a cabal-install binary in the Windows installer and
> > not include the Cabal-1.4.x library that you built it against.
>
> That sounds easiest, and should give all the cabal-install benefits to
> Windows us
Hi
> You could still have a cabal-install binary in the Windows installer and
> not include the Cabal-1.4.x library that you built it against.
That sounds easiest, and should give all the cabal-install benefits to
Windows users.
> Alternatively it'd be possible to include Cabal-1.4.x too and
On Sun, 2008-03-09 at 23:32 +, Neil Mitchell wrote:
> Hi
>
> > First, we intend to release the next version of GHC from the current
> > stable branch, 6.8.3, around the end of May 2008. This will probably be
> > the last release from this branch.
>
> Is it possible to include the cabal-in
Hi
> First, we intend to release the next version of GHC from the current
> stable branch, 6.8.3, around the end of May 2008. This will probably be
> the last release from this branch.
Is it possible to include the cabal-install tool with this release, in
the Windows installer?
The cabal-inst
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 + type
ask him to prioritise 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:
| > -
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
| 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 i
TECTED] 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
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
It is still coming along! :)
I'm frustrated with how slowly I've been progressing with it (even
though I do have good reasons), but I'm not stopping, and I believe
it will be ready for 6.8.
Knowing that you're waiting for it definitely gives me some
motivation to push harder on it. I'm gl
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,
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
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 tha
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
__
| 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 n
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 :: (
| 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
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 =
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,_,
| > - 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
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
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
: 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, p
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
___
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
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
>
>
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=new&status=assigned&status=reopened&milestone=6.6.2&order=priority
Not all of them would neces
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 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 ticke
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
Glasgow-haskell-use
| 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:
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.
___
> 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 bun
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 wou
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 so
> 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 ha
"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
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
50 matches
Mail list logo
