December 2005 - Haskell-Cafe

Re: :t main
by Scherrer, Chad 02 Dec '05

02 Dec '05

> From: Bulat Ziganshin <bulatz(a)HotPOP.com> > Hello Chad, > > Wednesday, November 30, 2005, 5:07:02 AM, you wrote: > > SC> I've been reading some of the articles about comonads, > and I thought > SC> the idea of giving main the type OI () -> () was pretty > interesting. > > it looks interesting. what are you reading? > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > > I'm reading the articles by Kieburtz and Uustalu linked from this page http://haskell.org/hawiki/CoMonadArticles On checking this again, I can't find the reference to the types I mentioned -- It may have just been the result of my reading the articles and letting the ideas simmer in my head, combined with a lack of rereading them before posting. I still need to read things through more carefully to be sure I understand it all correctly. In any case, here's the idea (still evolving, of course). There are safe functions of the form a -> IO b but not IO a -> b Dually, you should be able to write functions OI a -> b but not a -> OI b Now, suppose you want to read stdin, apply f to it, and print the result. The current standard is something like main = do s <- getContents print $ f s or main = getContents >>= (print . f) But it's simpler to write main = print . f . coGetContents where coGetContents :: OI () -> String f :: String -> a print :: a -> IO () Of course, changing the type of main alltogether is probably a bad idea, because it would break too much code. But maybe allowing constructions like this would be reasonable? Alternatively, there could be a nice way to write toMain :: (OI () -> IO ()) -> IO () My first thought is toMain f = f $ OI () but somehow this seems to easy, and I'm worried about the type safety. --------------------------------------------- Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

2 1

Re: [Haskell-cafe] Thread blocked indefinitely
by Joel Reymont 02 Dec '05

02 Dec '05

I got a copy, thanks! On Dec 2, 2005, at 6:47 PM, Greg Woodhouse wrote: > Did anyone ever send you a copy of this paper? I'm an ACM member, so I > could forward it to you if need be. -- http://wagerlabs.com/

1 0

Thread blocked indefinitely
by Joel Reymont 02 Dec '05

02 Dec '05

Folks, I'm trying to learn more about this exception. Would someone with a subscription to ACM kindly send me this paper: http://portal.acm.org/ft_gateway.cfm?id=507655&type=pdf? Thanks in advance, Joel -- http://wagerlabs.com/

1 0

RE: Examining the Haskell stack (read at your own risk ; -))
by Simon Marlow 02 Dec '05

02 Dec '05

