- Haskell-Cafe - Haskell.org

Haskell Platform on Ubuntu: Installation Problems
by Dmitri O.Kondratiev 04 Jul '11

04 Jul '11

Hi, I am trying to install Haskell Platform on latest Ubuntu desktop: ( uname -a: Linux frigate 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux ) I started with installing GHC. Ubuntu could only install version 6.12.3: without Cabal! Now I am trying to install haskell-platform which is a separate package. Ubuntu suggests to insatll version 2010.1.0.0.1 and fails (see bellow). What sould I do now to get GHC + Cabal? Should I: 1) De-insatll GHC 6.12.3 and all related libraries and try then installing Haskell Platform again? 2) Should I install Caball separately and forget about Haskell Platform? 3) Provide somehow for two different installations? Thanks! === Installation errors: This error could be caused by required additional software packages which are missing or not installable. Furthermore there could be a conflict between software packages which are not allowed to be installed at the same time. haskell-platform: Depends: ghc6 (< 6.12.1+) but 6.12.3-1ubuntu7 is to be installed Depends: libghc6-cgi-dev (>= 3001.1.7.2) but 3001.1.7.2-1build1 is to be installed Depends: libghc6-fgl-dev (< 5.4.2.2+) but 5.4.2.2-2build2 is to be installed Depends: libghc6-glut-dev (< 2.1.2.1+) but 2.1.2.1-1build1 is to be installed Depends: libghc6-haskell-src-dev (< 1.0.1.3+) but 1.0.1.3-2build1 is to be installed Depends: libghc6-html-dev (< 1.0.1.2+) but 1.0.1.2-3build2 is to be installed Depends: libghc6-hunit-dev (< 1.2.2.1+) but 1.2.2.1-2build2 is to be installed Depends: libghc6-mtl-dev (< 1.1.0.2+) but 1.1.0.2-10build2 is to be installed Depends: libghc6-network-dev (< 2.2.1.7+) but 2.2.1.7-1build2 is to be installed Depends: libghc6-opengl-dev (< 2.2.3.0+) but 2.2.3.0-2build2 is to be installed Depends: libghc6-parallel-dev (< 2.2.0.1+) but 2.2.0.1-1build1 is to be installed Depends: libghc6-parsec2-dev (< 2.1.0.1+) but 2.1.0.1-2build2 is to be installed Depends: libghc6-quickcheck2-dev (< 2.1.0.3+) but 2.1.0.3-1build2 is to be installed Depends: libghc6-regex-base-dev (< 0.93.1+) but 0.93.1-8build1 is to be installed Depends: libghc6-regex-compat-dev (< 0.92+) but 0.92-6build2 is to be installed Depends: libghc6-regex-posix-dev (< 0.94.1+) but 0.94.1-2build1 is to be installed Depends: libghc6-stm-dev (< 2.1.1.2+) but 2.1.1.2-5build2 is to be installed Depends: libghc6-xhtml-dev (>= 3000.2.0.1) but 3000.2.0.1-6build2 is to be installed Depends: libghc6-zlib-dev (< 0.5.2.0+) but 0.5.2.0-4build2 is to be installed Depends: libghc6-http-dev (>= 40000009) but 40000009-2build1 is to be installed Depends: libghc6-deepseq-dev (< 1.1.0.0+) but 1.1.0.0-2build1 is to be installed Depends: alex (< 2.3.3+) but 2.3.3-1 is to be installed Depends: happy (< 1.18.4-2+) but 1.18.4-2 is to be installed Depends: haddock but it is a virtual package

3 6

IterIO: How to write use my inumReverse
by John Ky 04 Jul '11

04 Jul '11

