Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
* Jose A. Ortega Ruiz j...@gnu.org [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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11 2011, Roman Cheplyaka wrote: * Jose A. Ortega Ruiz j...@gnu.org [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. Thanks for your suggestion. Yes, that's what i was thinking of doing; but i wanted to know before that if there might be reasons for people not being able or not wanting to use parsec 3 (in which case i might try to rewrite the parsing code using parsec 2-compatible calls, assuming there's a compatibility layer in parsec 3). Cheers, jao -- One reason that life is complex is that it has a real part and an imaginary part. -Andrew Koenig ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
2011/12/10 Jose A. Ortega Ruiz j...@gnu.org I'm happy to announce the release of xmobar 0.14. Xmobar is a text-based, minimalistic status bar for linuxy systems, written in Haskell. See http://projects.haskell.org/xmobar for details. Many, many thanks to the many, many contributors, and apologies for taking so long to put their code and fixes under a new release. In this episode: _New features_ - New brightness monitor, courtesy of Martin Perner. - New DateZone plugin, for configurable timezone and localized datetimes, also by Martin. - New keyboard layout monitor (Kbd). Yes, by Martin. - Rewrite of the event handling ([issue 53], [issue 57]), you guessed it. - Cpu monitor now also reports `iowait` field ([issue 55]). - Battery monitor: the full charge file is now settable in the monitor arguments (olpc systems use `charge_full_design`; see [issue 62]). _Bug fixes_ - [issue 45]: Fix for crashes with AC status changes in battery monitor. - [issue 48]: The quality field of Wireless behaves like a percentage. - [issue 50]/[issue 61]: `MPD` monitor now works with libmpd 0.6. - [issue 60]: Fixes for crashes on power resume for battery monitor. - Template sections without fields are now correctly displayed. - Catch errors when reading battery status (Ben Boeckel). - Compilation issues with ghc 7.x (Sergei Trofimovich). - Fixes for CoreTemp monitor in new kernels (Norbert Zeh). - Fix for pulseaudio problems in volume monitor (Martin Perner). - Fix for parsing errors when a `Run` entry ended in an array (Martin). - Fixed compilation in OpenBSD (Ivo van der Sangen). [issue 45]: http://code.google.com/p/xmobar/issues/detail?id=45 [issue 48]: http://code.google.com/p/xmobar/issues/detail?id=48 [issue 50]: http://code.google.com/p/xmobar/issues/detail?id=50 [issue 53]: http://code.google.com/p/xmobar/issues/detail?id=53 [issue 55]: http://code.google.com/p/xmobar/issues/detail?id=55 [issue 57]: http://code.google.com/p/xmobar/issues/detail?id=57 [issue 60]: http://code.google.com/p/xmobar/issues/detail?id=60 [issue 61]: http://code.google.com/p/xmobar/issues/detail?id=61 [issue 62]: http://code.google.com/p/xmobar/issues/detail?id=62 Cheers, jao ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi. I am Awesome WM user thinking about swithcing to the xmonad. Could I take an opportunity and ask about mouse support in xmonad/xmobar ? Actually, I assume that xmobar does nothing with mouse, but what is a common way of showing something like main menu to the user? Is there an option of switching windows with mouse by pressing on some window's icon, just like common DE does? -- Thanks, Sergey. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
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. 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
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11, 2011 at 05:09:44PM +0400, Sergey Mironov wrote: Hi. I am Awesome WM user thinking about swithcing to the xmonad. Could I take an opportunity and ask about mouse support in xmonad/xmobar ? Actually, I assume that xmobar does nothing with mouse, but what is a common way of showing something like main menu to the user? Is there an option of switching windows with mouse by pressing on some window's icon, just like common DE does? Yes, see http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html xmonad itself does not provide something which the user can click on to switch windows, but if you use some other window-switcher program (e.g. one that comes with your favorite DE) the above module can be used to make xmonad to respond to it. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11, 2011 at 8:48 AM, Peter Simons sim...@cryp.to 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Dec 10, 2011 at 18:25, Peter Simons sim...@cryp.to 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11, 2011 at 10:44, Antoine Latter aslat...@gmail.com wrote: On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Dec 10, 2011 at 18:25, Peter Simons sim...@cryp.to 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. 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11, 2011 at 10:10 AM, Brandon Allbery allber...@gmail.com wrote: On Sun, Dec 11, 2011 at 10:44, Antoine Latter aslat...@gmail.com wrote: On Sat, Dec 10, 2011 at 5:31 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Dec 10, 2011 at 18:25, Peter Simons sim...@cryp.to 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11, 2011 at 10:23 AM, Antoine Latter aslat...@gmail.com wrote: 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 :-) Okay, I just wasn't reading closely enough. We generalized the type of 'notFollowedBy' in parsec-3 - the generalization isn't parsec-3 specific at all, it just hadn't been done yet. The intent of the compatibility module was to supply backwards compatibility - I never thought about the problems of forward compatibility. Maybe some warning or deprecation pragmas are in order. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
Hi Antoine, What errors are you getting compiling with GHC 6.10.4? If its a small thing I certainly don't mind patching things. I am sorry, my previous statement was inaccurate. Parsec 3.1.2 compiles fine, but the 'text' library -- on which Parsec depends -- does not. We can probably avoid that issue by downgrading text to version 0.11.0.6 for GHC 6.10.4, which builds fine. It's not a pretty solution, but it seems to work fine. So, the good news is that we now have Parsec 3 available for GHC 6.10.4 in NixOS after all. :-) Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
I'm happy to announce the release of xmobar 0.14. Xmobar is a text-based, minimalistic status bar for linuxy systems, written in Haskell. See http://projects.haskell.org/xmobar for details. Many, many thanks to the many, many contributors, and apologies for taking so long to put their code and fixes under a new release. In this episode: _New features_ - New brightness monitor, courtesy of Martin Perner. - New DateZone plugin, for configurable timezone and localized datetimes, also by Martin. - New keyboard layout monitor (Kbd). Yes, by Martin. - Rewrite of the event handling ([issue 53], [issue 57]), you guessed it. - Cpu monitor now also reports `iowait` field ([issue 55]). - Battery monitor: the full charge file is now settable in the monitor arguments (olpc systems use `charge_full_design`; see [issue 62]). _Bug fixes_ - [issue 45]: Fix for crashes with AC status changes in battery monitor. - [issue 48]: The quality field of Wireless behaves like a percentage. - [issue 50]/[issue 61]: `MPD` monitor now works with libmpd 0.6. - [issue 60]: Fixes for crashes on power resume for battery monitor. - Template sections without fields are now correctly displayed. - Catch errors when reading battery status (Ben Boeckel). - Compilation issues with ghc 7.x (Sergei Trofimovich). - Fixes for CoreTemp monitor in new kernels (Norbert Zeh). - Fix for pulseaudio problems in volume monitor (Martin Perner). - Fix for parsing errors when a `Run` entry ended in an array (Martin). - Fixed compilation in OpenBSD (Ivo van der Sangen). [issue 45]: http://code.google.com/p/xmobar/issues/detail?id=45 [issue 48]: http://code.google.com/p/xmobar/issues/detail?id=48 [issue 50]: http://code.google.com/p/xmobar/issues/detail?id=50 [issue 53]: http://code.google.com/p/xmobar/issues/detail?id=53 [issue 55]: http://code.google.com/p/xmobar/issues/detail?id=55 [issue 57]: http://code.google.com/p/xmobar/issues/detail?id=57 [issue 60]: http://code.google.com/p/xmobar/issues/detail?id=60 [issue 61]: http://code.google.com/p/xmobar/issues/detail?id=61 [issue 62]: http://code.google.com/p/xmobar/issues/detail?id=62 Cheers, jao ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
Hi Jose, I'm happy to announce the release of xmobar 0.14. 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 The complete log is at http://hydra.nixos.org/build/1603134/nixlog/1/raw, just in case there happens to be an easy fix for that error. Thank you very much for your efforts! Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sat, Dec 10, 2011 at 18:25, Peter Simons sim...@cryp.to 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
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? Cheers, jao -- Life isn't about finding yourself. Life is about creating yourself. -George Bernard Shaw, writer, Nobel laureate (1856-1950) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