On 02 December 2005 14:17, Joel Reymont wrote: > On Dec 2, 2005, at 2:08 PM, Simon Marlow wrote: > >> It looks like your crash happened in the SSL library, and you have a >> useful stack trace there. > > This is contrived in that I already know where the error is and it > clearly points to SSL_free. I'm trying to figure out how I would have > gotten to that call to getHostByName. > >> r22 is a pointer to the stack, not a pointer to code, so you can't >> disassemble it, you need to display memory (as I described in >> separate mail). > > Quoting you: > > --- > gdb> p16 $r22 > > which prints 16 words of memory backwards (the way I like it) starting > at the addresss in $r22. when displaying memory this way, gdb very > handily prints the symbol name for words that point into the program. > You can then pick things off the stack that look like return addresses > and disassemble them, if you want. > --- > > And p16 is defined in .gdbinit as: > > define p16 > pmem $arg0 16 > end > > Printing the 16 words gives me the printout below but where do I find > my Haskell function? The code tha causes the crash looks like this: > > maybeFreeSSL :: MaybeSSL -> IO () > maybeFreeSSL tmv = > do putStrLn $ "maybeFreeSSL invoked" > mssl <- atomically $ swapTMVar tmv Nothing > case mssl of > Nothing -> return () > Just (ssl, _, _) -> do sslFree ssl > sslFree ssl > > Is there a way to have maybeFreeSSL in the trace? I compiled the app > with -debug but the libraries and the above maybeFreeSSL code was > compiled without it. > > Thanks, Joel > > P.S. > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000019 > 0x00568fe0 in sk_pop_free () > (gdb) p16 $r22 > 0x137a40c: 0x1ce63c <stg_NO_TREC_closure> > 0x137a408: 0x0 > 0x137a404: 0x0 > 0x137a400: 0x18fd0 <stg_TREC_HEADER_info> > 0x137a3fc: 0xd6dbc <stg_stop_thread_info> > 0x137a3f8: 0xd6f38 <stg_noforceIO_info> > 0x137a3f4: 0x13ef148 > 0x137a3f0: 0x0 > 0x137a3ec: 0x2605c <stg_catch_frame_info> > 0x137a3e8: 0x25c80 <stg_unblockAsyncExceptionszh_ret_info> > 0x137a3e4: 0x13ef150 > 0x137a3e0: 0x27030 <s3BN_info> > 0x137a3dc: 0x1d22cc <GHCziConc_lvl7_closure> > 0x137a3d8: 0x26f6c <s3BK_info> > 0x137a3d4: 0x13f38f4 > 0x137a3d0: 0x243f4 <s7Fy_info> > 0x137a3cc: 0xc3270 <s7FI_info> Ok, you want a crash course in reading the Haskell stack. Each xxx_info symbol is a return address. The other values are the contents of stack frames: values saved for use at the return address. A return address also has an associated info table (use pinfo in the .gdbinit I sent you for disaplying the info table, eg. pinfo s7FI_info). Understanding info tables is beyond the scope of this message; please see InfoTables.h in the GHC sources. You probably want to know what each return address corresponds to: - the ones beginning "stg_" are in the runtime, you can see the code for these in the GHC sources (grep in ghc/rts). - the ones that look like "s7FI_info" are local symbols. You might be able to find which module it comes from by grepping the .o files in your program and the .a library files. If you find it in a library, you can use 'nm' on the library to get a better idea of what function the symbol is associated with. One problem is that because these are local symbols, you might find the same symbol in multiple places, and you have to make an educated guess as to which is the appropriate one (or use the disassembly to distinguish). To map this back to Haskell code, you need to recompile the original module and dump the intermediate code with -ddump-stg. Understanding the output of -ddump-stg is beyond the scope of this message :-) Cheers, Simon

2 1

Re: returning lists
by Scherrer, Chad 02 Dec '05

02 Dec '05

raptor <raptor(a)tvskat.net> writes, > ]- that is the problem :"), 'cause such functions should accept Char and > String, but return a Tuple of Strings, but it is recursive (so that it fetch > next,next,next char :)) i.e. it is own "consumer" and should return String > --this is wrong, just tring grab char (x:xs) You might also have a look at http://haskell.org/hawiki/WorkerWrapper This idea should apply here. -Chad Scherrer

1 0

RE: Examining the Haskell stack (read at your own risk ; -))
by Simon Marlow 02 Dec '05

02 Dec '05

On 02 December 2005 14:03, Joel Reymont wrote: > You told me a bit about how to examine the Haskell stack by looking > at R22 on the PowerPC and $ebx on Intel architectures. I looked at > your .gdbinit but could not figure out which macros are to be used. > > The example below is a bit contrived in that I'm freeing the SSL > context twice, on purpose. I tried getting a disassembler dump using > the contents of R22 without luck: > > (gdb) info registers r22 > r22 0x137a3cc 20423628 > (gdb) disas 0x137a3cc > No function contains specified address. > > This is my stack trace: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000019 > 0x00568fe0 in sk_pop_free () > (gdb) where > #0 0x00568fe0 in sk_pop_free () > #1 0x0059f128 in X509_VERIFY_PARAM_free () > #2 0x003c4d5c in SSL_free () > #3 0x000c3254 in r7cH_info () > #4 0x000ccd04 in schedule (mainThread=0x13f3f18, > initialCapability=0x578df0) at Schedule.c:932 > #5 0x000cdcac in waitThread_ (m=0x1100360, initialCapability=0x0) at > Schedule.c:2156 > #6 0x000cdb90 in scheduleWaitThread (tso=0x13c0000, ret=0x0, > initialCapability=0x0) at Schedule.c:2050 > #7 0x0001ff0c in rts_evalLazyIO (p=0x1ce0c8, ret=0x0) at RtsAPI.c:459 > #8 0x0000495c in main (argc=25, argv=0x578df0) at Main.c:104 > (gdb) info registers r22 > r22 0x137a3cc 20423628 > (gdb) disas 0x137a3cc > No function contains specified address. It looks like your crash happened in the SSL library, and you have a useful stack trace there. r22 is a pointer to the stack, not a pointer to code, so you can't disassemble it, you need to display memory (as I described in separate mail). Cheers, Simon

