August 2009 - Haskell-Cafe

Heap profiling project update
by Patai Gergely 02 Aug '09

02 Aug '09

Hi all, It's been a while since I announced anything about the project on the list, but I've been regularly posting about it on my blog [1]. Everyone should feel encouraged to check out the cabalised code [2] and play with it, stress test it. Adventurous ones can also look at the source. ;) Gergely [1] http://just-bottom.blogspot.com/ [2] http://code.google.com/p/hp2any/source/checkout -- http://www.fastmail.fm - Send your email first class

1 0

Possible bug in Data.IP (network-data package)
by Mads Lindstrøm 02 Aug '09

02 Aug '09

Hi The network-data (version 0.0.2) [1] contains the module Data.IP. This modules encapsulates IPv4 headers. The Data.IP modules contains the type IPv4Header: data IPv4Header = IPv4Hdr { hdrLength :: Int , version :: Int , tos :: Int , payloadLength :: Int ... The code to turn IPv4 packages into IPv4Heder looks like [2]: instance Binary IPv4Header where put (IPv4Hdr ihl ver tos len id flags off ttl prot csum src dst) = do pW8 $ (ihl .&. 0xF) .|. (ver `shiftL` 4 .&. 0xF0) pW8 tos pW16 len pW16 id let offFlags = (off .&. 0x1FFF) .|. fromIntegral (fromEnum flags `shiftL` 13) pW16 offFlags pW8 ttl pW8 prot put csum put src put dst That is, the payload length is the 16-31'th bit of the IPv4 header. This field is according to [3] and [4] referred to as "total length" - not "payload length". The total length include both the length of the data and the header. When I read the term "payload length" I first thought it referred to the length of the package excluding the header. So I am right to see this as a bug in network-data ? Regards, Mads Lindstrøm [1] http://hackage.haskell.org/package/network-data [2] http://hackage.haskell.org/packages/archive/network-data/0.0.2/doc/html/src… [3] http://tools.ietf.org/html/rfc791 [4] http://en.wikipedia.org/wiki/IPv4#Header

2 1

Retrieving inner state from outside the transformer
by Phil 01 Aug '09

01 Aug '09

Hi, I've hit a brick wall trying to work out, what should be (and probably is!) a simple problem. I have a StateT stack (1 State monad, 2 StateT transformers) which works fine and returns the result of the outer monad. I thought I understood this fine, but perhaps not. My understanding is that the result returned by the inner-most monad is always 'transformed' by the outer monads and thus the result you get is that computed in the outer transformer. The problem I have is now I'd like not only to get the final state of the outer most transformer, but I'd also like to know the final states of the the inner StateT and the inner State at the end of the computation (so that at a later point in time I can reinitialize a similar stack and continue with the same set of states I finished with). So I figured I could have a separate (parent) State Monad (not part of this stack) that would store the final state of the sequence below. I figured it couldn't be part of this stack, as one computation on the stack does not lead to one result in the parent State Monad; it is only the end states of the sequence I care about. Anyway, currently I just have the stack evaluated as below. Is there anyway from outside of the computation that I can interrogate the states of the inner layers? The only way I can see to do this is inside the outer monad itself. As I'm not using the result I could use 'lift get' and 'lift lift get' to make the outer transformer return the two inner states as it's result. I could ignore this result for the first (iterations-1) and bind a final iteration which uses replicateM instead of replicateM_. This strikes me as pretty horrible tho! So, in the example below if I want to modify the 'result' function so it returns no only the outer state, but also the two inners states as a tuple (Double,Double,Double) is there an easier way of doing this? result :: RngClass a => NormalClass b => a -> b -> MonteCarloUserData -> Double result initRngState initNormState userData = evalState a initRngState where a = evalStateT b initNormState b = execStateT ( do replicateM_ (iterations userData) (mc userData)) 0 Any advice greatly appreciated! Thanks, Phil.

4 4

Re: [Haskell-cafe] ANN: atom 0.1.0
by Lee Pike 01 Aug '09

01 Aug '09

Note too that there's an example Atom program included with the source: http://hackage.haskell.org/packages/archive/atom/0.1.0/doc/html/Language-At… Lee > dons wrote: > We've had a few people playing with Atom to program the Arduino, and > John van Enk's been hacking too, > > Atom & Arduino :: Some Hacking (pt. 1) > http://blog.sw17ch.com/wordpress/?p=84 > > > An Atomic Fibonacci Server: Exploring the Atom (Haskell) DSL > http://leepike.wordpress.com/2009/05/05/an-atomic-fibonacci-server-explorin… > > Galois will prob. have a tech talk soon. > > -- Don > > thomas.dubuisson: >> Tom, >> I was asking earlier about any good sources of information for atom. >> It seems the once-good wiki is gone - are there tutorials for Atom >> hiding in forgotten corners? >> >> Thomas >> >> On Fri, Jul 31, 2009 at 1:49 PM, Tom Hawkins<tomahawkins(a)gmail.com> >> wrote: >>> Atom is a Haskell DSL for hard realtime applications. This release >>> includes support for assertions and functional coverage to aid >>> simulation and testing. The rev of the minor version indicates a >>> bit >>> of library stability. This is the version we're using for our >>> application, which officially went into production and hit the road >>> last month -- literally. >>> >>> http://hackage.haskell.org/package/atom >>> >>> -Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>

1 0

Re: Strange memory usage problem
by John Lato 01 Aug '09

01 Aug '09

> From: Ketil Malde <ketil(a)malde.org> > > Hi, > > I'm observing something I find quite strange. I have a program that > normally streams through a file, and it runs in the expected constant > space, consuming about 5MB, according to 'top'. When I uncomment a > certain block of code in the library it uses, space consumption > appears to grow linearly with the input size. > > This is a bit surprising to me, since the code in question isn't used > by the program at all, and yesterday, Cale confirmed this behavior on > a recent GHC (6.10.3, I think - mine is 6.8.2 as shipped with Ubuntu > 9.04). > I can confirm this behavior on GHC 6.10.4 on OSX 10.5.7. Try adding {-# INLINE getRB #-} above the getRB definition. That fixes it for me. I think that when the rest of the code is commented out, getRB is only called in one location, so GHC inlines it automatically. Since getRB is also called in the commented-out code, it probably isn't automatically inlined when that code is available. I suspect that the inlining allows GHC to infer some strictness property it otherwise can't. Cheers, John Lato

2 1

Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0
by Felipe Lessa 01 Aug '09

01 Aug '09

On Wed, Jul 29, 2009 at 06:26:30PM +0200, Sven Panne wrote: > Apart from that, a bug in vertexAttribPointer has been fixed. ...and the new ObjectName, StateVar and Tensor packages are being used, and this is great! Thanks for the release. -- Felipe.

4 9