Re: Release plans
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 wrote: > 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 will produce a compiler I should > use for > > getting real work done, but I wouldn't have the same reservations > concerning a > > 7.7.x "interim developer release". > > likewise. > > I'd be happy with just a git tag and an email to this list every month > or two indicating that there's a probably-ok version that could do > with some testing. This could happen whenever a feature lands and the > dust has settled a bit. > > Conrad. > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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 their libraries to work with a new GHC release > more than once a year. > > But perhaps we should announce a "library API freeze" some time before > the first RC on a stable branch. That way people can safely update their > dependencies at that point, and by the time the RC is out people testing > the RC will be able to test more without running into problems > installing libraries. > What would be ideal would be if this "library API freeze" coincided with the snapshot (odd-numbered) release. Then library maintainers would only have to update once, and hopefully many of them would have their updates available before ghc's stable release. John L. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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 will produce a compiler I should use for > getting real work done, but I wouldn't have the same reservations concerning a > 7.7.x "interim developer release". likewise. I'd be happy with just a git tag and an email to this list every month or two indicating that there's a probably-ok version that could do with some testing. This could happen whenever a feature lands and the dust has settled a bit. Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi David, On Tue, Jan 22, 2013 at 09:39:40PM -0800, David Terei wrote: > > This bug is still present in mainline. Any chance of it being fixed? I've just built HEAD with 7.6.2, so I think this has been fixed. If not, please give me more details on how to reproduce it. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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 year. The impression that I have from the responses so far is that most people who would like a snapshot release want to use it as their regular compiler, which will probably mean they want to use other libraries with it, which in turn will probably mean changes to libraries are needed (even if only bumping version bounds). It's therefore likely to mean more work for library maintainers (even if it's only checking and applying patches, it's still work). On Wed, Mar 20, 2013 at 01:23:04PM -0400, Carter Schonwald wrote: > > 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 maintainers can use to validate any such future > proofing patches would be tremendously helpful Thank you for doing this, but doing it for snapshot releases too would probably double the work most maintainers need to do. But perhaps we should announce a "library API freeze" some time before the first RC on a stable branch. That way people can safely update their dependencies at that point, and by the time the RC is out people testing the RC will be able to test more without running into problems installing libraries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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, in the sense that all code (including GHC libraries) is tagged in the repos and, possibly, we make an entry for it in the track system, so that people can record bugs against it. Given that GHC is very actively developed, it might make sense to have one of these "snapshot" releases every 3 or so months, as "technology preview", and without any promises about stability or compatibility (in particular, they should not be considered for inclusion in the HP or standard Linux distributions). This would give us a fairly low over-head middle ground between the volatility of nightly builds, and the long time between official releases. -Iavor On Wed, Mar 20, 2013 at 10:23 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > 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 maintainers can use to validate any such future > proofing patches would be tremendously helpful > > b) Theres a bunch of engineering i'm currently up where I want to use some > of the features very soon, and making it easier for other people to use the > open source subsets of that engineering sooner rather than later would be > valuable! > > c) lowering the barrier to folks using and stress testing these features > may catch problems sooner. > > note: i'm ok with compiling ghc from source, but many people who might be > happy to test those new features might find that a bit daunting the first > time. > > cheers > -Carter > > > On Wed, Mar 20, 2013 at 6:58 AM, 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 will produce a compiler I should use >> for >> getting real work done, but I wouldn't have the same reservations >> concerning a >> 7.7.x "interim developer release". >> >> -- >> John Wiegley >> FP Complete Haskell tools, training and consulting >> http://fpcomplete.com johnw on #haskell/irc.freenode.net >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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 maintainers can use to validate any such future proofing patches would be tremendously helpful b) Theres a bunch of engineering i'm currently up where I want to use some of the features very soon, and making it easier for other people to use the open source subsets of that engineering sooner rather than later would be valuable! c) lowering the barrier to folks using and stress testing these features may catch problems sooner. note: i'm ok with compiling ghc from source, but many people who might be happy to test those new features might find that a bit daunting the first time. cheers -Carter On Wed, Mar 20, 2013 at 6:58 AM, 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 will produce a compiler I should use > for > getting real work done, but I wouldn't have the same reservations > concerning a > 7.7.x "interim developer release". > > -- > John Wiegley > FP Complete Haskell tools, training and consulting > http://fpcomplete.com johnw on #haskell/irc.freenode.net > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
> 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 done, but I wouldn't have the same reservations concerning a 7.7.x "interim developer release". -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Polymorphic implicit parameters
I'm curious as to why GHC doesn't accept the following (contrived)
module:
{-# LANGUAGE ImplicitParams, RankNTypes #-}
f :: (?g :: (forall a . a -> a)) => a -> a
f = ?g
The error message is:
Illegal polymorphic or qualified type: forall a. a -> a
In the type signature for `f':
f :: ?g :: (forall a. a -> a) => a -> a
It's not a big deal since one can wrap the polymorphism in a newtype,
but it's somewhat unexpected.
Roman
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
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, 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 platforms, for people who wish to test new > features etc in HEAD. > > There is more detail on how all this will work here: > http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases > > > > We will therefore aim for a 7.8.1 release in October. We do not > currently expect to make a 7.6.3 release, although that may > change if serious bugs in 7.6.2 are discovered. > > > Would a 7.7.x recommended snapshot be useful to you? Tell us if you > want one. Compared to 7.6 it would contain: > * polykinded Typeable library > * major improvements in DPH (vectorisation avoidance, new vectoriser) > * type holes > * rebindable list syntax > * major changes to the type inference engine > * type level natural numbers > * overlapping type families > * the new code generator > * support for vector (SSE/AVX) instructions > * Scheduler changes to the RTS to improve latency > Is it worth us putting out a preview, or are you happy to work from > the nightly snapshots and wait for the full release in October? > > > Thanks > Ian > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC 7.8 make targeting bare metal ARM any easier?
kiwamu has been targeting an arm cortex-m3 succesfully with jhc. this is a CPU with 40k of RAM running Haskell code very much on bare metal. :) John On Tue, Mar 19, 2013 at 6:07 PM, Jeremy Shaw wrote: > There have been at least a couple projects, such as hOp and HaLVM > which attempt to run GHC on the bare metal or something similar. > > Both these projects required a substantial set of patches against GHC > to remove dependencies things like POSIX/libc. Due to the highly > invasive nature, they are also highly prone to bitrot. > > With GHC 7.8, I believe we will be able to cross-compile to the > Raspberry Pi platform. But, what really appeals to me is going that > extra step and avoiding the OS entirely and running on the bare metal. > Obviously, you give up a lot -- such as drivers, network stacks, etc. > But, there is also a lot of potential to do neat things, and not have > to worry about properly shutting down an embedded linux box. > > Also, since the raspberry pi is a very limited, uniform platform, > (compared to general purpose PCs) it is feasible to create network > drivers, etc, because only one chipset needs to be supported. > (Ignoring issues regarding binary blobs, undocumented chipsets, usb > WIFI, etc). > > I'm wondering if things are any easier with cross-compilation support > improving. My thought is that less of GHC needs to be tweaked? > > - jeremy > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC 7.8 make targeting bare metal ARM any easier?
Hello Jeremy, I'd also like to see GHC compiling for ARM bare metal. Honestly speaking I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: BeagleBone is excellent for this as you get all the TI supported tools together with JTAG debugging just for free from TI (including ARM compilers if you care about this) and also you get full documentation for its Sitara 335x SoC. Anyway, back to the GHC topic. I find it too invasive to go straight from POSIX/libc dependency to nothing on bare-metal. Instead of this while analyzing the situation for myself I've rather settled on POSIX RTOS which is much less weight that general purpose Linux distro and yet it provides a lot of API which makes GHC RTS porting work much easier. So as my hobby time permits I'm working on GHC port to RTEMS[1] which is a single-process, multi-threaded RTOS with POSIX API supported. On its devel mailing list you may find that Raspberry Pi BSP was already submitted for inclusion. Generally speaking, I also hope that since this work is much less invasive on GHC, it has higher chance of a merge into GHC HEAD once ready... Cheers, Karel [1]: http://www.rtems.org/ On 03/20/13 02:07 AM, Jeremy Shaw wrote: There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