Hi Haskell Cafe, I've defined the following reverse echo server that echos text back in reverse: module Programs.TcpEchoIterServer where import Control.Concurrent import Control.Exception import Control.Monad import Control.Monad.Trans import Data.IterIO import Data.IterIO.Inum import Network import System.IO import System.IO.Error (isEOFError) import qualified Data.ByteString.Lazy as L import qualified Data.ByteString.Lazy.Char8 as C iterHandle' :: (MonadIO m) => Handle -> IO (Iter L.ByteString m (), Onum L.ByteString m a) iterHandle' = iterHandle main = withSocketsDo $ do sListen <- listenOn (PortNumber 8000) putStrLn "Listening on Port 8000" forkIO $ forever $ do (sSession, hostname, port) <- accept sListen hSetBuffering sSession NoBuffering putStrLn ("Connected to " ++ hostname ++ ":" ++ show port) forkIO $ do (iter, enum) <- iterHandle' sSession enum |$ inumLines .| inumReverse .| inumUnlines .| iter putStrLn "Press <CTRL-D> to quit." exitOnCtrlD iterLines :: (Monad m) => Iter L.ByteString m [L.ByteString] iterLines = do line <- lineI return [line] iterUnlines :: (Monad m) => Iter [L.ByteString] m L.ByteString iterUnlines = (L.concat . (++ [C.pack "\n"])) `liftM` dataI iterReverse :: (Monad m) => Iter [L.ByteString] m [L.ByteString] iterReverse = do lines <- dataI return (map L.reverse lines) inumLines = mkInum iterLines inumUnlines = mkInum iterUnlines inumReverse = mkInum iterReverse exitOnCtrlD = try getLine >>= either (\e -> unless (isEOFError e) $ ioError e) (const exitOnCtrlD) It all works fine. My question is: Is it possible to rewrite inumReverse to be this: iterReverse :: (Monad m) => Iter L.ByteString m L.ByteString iterReverse = do line <- dataI return (L.reverse line) inumReverse = mkInum iterReverse And still be able to use it in the line: enum |$ inumLines .| {-- inumReverse goes in here somehow --} .| inumUnlines .| iter The reason I ask is that the Haskell function reverse has the type [a] -> [a], not [[a]] -> [[a]]. I thought perhaps the alternative inumReverse is cleaner than the original as it behaves more similarly to Haskell's own reverse function. Cheers, -John

2 1

Data.Time
by Tony Morris 04 Jul '11

04 Jul '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recently set out to write a library that required a decent time library. Having only had a flirt with Data.Time previously, I assumed it would be robust like many other haskell libraries. I don't know about consensus, but I have been massively let down. I won't go in to the details, since this is not the point -- I don't wish to complain - -- I wish to get on with it. So, assuming the consensus is in agreement, is there a reasonable alternative to Data.Time (I looked on hackage and nothing seemed to have come close)? Am I wrong in assuming Data.Time is pretty useless? If I am right, and there is no alternative, I see no option but to take an excursion into writing my own. Ultimately, I am just trying to avoid this. Tips welcome. - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Ggx4ACgkQmnpgrYe6r61BRQCfbn+1jqNSjR+lxM+4h3gpvAMM VskAoKxqDCETyVAaOdoYDmFJGz1fOGd/ =IC7O -----END PGP SIGNATURE-----

8 13

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
by Jason Dagit 04 Jul '11

04 Jul '11

On Sun, Jul 3, 2011 at 10:31 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > > On Jul 3, 2011, Jason Dagit <dagitj(a)gmail.com> wrote: >> >> to correctly handle GUI events you need to use the original thread >> allocated to your process to check for events and to call the Cocoa >> framework functionality. >> >> I looked at the threading documentation in Control.Concurrent for GHC and >> it's not clear to me if this is even possible with GHC without restricting >> to the non-threaded RTS. > > The 'main' thread in GHC is the bound thread initially allocated to the > process. That doesn't seem to be the case for GHCI. > You can easily establish an event-loop in the main thread, and feed > events from other threads. Consider using Control.Concurrent.Chan. > If you need feedback, things get a bit trickier because you'll have special > cases based on whether you're starting in the main thread. Yes, that might work for compiled programs. What about GHCI? Jason

1 0

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
by David Barbour 04 Jul '11

04 Jul '11

On Jul 3, 2011, Jason Dagit <dagitj(a)gmail.com> wrote: > to correctly handle GUI events you need to use the original thread > allocated to your process to check for events and to call the Cocoa > framework functionality. > > I looked at the threading documentation in Control.Concurrent for GHC and > it's not clear to me if this is even possible with GHC without restricting > to the non-threaded RTS. > The 'main' thread in GHC is the bound thread initially allocated to the process. You can easily establish an event-loop in the main thread, and feed events from other threads. Consider using Control.Concurrent.Chan. If you need feedback, things get a bit trickier because you'll have special cases based on whether you're starting in the main thread. Regards, Dave

1 0

GUI Program Hangs in GHCI
by Jason Dagit 04 Jul '11

