[jgm@berkeley.edu: Re: Pandoc restriction for Parsec <3]
The main user of parsec -- pandoc -- is *not* going to move to parsec 3,
since it is twice as slow.
That means that neither is the Haskell Platform
That means that we should downgrade to parsec 2 on arch and *not move to
parsec 3 for the foreseeable future*.
-- Don
----- Forwarded message from John MacFarlane
Hi John,
Suppose you're using pandoc in a web app that delivers up hundreds of pages, some quite long.
if you do that, Pandoc is a mission-critical component in your setup and it's fine to dedicate extra effort to, say, building it with Parsec 2. For occasional users like me, however, the difference in performance is hardly measurable.
Well, if you don't want your software to work on ArchLinux, then this is the way to go. It's your choice.
It's not my fault that it doesn't work on Arch.
Of course it is. You deliver a cabal file that refuses to build Pandoc with Parsec 3, even though it would build just fine! Who else do you think should be responsible for that?
Anyway, I have found a solution that should work. I'll fix Pandoc's Cabal file and upload that version to Hackage calling it, say open-pandoc. The automatic cabal2arch converter will make that package available in ArchLinux within a couple of days, and then everything will be fine.
Take care, Peter
----- End forwarded message -----
On 16/02/10 01:09, Don Stewart wrote:
The main user of parsec -- pandoc -- is *not* going to move to parsec 3, since it is twice as slow.
That means that neither is the Haskell Platform
That means that we should downgrade to parsec 2 on arch and *not move to parsec 3 for the foreseeable future*.
Is there any plan to still provide parsec 3 in Arch? As we all know, GHC is capable of having several versions of one package installed. Pacman needs separate names for the packages, but that feels like a minor issue. The only issue I see is with cabal2arch (since we want it as automated as possible). Can cabal2arch handle it? A possibly naive idea would be the following: - pacman package "parsec" is parsec 2 - pacman package "parsec3" is parsec 3 - cabal2arch maps dependencies on "parsec >2" to "parsec3", and all other to "parsec" /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
magnus:
On 16/02/10 01:09, Don Stewart wrote:
The main user of parsec -- pandoc -- is *not* going to move to parsec 3, since it is twice as slow.
That means that neither is the Haskell Platform
That means that we should downgrade to parsec 2 on arch and *not move to parsec 3 for the foreseeable future*.
Is there any plan to still provide parsec 3 in Arch?
I think if we can convince vegai to move haskell-parsec to parsec 2, then we can add special support for parsec 3. Then add support to cabal2arch to substitute. -- Don
On Tue, Feb 16, 2010 at 19:13, Don Stewart
magnus:
On 16/02/10 01:09, Don Stewart wrote:
The main user of parsec -- pandoc -- is *not* going to move to parsec 3, since it is twice as slow.
That means that neither is the Haskell Platform
That means that we should downgrade to parsec 2 on arch and *not move to parsec 3 for the foreseeable future*.
Is there any plan to still provide parsec 3 in Arch?
I think if we can convince vegai to move haskell-parsec to parsec 2, then we can add special support for parsec 3.
Then add support to cabal2arch to substitute.
That would be excellent. Does anyone know if the speed issues in parsec 3 are inherent in the algorithms used, or if a bit of profiling and optimisation will bring it to par with parsec 2? (I'll take my answer in the form of a link to a discussion on haskell-cafe if possible ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
participants (2)
-
Don Stewart -
Magnus Therning