- Haskell-Cafe - Haskell.org

ANN: websockets 0.4.0.0
by Jasper Van der Jeugt 04 Nov '11

04 Nov '11

Hello all, I'm pleased to announce the release of websockets [1] 0.4.0.0 today. You can grab it on Hackage [2]. This update brings an (almost completely rewritten) library which has support for multiple versions of the protocol, meaning you can choose to write backwards-compatible applications, or use the latest and greatest, all using a common API. All feedback is obviously welcome, I'd be glad to hear what you guys think. For the next version, client-side support is planned, so the library user can write clients in addition to servers. If there's any other feature you would like to see, feel free to let me know. [1]: http://jaspervdj.be/websockets/ [2]: http://hackage.haskell.org/package/websockets Cheers, Jasper

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 99, Issue 9
by yrazes 04 Nov '11

04 Nov '11

Hi This is a very simple basic case, but I have a little trouble with this... I hope somebody can help me main :: IO() main = return :: f tipos :: Int -> Int -> Int -> Float tipos a b c f = b / a * c where (a,b,c) = (8,3,15) Julita On Thu, Nov 3, 2011 at 11:10 PM, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: How to speedup generically parsing sum types? > (Jos? Pedro Magalh?es) > 2. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 3. Re: The type class wilderness + Separating instances and > implementations into separate packages (Ryan Newton) > 4. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 5. Re: The type class wilderness + Separating instances and > implementations into separate packages (Bas van Dijk) > 6. Re: How to speedup generically parsing sum types? (Claus Reinke) > 7. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 8. [ANNOUNCE] cereal-0.3.4.0 (Trevor Elliott) > 9. System calls and Haskell threads (Andreas Voellmy) > 10. Re: System calls and Haskell threads (Johan Tibell) > 11. Is generic information dumpable? (Magicloud Magiclouds) > 12. Re: Is generic information dumpable? (Jos? Pedro Magalh?es) > 13. Re: How to speedup generically parsing sum types? > (Twan van Laarhoven) > 14. compiler construction (Timo von Holtz) > 15. Re: System calls and Haskell threads (David Barbour) > 16. Re: System calls and Haskell threads (David Barbour) > 17. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 18. Re: compiler construction (Sean Leather) > 19. Re: compiler construction (Thomas Schilling) > 20. Mailing lists at haskell.org (Giovanni Tirloni) > 21. Re: Mailing lists at haskell.org (Bas van Dijk) > 22. Re: Is generic information dumpable? (Bas van Dijk) > 23. Re: Is generic information dumpable? (Jos? Pedro Magalh?es) > 24. Re: Is generic information dumpable? (Bas van Dijk) > 25. Re: Message (Ryan Newton) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Nov 2011 11:49:17 +0000 > From: Jos? Pedro Magalh?es <jpm(a)cs.uu.nl> > Subject: Re: [Haskell-cafe] How to speedup generically parsing sum > types? > To: Bas van Dijk <v.dijk.bas(a)gmail.com> > Cc: Haskell Cafe <haskell-cafe(a)haskell.org> > Message-ID: > <CA%2BZFbn_N27z_OABxHr1DPGRE%2B4m-t1BkK%3D-W%2BbDLvp66UC7G4Q(a)mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Bas, > > First of all, thanks for these numbers. I have previously compared the > performance of GP libs [1] and your results confirm what I would expect, > except for that last one, BigSum/fromJSON/generic. > > It's good that you're using INLINE pragmas on the generic function already. > What I would also try: > - Compile with -O2 and -fno-spec-constr-count (this last one is > particularly important) > - Add {-# INLINE [1] #-} pragmas to the to/from methods of your Generic > instances. > > To add these INLINE pragmas you will have to give your own instances of > Generic (so you can't derive them). I'd suggest you get hold of them with > -ddump-deriv, copy-paste and add the pragmas, just for testing purposes. > The phase is important: you first want to make sure you inline the generic > function definition, and only then the from/to. > > Please keep me posted on the effects of these suggestions. In particular, > if the INLINE pragmas on the from/to methods are essential, I'll be happy > to add them to the derived instances. > > > Cheers, > Pedro > > [1] http://dreixel.net/research/pdf/ogie.pdf > > 2011/11/3 Bas van Dijk <v.dijk.bas(a)gmail.com> > > > Hello, > > > > I recently added default generic implementations of toJSON and > > parseJSON to the aeson package. Now I'm optimizing them. Here are some > > benchmark results that compare: > > > > * th: toJSON and fromJSON generated by template-haskell. Can be > > compared to hand-written code. Should be the fastest of all. > > > > * syb: toJSON and fromJSON from the Data.Aeson.Generic module. Uses > > the Data type class. > > > > * generic: my toJSON and fromJSON using GHC Generics. > > > > The benchmark itself can be found here: > > > > > https://github.com/basvandijk/aeson/blob/optimizations/benchmarks/AesonComp… > > > > toJSON > > ====== > > > > D/toJSON/th 3.631734 us > > D/toJSON/syb 32.66679 us > > D/toJSON/generic 3.371868 us > > > > BigRecord/toJSON/th 8.982990 us > > BigRecord/toJSON/syb 48.90737 us > > BigRecord/toJSON/generic 8.971597 us > > > > BigProduct/toJSON/th 1.578259 us > > BigProduct/toJSON/syb 29.21153 us > > BigProduct/toJSON/generic 1.623115 us > > > > BigSum/toJSON/th 51.81214 ns > > BigSum/toJSON/syb 1.256708 us > > BigSum/toJSON/generic 71.32851 ns > > > > > > fromJSON > > ======== > > > > D/fromJSON/th 7.017204 us > > D/fromJSON/syb 23.46567 us > > D/fromJSON/generic 7.968974 us > > > > BigRecord/fromJSON/th 8.513789 us > > BigRecord/fromJSON/syb 36.64501 us > > BigRecord/fromJSON/generic 10.07809 us > > > > BigProduct/fromJSON/th 2.430677 us > > BigProduct/fromJSON/syb 17.97764 us > > BigProduct/fromJSON/generic 2.201130 us > > > > BigSum/fromJSON/th 414.8699 ns > > BigSum/fromJSON/syb 4.113170 us > > BigSum/fromJSON/generic 13.62614 us !!! > > > > > > As can be seen, in most cases the GHC Generics implementation is much > > faster than SYB and just as fast as TH. I'm impressed by how well GHC > > optimizes the code! > > > > Unfortunately the last benchmark, generically parsing a big sum type, > > is much slower. The code for parsing sums, which can be found here: > > > > > > > https://github.com/basvandijk/aeson/blob/optimizations/Data/Aeson/Types/Int… > > > > is basically this: > > > > > > instance (GFromSum a, GFromSum b) => GFromJSON (a :+: b) where > > gParseJSON (Object (M.toList -> [keyVal])) = gParseSum keyVal > > gParseJSON v = typeMismatch "sum (:+:)" v > > {-# INLINE gParseJSON #-} > > > > > > class GFromSum f where > > gParseSum :: Pair -> Parser (f a) > > > > instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where > > gParseSum keyVal = (L1 <$> gParseSum keyVal) <|> > > (R1 <$> gParseSum keyVal) > > {-# INLINE gParseSum #-} > > > > instance (Constructor c, GFromJSON a, ConsFromJSON a) => > > GFromSum (C1 c a) where > > gParseSum (key, value) > > | key == pack (conName (undefined :: t c a p)) = > > gParseJSON value > > | otherwise = notFound $ unpack key > > {-# INLINE gParseSum #-} > > > > > > notFound :: String -> Parser a > > notFound key = fail $ "The key \"" ++ key ++ "\" was not found" > > {-# INLINE notFound #-} > > > > > > Any idea how to make it faster? > > > > Regards, > > > > Bas > > >

2 2

Mailing lists at haskell.org
by Giovanni Tirloni 04 Nov '11

04 Nov '11

Hi, Does anyone know what's the procedure to create a new mailing list at haskell.org for a forming user group? Thank you, -- Giovanni

2 1

compiler construction
by Timo von Holtz 04 Nov '11

04 Nov '11

Hi, I study computer science in Kiel, Germany and I want to study abroad. Now I look for Universities, which offer compiler construction, since I need that course, preferably in the UK, Ireland, Australia or New Zealand. Ideally it would be in Haskell of course. Greetings Timo

3 2

How to speedup generically parsing sum types?
by Bas van Dijk 04 Nov '11

04 Nov '11

Hello, I recently added default generic implementations of toJSON and parseJSON to the aeson package. Now I'm optimizing them. Here are some benchmark results that compare: * th: toJSON and fromJSON generated by template-haskell. Can be compared to hand-written code. Should be the fastest of all. * syb: toJSON and fromJSON from the Data.Aeson.Generic module. Uses the Data type class. * generic: my toJSON and fromJSON using GHC Generics. The benchmark itself can be found here: https://github.com/basvandijk/aeson/blob/optimizations/benchmarks/AesonComp… toJSON ====== D/toJSON/th 3.631734 us D/toJSON/syb 32.66679 us D/toJSON/generic 3.371868 us BigRecord/toJSON/th 8.982990 us BigRecord/toJSON/syb 48.90737 us BigRecord/toJSON/generic 8.971597 us BigProduct/toJSON/th 1.578259 us BigProduct/toJSON/syb 29.21153 us BigProduct/toJSON/generic 1.623115 us BigSum/toJSON/th 51.81214 ns BigSum/toJSON/syb 1.256708 us BigSum/toJSON/generic 71.32851 ns fromJSON ======== D/fromJSON/th 7.017204 us D/fromJSON/syb 23.46567 us D/fromJSON/generic 7.968974 us BigRecord/fromJSON/th 8.513789 us BigRecord/fromJSON/syb 36.64501 us BigRecord/fromJSON/generic 10.07809 us BigProduct/fromJSON/th 2.430677 us BigProduct/fromJSON/syb 17.97764 us BigProduct/fromJSON/generic 2.201130 us BigSum/fromJSON/th 414.8699 ns BigSum/fromJSON/syb 4.113170 us BigSum/fromJSON/generic 13.62614 us !!! As can be seen, in most cases the GHC Generics implementation is much faster than SYB and just as fast as TH. I'm impressed by how well GHC optimizes the code! Unfortunately the last benchmark, generically parsing a big sum type, is much slower. The code for parsing sums, which can be found here: https://github.com/basvandijk/aeson/blob/optimizations/Data/Aeson/Types/Int… is basically this: instance (GFromSum a, GFromSum b) => GFromJSON (a :+: b) where gParseJSON (Object (M.toList -> [keyVal])) = gParseSum keyVal gParseJSON v = typeMismatch "sum (:+:)" v {-# INLINE gParseJSON #-} class GFromSum f where gParseSum :: Pair -> Parser (f a) instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where gParseSum keyVal = (L1 <$> gParseSum keyVal) <|> (R1 <$> gParseSum keyVal) {-# INLINE gParseSum #-} instance (Constructor c, GFromJSON a, ConsFromJSON a) => GFromSum (C1 c a) where gParseSum (key, value) | key == pack (conName (undefined :: t c a p)) = gParseJSON value | otherwise = notFound $ unpack key {-# INLINE gParseSum #-} notFound :: String -> Parser a notFound key = fail $ "The key \"" ++ key ++ "\" was not found" {-# INLINE notFound #-} Any idea how to make it faster? Regards, Bas

4 7

System calls and Haskell threads
by Andreas Voellmy 04 Nov '11

04 Nov '11

I just read Kazu Yamamoto's article on a high performance web server in the latest Monad.Reader, and I came across a statement that doesn't sound correct to me. He says: "When a user thread issues a system call, a context switch occurs. This means that all Haskell user threads stop, and instead the kernel is given the CPU time. " Is this right? I thought that when a system call is made by a Haskell thread being run by a particular worker thread on a CPU, other runnable Haskell threads in the run queues of the HECs for other CPUs can continue running concurrently (provided we've run our Haskell program with multiple CPUs using the -Nx RTS argument). That's what I understood from the discussion of foreign calls in "Runtime Support for Multicore Haskell". Andreas

3 3

The type class wilderness + Separating instances and implementations into separate packages
by Ryan Newton 03 Nov '11

03 Nov '11

What is the right interface for a queue? What is the right interface for a random number generator? I don't know, but in both cases you will find many packages on hackage offering different takes on the matter. In fact, there is a wilderness of alternative interfaces. We've had various discussions on this list about the number of alternative packages. I'm fine with lots of packages, but I think it would be great if not every package introduced a new interface as well as a new implementation. If we could agree as a community on common interfaces to use for some basics, that would probably go a long way towards taming the type class wilderness. People have mentioned this problem before with respect to "Collections" generally. One basic part of reaching such a goal is separating interface from implementation. I ran into the following problems just in the last 24 hours. In both cases I wanted to use a type class, but didn't want to depend on the whole package it lived in: - I wanted to use the Benchmarkable class in Criterion in my package. (Criterion deserving to be a "standard" package.) But I can't get that typeclass without depending on the whole Criterion package, which has several dependencies. And in fact on the machine I was on at the time some of those dependencies were broken, so I decided not to use Benchmarkable. - I wanted to use, or at least support, an existing class for Queues. I found the following: http://hackage.haskell.org/packages/archive/queuelike/1.0.9/doc/html/Data-M… I have no idea who uses this package. But because this package (like most packages) includes the implementation along with the interface it introduces additional dependency liabilities. In this case it failed to build on GHC 7.2 so I quickly gave up on supporting that TypeClass. How can we enumerate packages that at least purport to provide standard interfaces that you should both use and pick up to implement? On a Wiki page? -Ryan P.S. I'm working on mutable concurrent Deques right now and am trying to follow my own prescription above by creating an abstract interface in a separate package. See below if you would like to offer feedback on that interface. -------------------------------------- My ultimate goal is an "abstract-deque" parameterizable interface that abstracts over bounded/unbounded, concurrent/non-concurrent, single, 1.5, and double-ended queues, which would include both, say, Michael & Scott linked queues and the Chase-Lev work-stealing deques. An aggregated queue package could use type families to dispatch to the best available queue implementation for a given configuration. I've got a couple drafts of how this might work. They're in different branches here: https://github.com/rrnewton/haskell-lockfree-queue/blob/master/AbstractDequ… https://github.com/rrnewton/haskell-lockfree-queue/blob/one-type-class/Abst… One of them uses an associated data type family, the other an unassociated one. The type family has a bunch (six) phantom type parameters, and the unassociated one allows hiding those parameters at the expense of introducing more type classes. MegaQueue.hs will be used to aggregate together different queue implementations. The end result is that someone can create a new queue by setting all the switches on the type, as follows: test = do q :: Deque NT T SingleEnd SingleEnd Bound Safe Int <- newQ pushL q 33 x <- tryPopR q print x return q With those settings, requiring only single-ended rather than double-ended queues, the above code can use the LinkedQueue (Michael and Scott) implementation included in that repo. That little test, by the way, segfaults for me on Mac OS under GHC 7.2.1 even WITHOUT using casMutVar# (It's using Data.CAS.Fake presently.) I'll file a bug report after I sanity check it some more. Disregarding that... the big problem in this case is the* inability to create overlapping type family instances. * In this case what we dearly WANT to do is specialize some subset of the 64-mode configuration space and then have a "fallback". You can take a look at my struggling in MegaDeque. Both of my approaches require specifying explicitly the modes that you don't cover. Worse, we may want to specialize on element type as well. For example, for simple scalar types (or even Storable types) it may be desirable to use something foreign, like TBB queues. But in that case, there's no way to enumerate the types NOT specialized. As far as I know there is no way for type families to accomplish this (specialize, say "Int", and have a fallback for everything else). In general, is there a recognized work-around for this? For example, is this a place where using functional dependencies instead might do the trick? Also, there are some software-engineering issues here with respect to* where to put the instances*. It would be nice to put the instances for DequeClass inside the individual implementations (like LinkedQueue.hs). But that leads to problems because it's really the job of MegaQueue.hs to figure out how to spread implementations over the configuration-space. And once you put the instances in LinkedQueue.hs there is of course *no way to qualify or hide them upon import....* Feedback welcome. Cheers, -Ryan

3 3

Re: [Haskell-cafe] Tell cabal-install to generate only shared libraries
by Yves Parès 03 Nov '11

03 Nov '11

Apparently, disabling library vanilla causes GHC not to generate the ".hi" files : For instance when 'cabal install quickcheck --disable-library-vanilla': Registering QuickCheck-2.4.1.1... cabal: QuickCheck-2.4.1.1: file Test/QuickCheck/All.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Function.hi is missing (use --force to override) [...] override) QuickCheck-2.4.1.1: file Test/QuickCheck/State.hi is missing (use --force to override) QuickCheck-2.4.1.1: file Test/QuickCheck/Exception.hi is missing (use --force to override) QuickCheck-2.4.1.1: cannot find libHSQuickCheck-2.4.1.1.a on library path (use --force to override) 2011/11/3 Ivan Perez <ivanperezdominguez(a)gmail.com> > 2011/11/2 Yves Parès <limestrael(a)gmail.com>: > > Hello, > > > > When I tell cabal-install to build shared libraries (with "Shared: True" > in > > .cabal/config), it doubles the libraries installation time since it > compiles > > them twice, since it seems that is what GHC's flag "-shared" does. > > Is there a way to generate only the .so and not the the .a libs? > > --disable-library-vanilla > > Do not build ordinary libraries. This is useful in conjunction > with --enable-library-profiling > to build only profiling libraries, rather than profiling and > ordinary libraries. > > Haven't tried it myself. Maybe it works in combination with > --enable-shared? > > From: http://haskell.org/ghc/docs/7.0.4/html/Cabal/builders.html > > > > > Furthermore, I have the impression that the executables compiled by > > cabal-install are always linked statically... Can I tell cabal-install to > > activate the GHC's flag "-dynamic" for executables? > > The following two trac tickets mention a separate flag, > named --enable-executable-dynamic: > > http://hackage.haskell.org/trac/hackage/ticket/600 > http://hackage.haskell.org/trac/hackage/ticket/869 > > If that doesn't work, you can probably pass some argument to ghc with > --with-ghc-option > > Cheers, > Ivan > > > > > Thanks. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

2 1

ghc 7.2.1 Generics problem
by Magicloud Magiclouds 03 Nov '11

03 Nov '11

Hi, I do not know why, my ghc 7.2.1 does not seem to support DeriveRepresentable. I compiled the ghc 7.2.1 myself by ghc 7.0.4. All options default. $ ghc Types/TopTalkerRecord.hs Types/TopTalkerRecord.hs:2:14: Unsupported extension: DeriveRepresentable $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.2.1 -- 竹密岂妨流水过山高哪阻野云飞

4 6

Ridiculously slow FFI, or cairo binding?
by Eugene Kirpichov 03 Nov '11

03 Nov '11

Hello, I've got two very simple programs that draw a very simple picture using cairo, doing a couple hundred thousand of cairo calls. One program is in C++. The other is in Haskell and uses the cairo library bindings. The C++ program completes in a fraction of a second, the Haskell program takes about 7-8 seconds to run. They produce exactly the same output. What could be at fault here? Why are the cairo bindings working so slow? (I suppose there isn't too much cairo-specific stuff here, perhaps it's a general FFI question?) #include "cairo.h" int main() { cairo_surface_t *surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1024, 768); cairo_t *cr = cairo_create(surface); cairo_set_source_rgb(cr, 0, 255, 0); for(int x = 0; x < 1024; x += 2) for(int y = 0; y < 768; y += 2) { cairo_rectangle(cr, x, y, 1, 1); cairo_fill(cr); } cairo_surface_write_to_png(surface, "picture.png"); return 0; } module Main where import qualified Graphics.Rendering.Cairo as C import Control.Monad main = C.withImageSurface C.FormatARGB32 1024 768 $ \s -> do C.renderWith s $ do C.setSourceRGBA 0 255 0 255 forM_ [0,2..1024] $ \x -> do forM_ [0,2..768] $ \y -> do C.rectangle x y 1 1 C.fill C.surfaceWriteToPNG s "picture.png" -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

8 22