04 Jul '11

Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I found this old email regarding gtk2hs: http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI I recompiled the program to use -threaded but the behavior is unchanged (if the email above describes my problem then I expected the compiled version to start having issues). What else can cause the hangs I'm seeing? I'm using the GLFW-b library on hackage and the program I'm trying to run are any of the executables from the nehe-tuts package (also on hackage). To reproduce my hangs, I think you need OSX (I didn't test this on windows or linux), and then type the following: {{{ mkdir -p ~/tmp/test cd ~/tmp/test cabal update cabal-dev install-deps nehe-tuts cabal unpack nehe-tuts cabal-dev ghci nehe-tuts-0.2.3/lesson01.hs *Main> main }}} Doing a force quit on ghci gives me a stack trace via the OSX crash reporting system. You'll find the relevant bits from that at the end of this email. What debugging techniques do I have at my disposal for figuring out what is going wrong here? At least one person has suggested that possibly ghci and the GUI bits of glfw are competing for input and conflicting with each other. If that's the case, how could I be sure and what would I do about it? Thanks, Jason {{{ Process: ghc [48045] Path: /Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/ghc UID: 502 Thread 84d5f8 DispatchQueue 1 User stack: 47 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a] Kernel stack: 46 semaphore_wait_continue + 0 [0x22a88f] 1 lo_alltraps + 454 [0x2a1976] 1 i386_astintr + 47 [0x2aacb4] 1 ast_taken + 247 [0x219432] 1 bsd_ast + 806 [0x48fea8] 1 postsig + 432 [0x48cfff] 1 exit1 + 449 [0x48187a] 1 task_terminate_internal + 242 [0x22ca4d] 1 ipc_space_destroy + 177 [0x215868] 1 ipc_right_clean + 397 [0x215256] 1 mach_notify_no_senders + 75 [0x23ff7b] 1 mach_msg_send_from_kernel_proper + 90 [0x21e0cb] 1 ipc_kmsg_send + 105 [0x210a86] 1 ipc_kobject_server + 267 [0x21dbfc] 1 iokit_notify + 154 [0x284eed] 1 iokit_client_died + 85 [0x571527] 1 com.apple.GeForce 6.3.0 + 47083 [0x830867eb] 1 com.apple.GeForce 6.3.0 + 305981 [0x830c5b3d] 1 com.apple.GeForce 6.3.0 + 258633 [0x830ba249] 1 OSObject::release() const + 25 [0x506759] 1 OSObject::taggedRelease(void const*) const + 32 [0x50673e] 1 com.apple.GeForce 6.3.0 + 253194 [0x830b8d0a] 1 com.apple.GeForce 6.3.0 + 251919 [0x830b880f] 1 com.apple.NVDAResman 6.3.0 + 453556 [0x83689bb4] 1 com.apple.NVDAResman 6.3.0 + 445937 [0x83687df1] 1 com.apple.NVDAResman 6.3.0 + 302211 [0x83664c83] 1 com.apple.NVDAResman 6.3.0 + 249957 [0x83658065] 1 com.apple.NVDAResman 6.3.0 + 112888 [0x836368f8] 1 com.apple.NVDAResman 6.3.0 + 111718 [0x83636466] 1 com.apple.nvidia.nv50hal 6.3.0 + 623157 [0x83e1a235] 1 com.apple.nvidia.nv50hal 6.3.0 + 605845 [0x83e15e95] 1 com.apple.nvidia.nv50hal 6.3.0 + 606056 [0x83e15f68] Thread 84d67e DispatchQueue 2 User stack: 46 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff875edfc5] 46 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff875ee128] 46 _dispatch_worker_thread2 + 252 (in libSystem.B.dylib) [0x7fff875ee7fe] 46 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff875eecd4] 46 kevent + 10 (in libSystem.B.dylib) [0x7fff875ed12a] Kernel stack: 46 kevent + 97 [0x47a681] Thread 84d5f9 User stack: 46 kevent64 + 10 (in libSystem.B.dylib) [0x7fff87687512] Kernel stack: 46 kevent + 97 [0x47a681] Thread 84d5fa User stack: 46 ??? [0x10681d9e8] 38 ??? [0x10a60403b] 37 CGLFlushDrawable + 67 (in OpenGL) [0x7fff819d3261] 37 gldFinish + 874 (in GeForceGLDriver) [0x2000d728a] 37 glcNoop + 1072 (in OpenGL) [0x7fff819d491c] 37 CGSFlushSurfaceWithOptions + 396 (in CoreGraphics) [0x7fff88fb81f9] 37 _CGSFlushSurfaceInline + 210 (in CoreGraphics) [0x7fff88fb848c] 37 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff875d429a] 1 glfwSwapBuffers + 69 (in libglfw.dylib) [0x1036f6ba5] 1 _glfwPlatformPollEvents + 132 (in libglfw.dylib) [0x1036f26c4] 1 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155 (in AppKit) [0x7fff88135751] 1 _DPSNextEvent + 103 (in AppKit) [0x7fff88135ba5] 8 ??? [0x109fc6d03] 8 glFlush_Exec + 133 (in GLEngine) [0x11c5b7150] 8 gldUpdateDispatch + 13841 (in GeForceGLDriver) [0x2000d6711] 8 IOConnectCallMethod + 325 (in IOKit) [0x7fff81ae3328] 8 io_connect_method + 490 (in IOKit) [0x7fff81b26ad2] 8 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff875d429a] Kernel stack: 32 ipc_mqueue_receive_continue + 0 [0x210d84] 12 lo64_mach_scall + 77 [0x2a255d] 12 thread_setuserstack + 405 [0x295c17] 8 mach_msg_overwrite_trap + 274 [0x216f84] 8 ipc_kmsg_send + 105 [0x210a86] 8 ipc_kobject_server + 244 [0x21dbe5] 8 iokit_server_routine + 4669 [0x286610] 8 is_io_connect_method + 467 [0x56e2b3] 8 IOUserClient::externalMethod(unsigned int, IOExternalMethodArguments*, IOExternalMethodDispatch*, OSObject*, void*) + 909 [0x56d9ff] 8 shim_io_connect_method_scalarI_structureO + 455 [0x56d160] 8 com.apple.GeForce 6.3.0 + 49337 [0x830870b9] 8 com.apple.GeForce 6.3.0 + 310514 [0x830c6cf2] 8 com.apple.GeForce 6.3.0 + 64383 [0x8308ab7f] 8 IOLockSleep + 39 [0x53633c] 8 lck_mtx_sleep + 87 [0x221d42] 8 thread_block + 33 [0x227654] 8 thread_block_reason + 331 [0x2275c6] 8 thread_dispatch + 1966 [0x227327] 8 machine_switch_context + 659 [0x2a9adb] 4 mach_msg_overwrite_trap + 586 [0x2170bc] 4 ipc_mqueue_receive + 89 [0x211dc4] 4 thread_block + 33 [0x227654] 4 thread_block_reason + 309 [0x2275b0] 4 thread_go + 1961 [0x22698c] 4 thread_setrun + 1360 [0x225bba] 4 machine_idle + 239 [0x2ad0f5] 1 call_continuation + 28 [0x2a179c] 1 idle_thread + 58 [0x22812e] 1 thread_run + 118 [0x22743b] 1 thread_dispatch + 1347 [0x2270bc] 1 ml_set_interrupts_enabled + 47 [0x2a45e3] 1 lo_allintrs + 302 [0x2a1c2e] 1 interrupt + 182 [0x2ab419] 1 lapic_interrupt + 108 [0x2b32b2] 1 mp_kdp_exit + 860 [0x2b4506] 1 sync_iss_to_iks + 124 [0x2aabf6] Thread 84d623 User stack: 46 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a] Kernel stack: 46 semaphore_wait_continue + 0 [0x22a88f] }}}

