On Sat, Dec 10, 2011 at 18:25, Peter Simons wrote:

previous versions of xmobar used to compile fine with GHC 6.10.4, but the new version no longer does:

src/Parsers.hs:163:52: Couldn't match expected type `Char' against inferred type `[Char]' Expected type: GenParser Char st Char Inferred type: GenParser Char st String In the second argument of `($)', namely `wrapSkip $ string "Run"' In a stmt of a 'do' expression: notFollowedBy $ wrapSkip $ string "Run"

xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

* Jose A. Ortega Ruiz [2011-12-11 08:43:01+0100]

On Sun, Dec 11 2011, Brandon Allbery wrote:

[...]

...

xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x.

Aha, thanks for pointing this out, guys.

Peter, would using parsec 3.x be an acceptable solution to you?

To avoid problems like this, please specify version constraints in the .cabal file. See [1] for the details. [1]: http://www.haskell.org/cabal/users-guide/#build-information -- Roman I. Cheplyaka :: http://ro-che.info/

On Sun, Dec 11 2011, Roman Cheplyaka wrote: [...]

To avoid problems like this, please specify version constraints in the .cabal file. See [1] for the details.

I'm actually preparing a new release with stricter version constraints (the new .cabal is https://github.com/jaor/xmobar/blob/master/xmobar.cabal, in case anyone has the time to check whether i'm doing something dumb). It's clear to me what contraints to use for packages not included in ghc, but there're some of them that come with the compiler (unix, time and filepath in my case): what's the best practice regarding those packages? I've left they're version unspecified, intending to mean "whatever version comes with your ghc". Is that a good practice? TIA, jao -- Ignorance more frequently begets confidence than does knowledge - Charles Darwin

On Sun, Dec 11, 2011 at 8:48 AM, Peter Simons wrote:

Hi Jose,

 > Peter, would using parsec 3.x be an acceptable solution to you?

well, we can link xmobar with parsec 3.x on NixOS. The situation is tricky, though, because the latest version of parsec that we have, 3.1.2, doesn't compile with GHC 6.10.4 anymore, so we'd have to use some older version to work around that problem. That kind of setup somewhat complicated to maintain, which is why I would prefer to compile xmobar with parsec 2 2 if at all possible.

Hi Peter, What errors are you getting compiling with GHC 6.10.4? If its a small thing I certainly don't mind patching things.

Generally speaking, though, GHC 6.10.4 support is not a high priority. I just thought it might be worth pointing out that backwards compatibility has been lost in the 0.14 release, because earlier versions worked just fine.

Take care, Peter

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery wrote:

On Sat, Dec 10, 2011 at 18:25, Peter Simons wrote:

...

previous versions of xmobar used to compile fine with GHC 6.10.4, but the new version no longer does:

   src/Parsers.hs:163:52:        Couldn't match expected type `Char' against inferred type `[Char]'          Expected type: GenParser Char st Char          Inferred type: GenParser Char st String        In the second argument of `($)', namely `wrapSkip $ string "Run"'        In a stmt of a 'do' expression:              notFollowedBy $ wrapSkip $ string "Run"

xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x.

It's not clear to me from reading the sources and type signatures of 'notFollowedBy' why this is different in parsec 2 vs. parsec 3. Am I missing something easy? Because if it isn't obvious perhaps it wasn't on purpose. Antoine

On Sun, Dec 11, 2011 at 10:10 AM, Brandon Allbery wrote:

On Sun, Dec 11, 2011 at 10:44, Antoine Latter wrote:

...

On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery wrote:

...

On Sat, Dec 10, 2011 at 18:25, Peter Simons wrote:

...

   src/Parsers.hs:163:52:        Couldn't match expected type `Char' against inferred type `[Char]'

xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x.

It's not clear to me from reading the sources and type signatures of 'notFollowedBy' why this is different in parsec 2 vs. parsec 3.

It's not necessarily going to be visible in individual combinators, as I understand it; the issue is that Parsec2 can really only handle fundamental types such as Char, whereas Parsec3 can handle more complex types.  xmobar appears to be making use of this so its higher level parsing is at the string instead of the character level, factoring out lower level issues to a lower parsing "layer".

All of the imports in the ./src/Parsers.hs are from the Text.ParserCombinators.Parsec.* module space, which was intended to be a compatibility layer, and all of the parsers and parser-combinators in ./ser/Parsers.hs appear to be written using the 'Parser' type synonym, also from the compatibility layer, which has the same token type in both parsec-2.x and parsec-3.x. So after digging deeper I'm even more curious :-)

It's not going to be something easily retrofitted into Parsec2, in any case; Parsec3 needed a fair amount of work to do it to begin with, and even more to make it do so efficiently, which is why Parsec2 remained the default in the 6.12/6.14 days.

-- brandon s allbery                                      allbery.b@gmail.com wandering unix systems administrator (available)     (412) 475-9364 vm/sms