dependencies, and possibly even the
> X server itself, defeating the whole purpose of having a headless server.
>
> Thanks,
> Yitz
>
>
> On Sun, Nov 17, 2013 at 9:55 PM, Mark Lentczner
> wrote:
>> Here is the current status of the 2013.4.0.0 proposal.
>>
>>
install a boatload of X server dependencies, and possibly even the
X server itself, defeating the whole purpose of having a headless server.
Thanks,
Yitz
On Sun, Nov 17, 2013 at 9:55 PM, Mark Lentczner
wrote:
> Here is the current status of the 2013.4.0.0 proposal.
>
> Outstanding Issues
&g
On Tue, Nov 26, 2013 at 8:50 AM, Stijn van Drongelen wrote:
> I'm probably missing something here, but is `containers` not part of HP?
>
Yes - it is, but it is part of the set of packages that come with GHC,
hence I didn't list it by itself.
Those packages are: array, base, bytestring, Cabal, con
I don't think there is an issue with building GHC: If you build GHC from
source for packaging, it will build and use the version of the Cabal
package that it is shipped with. This will put Cabal-1.16 in the package
database. If you then build all the packages in the platform, that will
build Cabal
On Tue, Nov 26, 2013 at 9:18 AM, Carter Schonwald
wrote:
> or just build ghc with the 1.18 cabal and keep it all the same :)
That's what I'd like to avoid.
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
ghc doesn't actually depend on anything in the cabal api, merely ghc and
cabal share some bits related to manipulating the package data base (I
forget the details). So should be completely straightforward to do a test
build with 1.18 instead
On Tue, Nov 26, 2013 at 3:25 AM, Jens Petersen
wrote:
On 26 November 2013 17:18, Carter Schonwald wrote:
> or just build ghc with the 1.18 cabal and keep it all the same :)
>
Has it been tried? :)
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/ma
On 26 November 2013 17:08, Ivan Lazar Miljenovic
wrote:
> No, but if the binary installers auto-hide 1.16, then there will be a
> difference between the various platforms.
True, though Linux distros could update their ghc packages to hide
their Cabal library I suppose if necessary...
(I am kind
or just build ghc with the 1.18 cabal and keep it all the same :)
On Tue, Nov 26, 2013 at 3:08 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:
> On 26 November 2013 18:04, Mikhail Glushenkov
> wrote:
> > Hi,
> >
> > On Tue, Nov 26, 2013 at 7:28 AM, Ivan Lazar Miljenovic
> > wrote
Hi,
On Tue, Nov 26, 2013 at 7:28 AM, Ivan Lazar Miljenovic
wrote:
> Hurt, no; but it will make it inconsistent across platforms (as Linux
> distros typically just have meta-packages for the Platform, rather
> than an installer that can do this).
>
You mean that Linux distros will have both 1.18
Hi Mark,
On Sun, Nov 17, 2013 at 8:55 PM, Mark Lentczner
wrote:
> Here is the current status of the 2013.4.0.0 proposal.
>
> [...]
>
> Cabal:
> Cabal: 1.16.0 → 1.18.1.2 consensus seems to be that this will be
> okay
Will it be fine to include both versions of Cab
good point, pardon any confusion.
On Mon, Nov 18, 2013 at 12:49 AM, Mark Lentczner
wrote:
> On Sun, Nov 17, 2013 at 12:25 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> There's currently an issue with Alex happy when they're built with clang
>> cpp rather Than GCC cpp which som
On Sun, Nov 17, 2013 at 12:25 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> There's currently an issue with Alex happy when they're built with clang
> cpp rather Than GCC cpp which some folks are trying to hammer out I think.
> I think it's a problem in Alex 3.1.2 but not 3.1.0.
S
o
> build ghc 7.8 would be a nice thing to have.
>
>
> On Sunday, November 17, 2013, Mark Lentczner wrote:
>
>> Here is the current status of the 2013.4.0.0 proposal.
>>
>> *Outstanding Issues*
>> We have a few decisions outstanding, and I'd like to have th
a fresher Alex / happy so that Haskell platform can be used to build
ghc 7.8 would be a nice thing to have.
On Sunday, November 17, 2013, Mark Lentczner wrote:
> Here is the current status of the 2013.4.0.0 proposal.
>
> *Outstanding Issues*
> We have a few decisions outstanding,
Here is the current status of the 2013.4.0.0 proposal.
*Outstanding Issues*
We have a few decisions outstanding, and I'd like to have these decided by
Nov. 23 (one week).
- fgl - waiting to hear if Ivan will have new version ready in time.
- aeson / dlist - there are serveral op
On Thu, Nov 14, 2013 at 9:50 AM, Sean Leather wrote:
> But at the moment, to avoid unnecessary controversy and to give the new
> code some time to mature, I recommend that dlist is *not* added to the
> platform.
>
Code isn't wine -- there are quantitative metrics you can gather (like HPC
test cov
On 2013-11-14 09:50, Sean Leather wrote:
> I think it might be better to continue the dlist discussion on a separate
> thread. For a recap, see below.
[--snip--]
> But at the moment, to avoid unnecessary controversy and to give the new
> code some time to mature, I recommend that dlist is *not* add
I think it might be better to continue the dlist discussion on a separate
thread. For a recap, see below.
As I've just taken over maintenance and development of dlist (and nobody
seems to be complaining, yet, so I guess I'll just continue with it), I've
looked through the code and thought about th
On 13 Nov 2013 20:33, "Mark Lentczner" wrote:
>
> I'd like to better understand the backwards compatibility of these
changes, and this new major bump of aeson:
My idea for the new major release aeson-0.7 was that it would be included
in the next HP and introduce breaking changes but that it would
Re dlist
The platform hasn't been aiming for "small and focused" for quite some
time. And last year I called for a significant expansion of the palatform,
and this was met with general enthusiasm. The original motto for the
platform: "batteries included" is still apt.
We want to the platform to p
On Tue, Nov 12, 2013 at 12:21 AM, Ganesh Sittampalam wrote:
> FYI I've just uploaded HTTP 4000.2.9 which just has some dependency bumps.
Okay, I'll bump to this version.
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://pro
I'd like to better understand the backwards compatibility of these changes,
and this new major bump of aeson:
On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk wrote:
> Note that I removed the blaze-builder requirement from aeson-HEAD (it
> now uses the Builder from bytestring with a fallback to bl
On 13 Nov 2013 18:53, "Joachim Breitner" wrote:
>
> Hi,
>
> Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk:
> > On 10 November 2013 22:40, Mark Lentczner
wrote:
> > > Including aeson, which I think we'd all very much like to do, requires
> > > dlist-0.5.
> > > Now, dlist has been a
Hi,
Am Dienstag, den 12.11.2013, 09:26 +0100 schrieb Bas van Dijk:
> On 10 November 2013 22:40, Mark Lentczner wrote:
> > Including aeson, which I think we'd all very much like to do, requires
> > dlist-0.5.
> > Now, dlist has been around for a very long time, and is very stable.
> > I do not bel
On 12 November 2013 11:47, Sean Leather wrote:
> Assuming Don is willing and others agree, I don't mind taking over
> maintenance of dlist. I just imported it into GitHub:
> https://github.com/spl/dlist
Thanks for maintaining it!
> Bas: please submit a pull request with the suggested changes. Th
> On 10 November 2013 22:40, Mark Lentczner
> wrote:
> > Including aeson, which I think we'd all very much like to do, requires
> > dlist-0.5.
> > Now, dlist has been around for a very long time, and is very stable.
> > I do not believe that dlist's API is exposed indirectly via aeson at all.
> >
On 10 November 2013 22:40, Mark Lentczner wrote:
> Including aeson, which I think we'd all very much like to do, requires
> dlist-0.5.
> Now, dlist has been around for a very long time, and is very stable.
> I do not believe that dlist's API is exposed indirectly via aeson at all.
>
> I hereby pro
This is true, and in fact I almost never use dlist myself (or Endo), since
lambdas are already quite light weight.
However, dlist makes the intention explicit, which is probably a good
enough reason to use it in a package in the platform.
On Nov 11, 2013 10:20 AM, "Dag Odenhall" wrote:
> Wouldn’
On Nov 11, 2013 8:43 AM, "Brandon Allbery" wrote:
>
>
> On Mon, Nov 11, 2013 at 3:34 AM, Joachim Breitner <
m...@joachim-breitner.de> wrote:
>>
>> I’d feel more comfortable with this boot-library version deviation if
>> someone who knows the interaction of GHC (the compiler), ghc (the
>> librarY)
On 10 November 2013 23:14, Mark Lentczner wrote:
> I spoke too soon:
>
> aeson induces blaze-builder
Note that I removed the blaze-builder requirement from aeson-HEAD (it
now uses the Builder from bytestring with a fallback to blaze-builder
when configured with -fblaze-builder).
I think we're pr
The case-insensitive bump is good.
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Hi,
Am Sonntag, den 10.11.2013, 08:11 -0800 schrieb Mark Lentczner:
> Cabal:
> The Cabal 1.18 release was a major new release, including the very
> very useful sandbox feature. This would require shipping a different
> Cabal lib than the version shipped with the included GHC. I'm not sure
> of th
Hi,
cabal-install 1.18.0.2 has two critical bugs on Windows.
1. "cabal sdist" command make broken tarball on Windows.
https://github.com/haskell/cabal/issues/1538
2. "cabal update" command broke package index sometimes.
https://twitter.com/xyx_is/status/391944129074044929 (in Japanese)
* The API is actually (a bit) different.
* We weren't planning to offer a compatibility API through bytestring, but
the blaze-builder implementation might be in terms of bytestring.
* The bytestring builder has been out since bytestring-0.10
On Sun, Nov 10, 2013 at 11:49 PM, Mark Lentczner
wrote:
Is the API actually different, or just at a different module location?
In either case, are you planning on exporting a backward compatible
interface for some time from bytestring?
Realize that bytestring comes with GHC, so how long before we're likely to
see this blaze-builder in a release?
- Mar
blaze-builder is a bit troublesome as we've merged that package into
bytestring now and we want users to use that interface.
On Sun, Nov 10, 2013 at 11:14 PM, Mark Lentczner
wrote:
> I spoke too soon:
>
> *aeson* induces *blaze-builder* & *dlist* -- both are pretty long term
> established and st
I spoke too soon:
*aeson* induces *blaze-builder* & *dlist* -- both are pretty long term
established and stable - I say include 'em both.
*cgi* 3001.1.8.4 induces *MonadCatchIO-mtl* & *extensible-exceptions* -
this is more problematic:
- *extensible-exceptions* hasn't been needed since GHC 7,
Fine by me.
On Sun, Nov 10, 2013 at 10:40 PM, Mark Lentczner
wrote:
> Including aeson, which I think we'd all very much like to do, requires
> dlist-0.5.
> Now, dlist has been around for a very long time, and is very stable.
> I do not believe that dlist's API is exposed indirectly via aeson at
Including aeson, which I think we'd all very much like to do, requires
dlist-0.5.
Now, dlist has been around for a very long time, and is very stable.
I do not believe that dlist's API is exposed indirectly via aeson at all.
I hereby propose that it be added to the platform.
At the very least, it
2013/11/10 Mark Lentczner :
> [...] Packages with major version bumps:
> I'd like to get confirmation from the maintainers of these packages that
> this bump is "the right thing to do". The bump should ideally only add API,
> and not orphan any program that used to compile under the HP - at least n
hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't
cause any issues with the one that already comes with GHC.
On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner wrote:
> I know it is late, and so I've done some preliminary version sleuthing
> Here's my proposal for HP 201
I know it is late, and so I've done some preliminary version sleuthing
Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but
hoping to hear from all relevant parties soon.
*GHC 7.6.3* -- this is a compiler bump, but all the included packages
remain at the same version as 201
43 matches
Mail list logo