2 4

Strange context reduction with partial application and casting
by Wonchan Lee 04 Jul '11

04 Jul '11

Hi cafe, I found some strange phenomenon when I was hanging around with GHCi. Please see the following interaction: GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> let f a b c d = a == b && c == d Prelude> :t f f :: (Eq a, Eq a1) => a -> a -> a1 -> a1 -> Bool Prelude> let g = f 1 Prelude> :t g g :: Integer -> () -> () -> Bool Here I expect that the type of g is (Eq a) => Integer -> a -> a -> Bool. But suddenly all the context in the type is gone and I have some strange thing with unit type in it. I tried another example to get what I expected at the first time: Prelude> let g = f :: (Eq a) => Int -> Int -> a -> a -> Bool Prelude> :t g g :: Int -> Int -> () -> () -> Bool The resulting type was different from one that I want to cast into. I know that Haskell tries to reduce the context in the type when there's sufficient information to do it. However, this goes too far from what I think normal. Is this intended behavior or just a bug?

5 5

Confused about my IterIO code
by John Ky 03 Jul '11

03 Jul '11

Hi Hakell Cafe, I'm struggling to understand my unambitious IterIO code that somehow manages to work. Basically I run an echo server that is supposed to read from a socket line by line and write back to the socket with all the characters in the line reversed: import Control.Exception import Control.Monad import Control.Monad.Trans import Data.IterIO import Data.IterIO.Inum import Network import System.IO import System.IO.Error (isEOFError) import qualified Data.ByteString.Lazy as L import qualified Data.ByteString.Lazy.Char8 as C iterHandle' :: (MonadIO m) => Handle -> IO (Iter L.ByteString m (), Onum L.ByteString m a) iterHandle' = iterHandle main = withSocketsDo $ do sListen <- listenOn (PortNumber 8000) putStrLn "Listening on Port 8000" forkIO $ forever $ do (sSession, hostname, port) <- accept sListen hSetBuffering sSession NoBuffering putStrLn ("Connected to " ++ hostname ++ ":" ++ show port) forkIO $ do (iter, enum) <- iterHandle' sSession enum |$ inumReverseLines .| iter putStrLn "Press <CTRL-D> to quit." exitOnCtrlD inumReverseLines :: (Monad m) => Inum L.ByteString L.ByteString m a inumReverseLines = mkInum $ do line <- lineI return (L.reverse (L.concat [line, C.pack "\n"])) exitOnCtrlD = try getLine >>= either (\e -> unless (isEOFError e) $ ioError e) (const exitOnCtrlD) When I run it, it does this: asdfghc7@hoggy-nn:/home/hoggy$ nc localhost 8000 1234 4321 4321 1234 abcde edcba The red lines are the replies from my echo server. But all I've done is: enum |$ inumReverseLines .| iter inumReverseLines = mkInum $ do line <- lineI return (L.reverse (L.concat [line, C.pack "\n"])) No attempt was made to reverse more than one line - at least as far as I can see. What have I done wrong that it should work so well? Also, is there a better way to do this? Cheers, -John

