- Haskell-Cafe - Haskell.org

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

Printing the empty list.
by Joshua Ball 02 Jul '11

02 Jul '11

GHCi seems to be clever about some things: If I try to print the empty list in ghci, I encounter no problems: Prelude> [] [] Prelude> show [] "[]" Prelude> print [] [] Even though the type of the list is clearly unknown, it must be picking SOME type. (why does it print [] instead of "")? If I write a program in a file and load it in main = print [] Then I get the ambiguous type variable error that I would expect. Why doesn't ghci generate this error at the prompt? -- Borrow my books: http://goo.gl/UBbSH

6 6

Period of a sequence
by michael rice 02 Jul '11

02 Jul '11

MathWorks has the function seqperiod(x) to return the period of sequence x. Is there an equivalent function in Haskell? Michael

4 3

Re: [Haskell-cafe] ~ type operator
by Henning Thielemann 02 Jul '11

02 Jul '11

On 24.06.2011 11:10, Daniel Fischer wrote: > On Friday 24 June 2011, 10:26:42, Guy wrote: >> What does the ~ type operator mean? I've sometimes seen types such as (a >> ~ b) in error messages, but can't understand what GHC is trying to tell >> me. > > Type equality, (a ~ b) means that a and b are the same type (rather, that > the compiler can prove they're the same). This type operator is needed when using type families. With functional dependencies you can assert a bijection between types by writing class C a b | a -> b, b -> a where but using type functions you have to tell the compiler somehow that one type function reverses the mapping of another function. This is where (~) is needed. You can use this type operator, when LANGUAGE TypeFamilies is enabled. I assume that the use of (~) in type error messages reflects that GHC's type checker is now internally based on type families. There are also other circumstances, where GHC uses non-Haskell-98 syntax in its messages, e.g. it uses explicit 'forall' quantifiers in error messages also if they are disabled in the affected module.

1 0