2 1

RE: Threaded runtime (was Re: [Haskell-cafe] Project postmortem)
by Simon Marlow 02 Dec '05

02 Dec '05

On 02 December 2005 13:32, Joel Reymont wrote: > I was going on this quote by Simon PJ: > > -- > It should be find to have lots of threads, esp if most of them are > asleep. The only thing to watch out for is that GHC's runtime system > will consume one *OS* thread for each *blocked* foreign call. So if > you have 10k threads each making a separate call to the OS to read > from 10k sockets, and they all block, you'll use 10k OS threads, and > that will probably fail. > -- > > Is this correct and if so how does it mesh with what you said above? It's correct, but not the whole story. When you do a blocking I/O operation, it is not implemented in terms of a blocking foreign call, so it doesn't create an OS thread(*). In -threaded mode, blocking I/O is implemented by sending a reguest to the I/O manager thread, which returns a response when I/O is available. In non-threaded mode, blocking I/O is implemented by returning to the runtime, which occasionally checks for available I/O and wakes up the appropraite threads. Either way, as I said, the programmer doesn't see any difference. (*) except on Windows, where everything is done differently and blocking I/O currently gets a real OS thread. Cheers, Simon

1 0

RE: [Haskell-cafe] Project postmortem
by Simon Marlow 02 Dec '05

02 Dec '05

On 02 December 2005 12:25, Joel Reymont wrote: > I thought that if -threaded is not used then all the blocking IO is > assigned a separate OS thread. No - the runtime is completely single-threaded without -threaded. Blocking I/O is managed by the runtime. With -threaded, blocking I/O is managed by a Haskell thread. The programmer shouldn't see any difference in the behaviour of I/O. Is the documentation for -threaded lacking? I realise it's a bit terse, but do you have any concrete suggestions for improving it? Cheers, Simon

2 2

wxHaskell and do statements
by mempko 02 Dec '05

02 Dec '05

Hello, I have a program that just will not compile and I cannot figure out why. I am starting out with wxHaskell but keep getting certain errors. Here is the source: ------------------------- module Main where import Graphics.UI.WX main :: IO () main = start hello hello :: IO () hello = do f <- frame [text := "Super Window"] lab <- staticText f [text:= "Hello"] quit <- button f [text:= "Quit", on command := close f] touch <- button f [text:= "Touch Me", on command := set quit [text:= "Yay"]] set f [layout:= floatCenter (widget lab) $ floatCenter (widget touch) $ floatCenter (widget quit)] ------------------ I keep the following error **** Compiling Main ( test1.hs, test1.o ) test1.hs:9:11: The last statement in a 'do' construct must be an expression ***** I looked at source code for the do statement and can not understand why I get that error.

5 5

RE: [Haskell-cafe] Project postmortem
by Simon Marlow 02 Dec '05

02 Dec '05

On 02 December 2005 12:49, Tomasz Zielonka wrote: > On Fri, Dec 02, 2005 at 12:39:25PM -0000, Simon Marlow wrote: >>> Do I understand correctly that another workaround is >>> - don't compile your programs with -threaded >>> ? >> >> No, the bug isn't related to -threaded. It still occurs without >> -threaded. > > Let's check that now I understand - so the sequence > > call gethostbyname > read the returned hostent > > is written in Haskell, and many such sequences can be interleaved when > using Concurrent Haskell? Yes, exactly. Cheers, Simon

1 0