3 3

ANNOUNCE: regex-applicative-0.1
by Roman Cheplyaka 03 Jul '11

03 Jul '11

I am glad to announce the initial release of regex-applicative. Hackage: http://hackage.haskell.org/package/regex-applicative Repository: https://github.com/feuerbach/regex-applicative Issues: https://github.com/feuerbach/regex-applicative/issues regex-applicative is aimed to be an efficient and easy to use parsing combinator library based on regular expressions. Perl programmers often use regular expressions for parsing, even if it is not an appropriate tool for the job, because Perl has so good support for regexps. The opposite seems to be valid about Haskell programmers -- they use parsing combinators (which recognize context-free or even context-sensitive grammars), even when the language is actually regular! Hopefully, this library will improve the situation. This is an early preview release. Some features are lacking, and performance is probably not very good yet. Among the features that we are going to support in future versions are: * Non-greedy operators * Search-and-replace functionality * Error reporting The implementation is heavily based on the ideas from "A Play on Regular Expressions" by Sebastian Fischer, Frank Huch and Thomas Wilke. http://sebfisch.github.com/haskell-regexp/regexp-play.pdf -- Roman I. Cheplyaka :: http://ro-che.info/

1 0

Fwd: Data.Time
by Daniel Patterson 03 Jul '11

03 Jul '11

sent from wrong account - message follows: > I've found most of the time library to be quite useful, but the parsing to be worthless (I've tried to get someone to prove me wrong already, and would be happy if someone could on this thread!). > > Specifically, the formatTime function, if it ever strips out padding (by zeros or spaces), results in a time that is unparseable. The fact that formatTime and parseTime are not capable of being inverses of each other seems like a major flaw, when you think that this is not a parseable date: > > 2011/1/30 (because the month must be padded by zeros). > > Even though it is very easy to print, and occurs commonly in the world. > > Because of this, I use formatTime to write my times, and then have a custom parser to parse them back out. Which makes me think that this is a broken library > > On Jun 27, 2011, at 10:37 AM, <briand(a)aracnet.com> <briand(a)aracnet.com> wrote: > >> On Mon, 27 Jun 2011 11:15:28 +0300 >> Yitzchak Gale <gale(a)sefer.org> wrote: >> >>> >>> The biggest shortcoming, in my opinion, is that the documentation >>> assumes that the reader is very familiar with the Haskell type >>> system, and with viewing type signatures and instance lists as an >>> integral and central part of the documentation. >>> >>> In particular, Haskell's standard numeric type classes and the >>> conversion functions between them play a central role in the API >>> of Data.Time. But you wouldn't realize that unless you have read >>> the type signatures and instance lists in the Haddocks very >>> carefully, and have thought about it for a while. >> >> This is exactly right. >> >>> >>> Another problem, as Malcolm pointed out, is that because of the >>> sheer size of the library, a quick-start guide for the common >>> cases would be extremely helpful for newcomers. >> >> That would be very, very helpful. I had a few working examples things were much better. Finding a starting place, any starting place, proved to be quite elusive. Also the fact that asking for the current time traps you in IO hell, doesn't help, although it's clear that it should be that way. >> >> Brian >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >

4 5