- Haskell-Cafe - Haskell.org

Reading pcap
by mukesh tiwari 16 Oct '11

16 Oct '11

Hello all I was going through wireshark and read this pcap<http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=u…>file in wireshark. I wrote a simple haskell file which reads the pcap file displays its contents however it looks completely different from wireshark. When i run this program . it does not produce any thing and when i press ^C ( CTRL - C ) it produce output. output for given file ^C*0xd4 0xc3 0xb2 0xa1 0x02 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff 0x00 0x00 0x01 0x00 0x00 0x00 0x0b 0xd4 0x9e 0x43 0x41 0x38 0x01 0x00 0x3c 0x00 0x00 0x00 0x3c 0x00 0x00 0x00 *0x00* *0x04 0x76 0xdd 0xbb 0x3a 0x00 0x04 0x75 0xc7 0x87 0x49 0x08 0x00 0x45 0x00 0x00 0x28 0x1a 0x6a 0x40 0x00 0x40 0x88 0x6f 0x71 0x8b 0x85 0xcc 0xb0 0x8b 0x85 0xcc 0xb7 0x80 0x00 0x04 0xd2 0x00 0x00 0x38 0x45 0x68 0x65 0x6c 0x6c 0x6f 0x20 0x77 0x6f 0x72 0x6c 0x64 0x00 0x00 0x00 0x00 0x00 0x00 The values displayed in wireshark 0000 00 04 76 dd bb 3a 00 04 75 c7 87 49 08 00 45 00 ..v..:.. u..I..E. 0010 00 28 1a 6a 40 00 40 88 6f 71 8b 85 cc b0 8b 85 .(.j@.@. oq...... 0020 cc b7 80 00 04 d2 00 00 38 45 68 65 6c 6c 6f 20 ........ 8Ehello 0030 77 6f 72 6c 64 0a 00 00 00 00 00 00 world... .... import Data.Char import Data.List import Text.Printf import Control.Monad fileReader :: Handle -> IO () fileReader h = do t <- hIsEOF h if t then return () else do tmp <- hGetLine h forM_ tmp ( printf "0x%02x " ) fileReader h main = do l <- openBinaryFile "udp_lite_full_coverage_0.pcap" ReadMode fileReader l print "end" I am simply trying to write a haskell script which produce interpretation of pcap packet same as wireshark ( At least for UDP packet ) . Could some one please tell me a guide map to approach for this . A general guide line for this project like What to read which could be helpful for this project , which haskell library or any thing which you think is useful . Regards Mukesh Tiwari

4 7

Re: [Haskell-cafe] Cabal's dependence mechanism can be more available
by 吴兴博 16 Oct '11

16 Oct '11

hello Aur: :) You get the point, the author of that package said that he has no enough time to check for the problem. then I have to solve it myself. For these kind of packages, maybe the best way to use it is re-write it myself... I have see a lot of packages that comes from "master thesis" or some. if you miss the season, then you miss the successful build :). 在 2011年10月15日下午6:48，Aur Saraf <sonoflilit(a)gmail.com>写道： > Did you at least receive this? :-) > > > ---------- Forwarded message ---------- > From: <libraries-owner(a)haskell.org> > Date: Fri, Oct 14, 2011 at 10:47 PM > Subject: Re: [Haskell-cafe] Cabal's dependence mechanism can be more > available > To: sonoflilit(a)gmail.com > > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > libraries-owner(a)haskell.org. > > > > ---------- Forwarded message ---------- > From: Aur Saraf <sonoflilit(a)gmail.com> > To: 吴兴博 <wuxb45(a)gmail.com> > Date: Fri, 14 Oct 2011 22:47:27 +0200 > Subject: Re: [Haskell-cafe] Cabal's dependence mechanism can be more > available > That a package builds with a certain version of another package does > not mean that the code is correct. > > I once had to maintain code that used "CSV > 0.0.0.1", and it turned > out that in CSV-0.0.0.2 there wasn't a newline appended to the end of > the string anymore (in the old version there was), so the packages > compiled great together but I had a huge bug (because I was generating > a text file of empty-line separated CSV blocks for a perl script to > turn into an Excell file, and the perl now thought that it was all one > big CSV block). > > Trusting the author is the best that can be done in these cases. > Sometimes the author is wrong, and then we must ask him to correct his > packages - which I do a lot. But that's life. > > > Cheers, > Aur > > On Thu, Oct 13, 2011 at 4:05 PM, 吴兴博 <wuxb45(a)gmail.com> wrote: > > [[ My point is on cabal, but I had to give some examples. I'm very sorry > > for the authors of the packages listed below. ]] > > The story is : > > I was trying to install a package from hackage [holumbus-mapreduce]. I > use > > ghc-7.2.1 and had a hard time to install the packages that depends on. > > [holumbus-mapreduce] depends on [holumbus-distribution]. > > [holumbus-distribution] depends on [hxt] and [hxt-regex-xmlschema]. etc.. > > There are tens of depends that drive me into an infinite 'step in'. > > If the dependence mechanism of cabal packages is good enough and the > > author of the package built it, the success can be repeat. but it not. > > a example: > > 1. > > There are hxt packages with version 9.* in hackage now. > > [holumbus-distribution] says that it depends on "hxt >= 8.2". > > But I had to add "< 9" to make it compiled. Maybe when > > holumbus-distribution was released, there was no hxt 9.*. > > 2. > > some packages depends on "haskell98 <2" > > I just removed this line, and it compiled, and id I use > "haskell98", > > the newer "haskell98-2.*" will clash with new "base" > > 3. > > here is a piece of message from `runhaskell Setup configure` > > """ > > Configuring Holumbus-Distribution-0.1.1... > > Warning: This package indirectly depends on multiple versions of > the > > same > > package readline-1.0.1.0 requires process-1.0.1.5 > > package hslogger-1.1.5 requires process-1.0.1.5 > > package haskell98-2.0.0.0 requires process-1.1.0.0 > > """ > > but finally I found that "readline" does not refuse to be compiled > with > > newer "process" at all, I use --reinstall to adjust "readline" and > > "hslogger" play with "process-1.1.0.0" > > It is like C++'s multi-deriving or something like that, I'm not sure > of > > the technique word. A what to contain B,C ; B contains D' and C > contains > > D'' ; but there can be only One D in A. > > > > All I did is download the all packages, edit its depends: and compile and > > install it. > > > > If Cabal can remember some certain package-version combination of the > > successful builds, Sure It will make hackage more available to users. > > based on some success build, it can also try to make promotion to > > depends-packages, and provides newest & can build packages. > > > > Cheers! > > > > -- > > > > Wu Xingbo > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- 吴兴博 Wu Xingbo

1 0

A question about causality in FRP
by Alan Jeffrey 15 Oct '11

15 Oct '11

Hi everyone, Not sure this is the right venue, as this is a question about the semantics of FRP rather than Haskell... I have a question about the definition of "causality" for stream functions. A quick recap... Given a totally ordered set T (of times), the type of behaviours Beh A is defined to be (T -> A). Behaviours come with an equivalence relation a =t b (equal up to time t) defined as: a =t b iff forall s <= t . a(s) = b(s) A function (f : Beh A -> Beh B) is causal whenever it respects =t, i.e. (forall t . a =t b => f a =t f b). This is fine and good, until we hit nested behaviours, where there are oddities. Consider the function: double : Beh A -> Beh Beh A double a t u = a u This fails to be causual, because (using list notation for behaviours where the time domain is natural numbers) we have: [0,1,2,...] 0 = 0 = [0,2,4,...] 0 double [0,1,2,...] 0 = [0,1,2,...] != [0,2,4,...] = double [0,2,4,...] On the other hand: weird : Beh Beh A -> Beh A weird a t = a t (t + 1) is causal, even though on the surface the behaviour at time t depends on the behaviour at time t+1. An alternate definition, which allows double and disallows weird, is a "deep" equality: a ~t b iff forall s <= t . a(s) ~s b(s) Note that this depends on deep equality being defined at type A. Some appropriate definitions for ~t at other types includes: at type A -> B: f ~t g iff forall s <= t, a ~s b implies f a ~s f b at type (A,B): (a1,a2) ~t (b1,b2) iff (a1 ~t b1) and (a2 ~t b2) [And yes, I don't think it's a coincidence that this looks a lot like a parametricity definition or step-indexed logical relation.] Has such a definition of "deep" causality been investigated? Alan.

4 10

Cabal's dependence mechanism can be more available
by 吴兴博 14 Oct '11

14 Oct '11

[[ My point is on cabal, but I had to give some examples. I'm very sorry for the authors of the packages listed below. ]] The story is : I was trying to install a package from hackage [holumbus-mapreduce]. I use ghc-7.2.1 and had a hard time to install the packages that depends on. [holumbus-mapreduce] depends on [holumbus-distribution]. [holumbus-distribution] depends on [hxt] and [hxt-regex-xmlschema]. etc.. There are tens of depends that drive me into an infinite 'step in'. If the dependence mechanism of cabal packages is good enough and the author of the package built it, the success can be repeat. but it not. a example: 1. There are hxt packages with version 9.* in hackage now. [holumbus-distribution] says that it depends on "hxt >= 8.2". But I had to add "< 9" to make it compiled. Maybe when holumbus-distribution was released, there was no hxt 9.*. 2. some packages depends on "haskell98 <2" I just removed this line, and it compiled, and id I use "haskell98", the newer "haskell98-2.*" will clash with new "base" 3. here is a piece of message from `runhaskell Setup configure` """ Configuring Holumbus-Distribution-0.1.1... Warning: This package indirectly depends on multiple versions of the same package readline-1.0.1.0 requires process-1.0.1.5 package hslogger-1.1.5 requires process-1.0.1.5 package haskell98-2.0.0.0 requires process-1.1.0.0 """ but finally I found that "readline" does not refuse to be compiled with newer "process" at all, I use --reinstall to adjust "readline" and "hslogger" play with "process-1.1.0.0" It is like C++'s multi-deriving or something like that, I'm not sure of the technique word. A what to contain B,C ; B contains D' and C contains D'' ; but there can be only One D in A. All I did is download the all packages, edit its depends: and compile and install it. If Cabal can remember some certain package-version combination of the successful builds, Sure It will make hackage more available to users. based on some success build, it can also try to make promotion to depends-packages, and provides newest & can build packages. Cheers! -- Wu Xingbo

2 1

Lists concatenation being O(n)
by Yves Parès 14 Oct '11

14 Oct '11

Hello, I re-read recently a bit of RealWorldHaskell, and I saw something that puzzles me now that I have a better understanding of the language. It concerns the list concatenation being costful, and the need to use another type like DList. [] ++ ys = ys (x:xs) ++ ys = x : (xs ++ ys) To me, we have here something that would be costful in a strict language, but that here, thanks to guarded recursion ((:) being non-strict), doesn't evaluate the first list until it is needed. How comes RHW says "We can see that the cost of creating a new list depends on the length of the initial list", since nothing will be done unless we ask for our list to be evaluated, which is somewhat something we will end up asking.

6 9

__GLASGOW_HASKELL__ macro in 7.2.1
by JP Moresmau 14 Oct '11

14 Oct '11

Hello list, I must be doing something stupid, but what? ghc --version The Glorious Glasgow Haskell Compilation System, version 7.2.1 ghc -E -optP-dM -cpp Main.hs (per http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html) {-# LINE 1 "Main.hs" #-} #define mingw32_HOST_OS 1 #define i386_BUILD_ARCH 1 #define __GLASGOW_HASKELL__ 702 #define __STDC_HOSTED__ 1 #define i386_HOST_ARCH 1 #define mingw32_BUILD_OS 1 I'm on Windows so everything else is correct except the line that tells me I'm using 7.0.2. Unfortunately I have code that works under 7.0.3 and breaks under 7.2.1 (and the 7.2.1 code breaks under 7.0.3, of course) so I don't see anything other option than conditional compilation. What am I doing wrong? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

3 3

lhs2tex-hl 1.4.3 released
by Alessandro Vermeulen 14 Oct '11

14 Oct '11

Dear all, I've uploaded a new version of lhs2tex-hl [1] to hackage [2]. It includes: 1. It now builds on GHC 7.2.x 2. You can list the LaTeX commands you have to implement (with a default implementation) with lhs2TeX-hl --action=ListCommands 3. Binary operators should now be typeset correctly. What does it do? It generates formatting statement for highlighting your Haskell code in your lhs2TeX compatible documents. Generate a fmt file with > lhs2TeX-hl -o file.fmt file.lhs and add the following to your lhs file: %include file.fmt Have fun With kind regards, Alessandro Vermeulen [1] https://github.com/spockz/lhs2texhl [2] http://hackage.haskell.org/package/lhs2TeX-hl

1 0

Re: [Haskell-cafe] [Haskell] ANNOUNCE: vector-bytestring-0.0.0.0
by Bas van Dijk 14 Oct '11

14 Oct '11

On 14 October 2011 14:01, Ertugrul Soeylemez <es(a)ertes.de> wrote: > Is there any particular reason to prefer storable vectors instead of > unboxed vectors? The element type is fixed to Word8 anyway. To be able to safely interface with foreign libraries. Note that unboxed vectors are represented as ByteArray#s. These are "unpinned" which means that the GC can freely move them through the heap to defragment your memory. If a foreign library had a pointer to an unboxed vector and the GC would move the memory to some place else, your program could crash. Storable vectors use a ForeignPtr instead which (according how you allocated it) points to "pinned" memory. You might like to follow the just created: http://hackage.haskell.org/trac/ghc/ticket/5556 which proposes the pin# and unpin# primitives for dynamically pinning and unpinning ByteArray#s. This way, as pumpkin explains it, you don't have to decide up front whether you want to suffer from memory fragmentation or to support foreign bindings. It would be really nice if that could be implemented! Bas

1 0

hello Haskell
by R J 14 Oct '11

14 Oct '11

hey Haskell this is sick http://www.bestsource10.com

1 0

Cross-compilation x64 -> x86 easier under Ubuntu 11.10 with multiarch?
by Eugene Kirpichov 13 Oct '11

13 Oct '11

Hi cafe, Ubuntu 11.10 has been released, which includes support for "multiarch" https://wiki.ubuntu.com/MultiarchSpec Am I right that this will facilitate compiling Haskell code into x86 binaries on an x64 machine? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

4 7