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
[Haskell-cafe] Hardware description in Haskell.
I would like to introduce my over-than-two years long project, HHDL: http://thesz.mskhug.ru/svn/hhdl/hackage/hhdl/ (I prefer to pronounce it as a ha-ha-dee-el, this way it is more fun) It allows one to create digital hardware description in Haskell and then generate VHDL code (Verilog is on the way). Okay, it would allow one to do all that some day. I hope it will come sooner than later. I try to make all wires as typed as I can and to support algebraic types with patetrn matching. I wrote a simple example to demonstrate some of those facilities: http://thesz.mskhug.ru/svn/hhdl/hackage/hhdl/src/Hardware/HHDL/Examples/RunningSumMaybes.hs This is a simple accumulator that accepts a Maybe Word8 input. The resulting VHDL is very wordy, but looks superficially correct. I wrote two posts about HHDL: http://thesz.livejournal.com/1284055.html - slightly outdated as HHDL now generates VHDL that typechecks and allows one to name inputs and outputs http://thesz.livejournal.com/1284541.html - motivation behind HHDL There is no package for Hackage, because I do not feel HHDL is worth it right now. For example, I tested it on ghc 6.12.1, not later versions, the library code is messy. But HHDL is good enough for some scrutiny and critique by Haskell users who is into hardware description. ___ 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] Hardware description in Haskell.
On Sun, Dec 11, 2011 at 10:52 AM, Serguey Zefirov sergu...@gmail.com wrote: There is no package for Hackage, because I do not feel HHDL is worth it right now. For example, I tested it on ghc 6.12.1, not later versions, the library code is messy. But HHDL is good enough for some scrutiny and critique by Haskell users who is into hardware description. A two years-old project is more than ready to be on Hackage. It will sure make it easier to use by prospective users. Cheers, -- Felipe. ___ 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] HaXml 1.13 - 1.22 upgrade
On 12/11/2011 01:36 AM, Antoine Latter wrote: It looks like the function 'xmlParse' returns a value of type 'Document Posn', according to the API docs. I'm guessing the 'Posn' value is used to annotate the position in the source document a particular piece of XML came from, so you can report errors better. Since the pretty-printing functions ignore it, you can replace it with whatever you want, even with a value of a different type if you have a need to annotate the tree. Thanks, I was able to get it working after a little sleep/coffee. The migration guide says to replace all of the 'i' with () if you don't care about them, so I tried that, but it doesn't work in this case: the two 'i' in (CElem (Element i) i) have to match. The only way I see to construct a Posn is with noPos, so I stuck that in there. It's probably not correct, but it compiles and runs, so it's correct =) ___ 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] Haskell Summers of Code retrospective (updated for 2011)
I would be interested in what the hold-up is with the two Cabal projects. Does the work need more clean-up or is it just stuck in the Duncan-code-review pipeline? If Duncan is indeed the bottleneck, maybe we should look into ways of taking some of the work off Duncan. On 11 December 2011 02:57, Gwern Branwen gwe...@gmail.com wrote: The Wheel turns, and months come and pass, leaving blog posts that fade into 404s; a wind rose in Mountain View, whispering of the coming Winter... Tonight I sat down and finally looked into the 2011 SoCs to see how they turned out and judge them according to my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-1 They turned out pretty much as I predicted - but then I *would* say that, wouldn't I? (Also submitted to /r/haskell for those who swing that way: http://www.reddit.com/r/haskell/comments/n82ln/summer_of_code_2011_retrospective/ ) -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ 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] Tracing Prelude.read exceptions
Hi, I got quite used to a sequence providing simple data persistence : 1) Store my data to a file: writeFile fileName (show someData) 2) Some time later read this data back: line - readFile fileName let someData = read line :: SomeDataType Having this done hundreds of times I now got stuck with step 2) trying to read moderately complex structure back. I get read exception in run-time: fromList *** Exception: Prelude.read: no parse I have checked and rechecked my types, data files, etc. - and still no idea. So my question: Is there any way to trace Prelude.read exceptions to see exactly on what data element read fails in run-time? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No instance for (Read POSIXTime)
dokondr wrote: When I try to read POSIXTime... No instance for (Read POSIXTime)... What should I do to provide Read instance for POSIXTime? Short answer: if you are thinking about this as a moment in time that could be parsed from the usual kind of string representation for that, you probably want to use UTCTime in your data type, not POSIXTime. If you really, really want to represent it internally as POSIXTime, then you should read those strings as UTCTime and then convert them to POSIXTime to store in your data type. I.e., in that case don't make your data type an instance of Read. POSIXTime is just a type alias for NominalDiffTime, i.e., a quantity of time between two moments. This is what the Show instance looks like: Prelude Data.Time realToFrac 100 :: NominalDiffTime 100s By convention, the Read instance would expect a string in that format. Generally people aren't interested in that, so there is no Read instance. Even if you did want to parse that, you would just parse it as a number and then use realToFrac, as I did above. The rule of thumb is: always represent moments in time as a UTCTime. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tracing Prelude.read exceptions
On Sun, Dec 11, 2011 at 4:19 PM, dokondr doko...@gmail.com wrote: Hi, I got quite used to a sequence providing simple data persistence : 1) Store my data to a file: writeFile fileName (show someData) 2) Some time later read this data back: line - readFile fileName let someData = read line :: SomeDataType I can't help you with your question, but I suggest using safecopy [1] even for simple cases. It's *much* faster and also safer. Also, it's easy to use, just use L.writeFile fileName $ S.runPutLazy $ safePut someData and ret - S.runGetLazy safeGet $ L.readFile fileName case ret of Left err - print err Right someData - ... where import Control.Applicative (($)) import qualified Data.ByteString.Lazy as L -- [2] import qualified Data.Serialize.Get as S -- [3] import qualified Data.Serialize.Put as S -- [4] Cheers, [1] http://hackage.haskell.org/package/safecopy [2] http://hackage.haskell.org/packages/archive/bytestring/0.9.2.0/doc/html/Data-ByteString-Lazy.html [3] http://hackage.haskell.org/packages/archive/cereal/0.3.4.0/doc/html/Data-Serialize-Get.html [4] http://hackage.haskell.org/packages/archive/cereal/0.3.4.0/doc/html/Data-Serialize-Put.html -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work? (palindrome :: IO)
Brandon Allbery wrote: case () of () | s == reverse s - putStrLn palindrome _ - putStrLn nope Tom Murphy wrote: This is kind of a hack of case, though. I think what the OP was looking for is isPalindrome word | (word == reverse word) = putStrLn (word ++ is a palindrome) | otherwise = putStrLn (word ++ is not a palindrome) Erm? It's as much of a hack of case as yours is, since the above is actually using case. I agree with Tom here. While it's true that the compiler internally desugars to case, that low-level compiler transformation doesn't have much to do with the best way to write clear code. I find that case often creates code that is more confusing and bug-prone. Except when what I really want to express is pattern matching, *and* there is some specific reason here why I don't want to use a named function in a let or where binding. Altogether, it doesn't come up very often for me. And even for styles that use case more than I do, certainly there is room to call the use of the case () idiom a hack. (Even though I'll admit that I do use it sometimes.) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No instance for (Read POSIXTime)
Yitz, thanks for the detailed answer! May be I should have formulated my question differently. All I actually need is some way to get *seconds* since epoch from the system, so I could manipulate them as integers. Correct me if I am wrong, but UTCTime does not help here. The only way I found to get seconds form epoch using existing today GHC libraries is that: utcStr = Wed, 07 Dec 2011 10:10:05 + posixSecondsIntg = read posixSecondsStr :: Integer posixSecondsStr = init $ show (cvtUTCtoSec utcStr) -- throw away 's' from posix seconds string, s\ uch as 1235657s cvtUTCtoSec utcTimeStr = utcTimeToPOSIXSeconds utcTime where utcTime = fromJust $ tryParseTime utcTimeStr timeFormat1 = %a, %d %b %Y %T %z timeFormat2 = %m/%e/%Y %l:%M:%S %p tryParseTime :: String - Maybe UTCTime tryParseTime timeStr = tryFormat (parseTime defaultTimeLocale timeFormat1 timeStr :: Maybe UTCTime) where tryFormat time | time == Nothing = parseTime defaultTimeLocale timeFormat2 timeStr :: Maybe UTCTime | otherwise = time Not a very easy way, isn't it? On Sun, Dec 11, 2011 at 9:22 PM, Yitzchak Gale g...@sefer.org wrote: dokondr wrote: When I try to read POSIXTime... No instance for (Read POSIXTime)... What should I do to provide Read instance for POSIXTime? Short answer: if you are thinking about this as a moment in time that could be parsed from the usual kind of string representation for that, you probably want to use UTCTime in your data type, not POSIXTime. If you really, really want to represent it internally as POSIXTime, then you should read those strings as UTCTime and then convert them to POSIXTime to store in your data type. I.e., in that case don't make your data type an instance of Read. POSIXTime is just a type alias for NominalDiffTime, i.e., a quantity of time between two moments. This is what the Show instance looks like: Prelude Data.Time realToFrac 100 :: NominalDiffTime 100s By convention, the Read instance would expect a string in that format. Generally people aren't interested in that, so there is no Read instance. Even if you did want to parse that, you would just parse it as a number and then use realToFrac, as I did above. The rule of thumb is: always represent moments in time as a UTCTime. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hardware description in Haskell.
2011/12/11 Felipe Almeida Lessa felipe.le...@gmail.com: On Sun, Dec 11, 2011 at 10:52 AM, Serguey Zefirov sergu...@gmail.com wrote: scrutiny and critique by Haskell users who is into hardware description. A two years-old project is more than ready to be on Hackage. It will sure make it easier to use by prospective users. This is two-years-long project, not two-years-old. It is only days old, it became useful this day, actually. I have two points in my TODO list. When I finish them I'll do a package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 10th Ghent Functional Programming Group Meeting on Thursday, December 15, 2011 at 19h30
Dear All, We would like to remind you of the 10th Ghent Functional Programming Group (GhentFPG) meeting, which will take place this Thursday, December 15, 2011, at 19h30 in the Technicum building of Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent). This meeting, we will focus on tackling some interesting problems with the elegance of functional programming. We will try to post the problems to this mailing list at least two days in advance. As with the previous meeting, the meeting room is still unreachable through the regular building entrance because of construction works. Hence, attendees need to take the alternative side entrance. This entrance can be found on the right side (as seen from the street) of the building -- it will remain open until 20:00. If you walk up to the Technicum building and go right at the bicycle stands, you should see “Ingang Blok 1 Blok 2” indicated. Follow this, and you’ll be able to get inside, at which point you’ll see arrows pointing to the meeting room. For safety measures the blue doors will be locked, so if you arrive after 19:30, please give us a call at +32 (0) 9 264 3370, so we can come and open the doors for you. P.S. we would also like to remind you that you are all certainly welcome at the talk about Real-World Functional Programming @ Incubaid, organized by Tom Schrijvers for his course on Functional Logic Programming at Ghent University. For more details see [1]. [1]: https://groups.google.com/d/topic/ghent-fpg/csUnMX08WKc/discussion Hope to see you then! The GhentFPG Organizing Committee. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Sharing a room for the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL?
Hi, I will attend the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL next year, and will have to share a room with another attendee. As we can give preferences, I was wondering if another Haskeller might be in the same position and interested in sharing a room. Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: smallcheck-0.6; test-framework-smallcheck-0.1
I'm pleased to announce a new release of SmallCheck. The highlights for this release are: * Default Generic implementation of Serial instance, contributed by Bas van Dijk This means that you don't need to write instances by hand for your types to generate test values for them. See [1] for the details. [1]: http://hackage.haskell.org/packages/archive/smallcheck/0.6/doc/html/Test-SmallCheck-Series.html#g:5 * Revised, organised into modules and documented API * Integration with test-framework, through test-framework-smallcheck package It allows to organize SmallCheck properties into a test suite (possibly together with HUnit or QuickCheck tests), apply timeouts, get nice statistics etc. Thanks to Max Bolingbroke for cooperation on this front. Please refer to the README for more information about SmallCheck: https://github.com/feuerbach/smallcheck/blob/master/README.md Hackage links: http://hackage.haskell.org/package/smallcheck-0.6 http://hackage.haskell.org/package/test-framework-smallcheck-0.1 -- 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] Generating Code
It occurs to me that c2hs (or more appropriately the gtk2hsc2hs fork) is intended to solve this problem; have you looked into it? hdirect falls into this category as well ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work? (palindrome :: IO)
To clarify, by hack I meant that it seemed like a workaround specifically to keep case in the OP's code, when it seemed like they were looking for the functionality of guards. amindfv / Tom On Dec 11, 2011 1:39 PM, Yitzchak Gale g...@sefer.org wrote: Brandon Allbery wrote: case () of () | s == reverse s - putStrLn palindrome _ - putStrLn nope Tom Murphy wrote: This is kind of a hack of case, though. I think what the OP was looking for is isPalindrome word | (word == reverse word) = putStrLn (word ++ is a palindrome) | otherwise = putStrLn (word ++ is not a palindrome) Erm? It's as much of a hack of case as yours is, since the above is actually using case. I agree with Tom here. While it's true that the compiler internally desugars to case, that low-level compiler transformation doesn't have much to do with the best way to write clear code. I find that case often creates code that is more confusing and bug-prone. Except when what I really want to express is pattern matching, *and* there is some specific reason here why I don't want to use a named function in a let or where binding. Altogether, it doesn't come up very often for me. And even for styles that use case more than I do, certainly there is room to call the use of the case () idiom a hack. (Even though I'll admit that I do use it sometimes.) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
On 12/7/11 10:21 AM, Henrik Nilsson wrote: I also had a look at John Millikin's page on Understanding Iteratees, which is very good: https://john-millikin.com/articles/understanding-iteratees/ But, the intuition that comes across there is: * iteratee: a stream (of sorts) consumer * enumerator: a stream (of sorts) producer * enumeratee: a stream (of sorts) transformer And iterator isn't mentioned at all. The iterator terminology is from the object-oriented world; iteratees are explicitly offered as an alternative to the iterator approach, which is why we don't have iterators. An iterator is something which iterates over a collection--- to produce the elements in that collection. In the iterator approach the sink (the for-loop) is in charge and it pulls the data from the source (the iterator). The problem, of course, is that the source never knows whether the sink will pull the next element or not, so it never knows when it's done. An iteratee is also something which iterates over a collection--- to consume the elements in that collection. In the iteratee approach the source (the enumerator) is in charge and it pushes the data into the sink (the iteratee) until the sink declares that it's had enough! and then the source knows it's done and it can free whatever resources need freeing. So there are actually two issues going on here: one is the source-vs-sink distinction, and the other is the active-vs-passive or push-vs-pull distinction. Since we have two binary features, we can have them be aligned in parallel or in opposition (which one is which is irrelevant). iterator-style --- source : sink :: passive : active iterator = passive source for-loop = active sink (pull) iteratee-style --- source : sink :: active : passive enumerator = active source (push) iteratee = passive sink The enumeratee terminology comes from a pun about something which is both an enumerat(or) and also an (iterat)ee. However, it would have been much clearer IMO if instead we had used this terminology retroactively as a name for the for-loop or other active sink in the iterator style. If this had been done, then we could use the following analysis: iterat- = passive enumerat- = active -or = source -ee = sink Which preserves the analogy you want. Employers are the source of employment, and employees are the sinks/consumers of employment. To make sense of the active-vs-passive distinction, rather than thinking about the employers as the ones being active (i.e., thinking of employment as the commodity), we could instead choose to frame our discourse around workers as the source of work (i.e., thinking of labor as the commodity). In this case we would expect workees to be the consumers of work/labor; but, alas, we have no word for rendering employers as passive participants in the world of economic transactions. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recommended class instances for container type
On 12/8/11 11:12 AM, Christoph Breitkopf wrote: Hello, I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...). And what about the more experimental things? Say, DeepSeq, Typeable, Data? I'd like to keep this simple at start, and I've admittedly not followed recent developments in Haskell-land (recent meaning the last 10 years or so. I _do_ know about hierachical modules ;-) ). I don't use Typeable or Data, but there are a lot of folks who do, and they seem pretty well entrenched in GHC-standard Haskell. Not sure about non-GHC compiler support. For a container datatype, I'd consider Foldable and Traversable to be essential (provided that they're actually implementable). These classes are widely used and so they offer a nice standard set of names for common operations. But more than just having a common set of names, implementing these classes ensures a minimum level of completeness for your API--- and that's the essential part. Functor, Applicative, and Monad are also good to offer whenever possible. Functor is required/implied by Foldable and Traversable. Applicative and Monad just give a nice clean interface--- though you should beware of whether there are multiple law-abiding implementations for these two classes. If there are, then you'll have to worry about which one you offer by default (if any) as well as how people can access the other ones. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Splitting off many/some from Alternative
Hey everyone, I am sure that it is too late to do more than idly speculate about this, but could we split the some/many methods out from Alternative? They simply don't make sense except in a subset of possible Alternatives --- in most cases they just result in an infinite loop. That is to say, it is not just that they are extraneous functionality, but most of the time they are *impossible* functionality to even implement! In a way, it is a lie to be including them in Alternative since people making use of the class might incorrectly (but quite reasonably!) assume that any type that is an instance of Alternative *has* a well-defined some and many method, when this is actually the exception rather than the rule. It is only recently that I have been able to grok what some and many are even about (I think), and they seem to only make sense in cases where executing the Alternative action results in a portion of some input being consumed or not consumed. some v means consume at least one v and return the list of items consumed or fail, and many v means consume zero or more v and return the list of items consumed or the empty list of none are consume. It thus makes sense for there to be some subclass of Alternative called something like Consumptive that contains these methods. The majority of Alternative instances would no longer have these methods, and again that would actually be an improvement since in such cases some/many were unworkable and did nothing but cause infinite loops anyway. Normally it would be unthinkable to even consider such a change to the base libraries, but I suspect that there are not more than a couple of packages out there that make active use of the some/many instances of Alternative; it is really only parser packages that need some/many, and users most likely use the versions included with the packages themselves rather than the Alternative version. Could we verify that this is the case, and if so split them away? I thought I heard a trick whereby people were able to grep all the source on Hackage, but I can't remember what it was. :-) Just a thought. :-) Thanks, Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting off many/some from Alternative
On Mon, Dec 12, 2011 at 00:18, Gregory Crosswhite gcrosswh...@gmail.comwrote: It is only recently that I have been able to grok what some and many are even about (I think), and they seem to only make sense in cases where executing the Alternative action results in a portion of some input being consumed or not consumed. some v means consume at least one v and return the list of items consumed or fail, and many v means consume zero or more v and return the list of items consumed or the empty list of none are consume. It thus makes sense for there to be some subclass of Alternative called something like Consumptive that contains these methods. Parsive? I think the only reason they're in there is that Applicative and Alternative came about via experimentation with parsing (Applicative started its pre-ghc life as a parser combinator library). -- 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] HaXml 1.13 - 1.22 upgrade
The extra parameter i is for information attached to each node of the tree. As you have correctly guessed, the parser fills in this field with positional information relating to the original source document, which is useful for instance if you are validating or checking the original document. When building new parts of a document, it is perfectly fine to attach noPos. You can alternatively replace all of the informational items in the tree, with for instance fmap (const ()) if you don't care about them. The information fields are useful for other purposes though, e.g. to hold the relevant xmlns namespace for subtrees; or to distinguish added/removed/modified subtrees in a diff-like viewer. Regards, Malcolm On 11/12/2011, at 14:56, Michael Orlitzky mich...@orlitzky.com wrote: On 12/11/2011 01:36 AM, Antoine Latter wrote: It looks like the function 'xmlParse' returns a value of type 'Document Posn', according to the API docs. I'm guessing the 'Posn' value is used to annotate the position in the source document a particular piece of XML came from, so you can report errors better. Since the pretty-printing functions ignore it, you can replace it with whatever you want, even with a value of a different type if you have a need to annotate the tree. Thanks, I was able to get it working after a little sleep/coffee. The migration guide says to replace all of the 'i' with () if you don't care about them, so I tried that, but it doesn't work in this case: the two 'i' in (CElem (Element i) i) have to match. The only way I see to construct a Posn is with noPos, so I stuck that in there. It's probably not correct, but it compiles and runs, so it's correct =) ___ 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] Tracing Prelude.read exceptions
I suggest switching from 'read' to a real parser that can give you proper error messages. I use Text.Parse from the polyparse package, which is designed to parse back exactly the format produced by derived Show instances. To derive the Parse class from your datatypes, the tool DRiFT is handy. 'runParser parse' will give you Either String a, where the string contains any error message. Regards, Malcolm On 11/12/2011, at 18:19, dokondr doko...@gmail.com wrote: Hi, I got quite used to a sequence providing simple data persistence : 1) Store my data to a file: writeFile fileName (show someData) 2) Some time later read this data back: line - readFile fileName let someData = read line :: SomeDataType Having this done hundreds of times I now got stuck with step 2) trying to read moderately complex structure back. I get read exception in run-time: fromList *** Exception: Prelude.read: no parse I have checked and rechecked my types, data files, etc. - and still no idea. So my question: Is there any way to trace Prelude.read exceptions to see exactly on what data element read fails in run-time? Thanks! ___ 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
