- Haskell-Cafe - Haskell.org

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

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

02 Dec '05

On 02 December 2005 12:11, Tomasz Zielonka wrote: > On Fri, Dec 02, 2005 at 11:20:54AM -0000, Simon Marlow wrote: >> If anyone is interested, this turned out to be a bug in the >> Network.BSD module, namely that getHostByName isn't thread safe >> because it is based on the C library function gethostbyname(), which >> returns data in a single static area. >> >> Workarounds are: >> >> - do your own mutual exclusion locking around getHostByName and any >> function that calls it (eg. connectTo). >> >> - use Network.Alt >> (http://www.cs.helsinki.fi/u/ekarttun/network-alt/) which has a >> thread-safe implementation of getHostByName. >> >> - wait for 6.4.2, which will contain a fix for this bug (we don't >> have a fix committed yet, Einar Karttunen has kindly offered to >> look into it). > > 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. Cheers, Simon

2 1

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

02 Dec '05

On 21 November 2005 10:16, Joel Reymont wrote: > Is Wolfgang still around? > > Would you guys be willing to guide me through this? I could then > possibly become the next Mac OSX expert :-). > > I have the disassembler dumps, etc. I do not know how to approach > this problem. I read up a bit on the GHC internals, STG, code > generation, etc. If anyone is interested, this turned out to be a bug in the Network.BSD module, namely that getHostByName isn't thread safe because it is based on the C library function gethostbyname(), which returns data in a single static area. Workarounds are: - do your own mutual exclusion locking around getHostByName and any function that calls it (eg. connectTo). - use Network.Alt (http://www.cs.helsinki.fi/u/ekarttun/network-alt/) which has a thread-safe implementation of getHostByName. - wait for 6.4.2, which will contain a fix for this bug (we don't have a fix committed yet, Einar Karttunen has kindly offered to look into it). Cheers, Simon

3 2

RE: Re[2]: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 02 Dec '05

02 Dec '05

On 01 December 2005 13:27, Bulat Ziganshin wrote: > Hello Simon, > > Wednesday, November 30, 2005, 3:26:44 PM, you wrote: > >> It's a modification of GHC.Conc, so I can't supply a standalone >> implementation I'm afraid. > >>> I could use Tomasz's workaround in the meantime but isn't GHC 6.6 >>> supposed to be out in a year? > >> Rather less than a year, I hope. > > Joel, you can download GHC 6.6 beta builds (from > http://www.haskell.org/ghc/dist/head/dist ?), so you only > need to wait until Simon actually merges this update to the main code http://www.haskell.org/ghc/dist/current/dist/ and registerTimeout is already in. Cheers, Simon

1 0

Problem with continuations and typing
by oleg＠pobox.com 02 Dec '05

02 Dec '05

Jerzy Karczmarczuk wrote: > I tried to cook-up a simple version of nondeterministic computations > using the two-continuation model. I got stuck on an 'infinite type' > error, and my question is: have you seen a *concrete* (really > concrete) Haskell implementation of a similar model, I could inspire > myself on? (I know a few theoretical works on that). Yes, of course: the code for the LogicT paper http://pobox.com/~oleg/ftp/packages/LogicT.tar.gz (please see SFKT.hs) and http://www.haskell.org/pipermail/haskell/2005-October/016577.html http://www.haskell.org/pipermail/haskell/2005-October/016696.html As we can see, FR stream indeed takes success and the failure continuations. This is emphasized at the beginning of the first article. > But I would like to continue this exercice along these lines, without > too much exotism (no monads, yet...), for my students. Do you have any > simple work-around Introduce some algebraic constructors? Perhaps > higher-rank polymorphism could do something (but then I would have to > explain it to my folk...) You're correct on both counts. We can emulate equi-recursive types with iso-recursive ones: e.g., plain Haskell list. Or, you may choose to use higher-ranked type (the FR stream). There is a third solution: use a small typing hole in Haskell to sneak in the real equi-recursive type. I have a feeling though you might not wish to explain the latter method to your students. This present question is actually related to your previous inquiry about expressing a predecessor in a simply-typed lambda-calculus. It cannot be expressed. We need either a recursive or higher-ranked type: predecessor is 'car'.

1 0