Re: [Haskell-cafe] ghc 7.2.1 Generics problem
2011/11/1 José Pedro Magalhães : > Oh, right, I see that some things on that page need updating; I'll do so. > > Thanks, > Pedro > > On Tue, Nov 1, 2011 at 09:33, Magicloud Magiclouds > wrote: >> >> On Tue, Nov 1, 2011 at 1:59 PM, Andres Löh >> wrote: >> > 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 >> > >> > There's no extension of that name in 7.2.1. Do you mean DeriveGeneric? >> > >> > Cheers, >> > Andres >> > >> >> I do not know. I will try that. >> I got the name from http://www.haskell.org/haskellwiki/Generics. >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > Thank you. I saw the page was updated. So I followed the document. And got stuck again. Copying the code and compile, I got: 25instance (GSerialize a) => GSerialize (M1 i a) where 26 gput (M1 x) = gput x test.hs:25:40: `M1 i a' is not applied to enough type arguments The first argument of `GSerialize' should have kind `* -> *', but `M1 i a' has kind `(* -> *) -> * -> *' In the instance declaration for `GSerialize (M1 i a)' -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc 7.2.1 Generics problem
Thanks, you spotted another mistake on that page, I corrected it. Make sure to have a look at the functions in http://hackage.haskell.org/package/generic-deriving too; I'm sure those compile :-) Pedro 2011/11/3 Magicloud Magiclouds > 2011/11/1 José Pedro Magalhães : > > Oh, right, I see that some things on that page need updating; I'll do so. > > > > Thanks, > > Pedro > > > > On Tue, Nov 1, 2011 at 09:33, Magicloud Magiclouds > > wrote: > >> > >> On Tue, Nov 1, 2011 at 1:59 PM, Andres Löh > >> wrote: > >> > 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 > >> > > >> > There's no extension of that name in 7.2.1. Do you mean DeriveGeneric? > >> > > >> > Cheers, > >> > Andres > >> > > >> > >> I do not know. I will try that. > >> I got the name from http://www.haskell.org/haskellwiki/Generics. > >> > >> -- > >> 竹密岂妨流水过 > >> 山高哪阻野云飞 > >> > >> ___ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > Thank you. I saw the page was updated. > So I followed the document. And got stuck again. > > Copying the code and compile, I got: > > 25instance (GSerialize a) => GSerialize (M1 i a) where > 26 gput (M1 x) = gput x > > test.hs:25:40: >`M1 i a' is not applied to enough type arguments >The first argument of `GSerialize' should have kind `* -> *', >but `M1 i a' has kind `(* -> *) -> * -> *' >In the instance declaration for `GSerialize (M1 i a)' > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?
Hi,
The actual thanks for tracking this down go to Vincent Hanquez for finding
that we're doing a lot of gmp calls (and for making me aware of ltrace),
and to Felipe Lessa for finding that this is caused by poor code generated
for cFloatConv :)
Your changes look identical to those that I made in my copy.
On Thu, Nov 3, 2011 at 11:41 AM, Axel Simon wrote:
> Hi Eugene,
>
>
> On 02.11.2011, at 17:34, Eugene Kirpichov wrote:
>
> Heh.
>>
>> Guess what!
>> A simple {-# INLINE cFloatConv #-} helped to the same extent!
>>
>> Axel, I think this change should be pretty easy to incorporate, and it
>> probably makes sense to inline all other functions in Types.chs too.
>>
>>
> I've added INLINE pragmas to all these odd c2hs marshalling functions.
> Could you pull and check if I've done it correctly?
>
> Thanks for tracking this down!
>
> Axel
>
>
> Would you like me to send the trivial darcs patch or the gtk2hs team
>> will take care of this?
>>
>> On Wed, Nov 2, 2011 at 7:29 PM, Felipe Almeida Lessa
>> wrote:
>>
>>> On Wed, Nov 2, 2011 at 11:24 AM, Jean-Marie Gaillourdet
>>> wrote:
>>>
Hi Eugene,
did you try using the SPECIALIZE pragma? It is part of the Haskell 98
and Haskell 2010 specifications.
>>>
>>> I don't think it's going to make any difference, as the core already
>>> have an specialized poor version. See my first e-mail.
>>>
>>> --
>>> Felipe.
>>>
>>>
>>
>>
>> --
>> Eugene Kirpichov
>> Principal Engineer, Mirantis Inc. http://www.mirantis.com/
>> Editor, http://fprog.ru/
>>
>
>
--
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to speedup generically parsing sum types?
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/AesonCompareAutoInstances.hs
toJSON
==
D/toJSON/th 3.631734 us
D/toJSON/syb32.66679 us
D/toJSON/generic3.371868 us
BigRecord/toJSON/th 8.982990 us
BigRecord/toJSON/syb48.90737 us
BigRecord/toJSON/generic8.971597 us
BigProduct/toJSON/th1.578259 us
BigProduct/toJSON/syb 29.21153 us
BigProduct/toJSON/generic 1.623115 us
BigSum/toJSON/th51.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/Internal.hs#L1059
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tell cabal-install to generate only shared libraries
You are absolutely right, they do not seem to play along very well. Here's what I tried: $ cabal install --disable-library-vanilla --enable-shared ranges Resolving dependencies... Configuring ranges-0.2.4... Preprocessing library ranges-0.2.4... Building ranges-0.2.4... [1 of 1] Compiling Data.Ranges ( Data/Ranges.hs, dist/build/Data/Ranges.dyn_o ) Data/Ranges.hs:74:7: Warning: This binding for `x' shadows the existing binding bound at Data/Ranges.hs:72:13 cabal: : Failed to load interface for `Data.Ranges': Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: ranges-0.2.4 failed during the building phase. The exception was: ExitFailure 1 2011/11/3 Yves Parès : > 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 >> >> 2011/11/2 Yves Parès : >> > 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@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
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
> 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/AesonCompareAutoInstances.hs
>
> toJSON
> ==
>
> D/toJSON/th 3.631734 us
> D/toJSON/syb32.66679 us
> D/toJSON/generic3.371868 us
>
> BigRecord/toJSON/th 8.982990 us
> BigRecord/toJSON/syb48.90737 us
> BigRecord/toJSON/generic8.971597 us
>
> BigProduct/toJSON/th1.578259 us
> BigProduct/toJSON/syb 29.21153 us
> BigProduct/toJSON/generic 1.623115 us
>
> BigSum/toJSON/th51.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/Internal.hs#L1059
>
> 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
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
2011/11/3 José Pedro Magalhães :
> - Compile with -O2 and -fno-spec-constr-count (this last one is particularly
> important)
I already compiled with -O2. Adding -fno-spec-constr-count does not
change the results.
> - Add {-# INLINE [1] #-} pragmas to the to/from methods of your Generic
> instances.
I tried:
BigSum/toJSON/generic goes from 70 ns to 52 ns! So inlining 'from' is
an improvement.
Unfortunately BigSum/fromJSON/generic stays at 13 us.
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The type class wilderness + Separating instances and implementations into separate packages
> I think the best option at the moment is to break out type classes in their> > own packages. That's what I did with hashable. Indeed! I greatly believe in this mantra now. Really, my point was only this banal one -- packages with only interfaces in them have no dependencies and are much less likely than implementation packages to break when the GHC version changes. > Aside: The problem with collections is that we don't have the programming > language means to do this well yet (although soon!). The issue is that we > want to declare a type class where the context of the methods depends on the > instance e.g. > class MapLike m where > type Ctx :: Context -- Can't do this today! > insert Ctx => k -> v -> m -> m > Java et all cheats in their container hierarchy by doing unsafe casts (i.e. > they never solved this problem)! Ah, interesting. Is there a proposal to do this? While we need to avoid an infinite regress of generalization and abstraction (type programming => kind programming?, etc) -- it does seem like class contexts on types and type class instances themselves would be nice to have *some* control over. (In the above message, for example I was having trouble due to not being able to hide instances on import.) > I would hope that we could get all the important interfaces into the Haskell > Platform eventually (and have all packages there use them). +1! Cheers, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
For those who find this interesting. Here's the code of the BigSum benchmark
with a manual Generic instance with inlined 'from' and 'to':
https://gist.github.com/1336426
José, I was thinking about the following idea. Say GHC generates the
following instance for BigSum:
instance Generic BigSum where
type Rep BigSum = D1 D1BigSum SumOfBigSum
...
type SumOfBigSum =
( ( (C1 C1_0BigSum U1
:+: (C1 C1_1BigSum U1 :+: C1 C1_2BigSum U1)
)
:+: (C1 C1_3BigSum U1
:+: (C1 C1_4BigSum U1 :+: C1 C1_5BigSum U1)
)
)
:+: ( (C1 C1_6BigSum U1
:+: (C1 C1_7BigSum U1 :+: C1 C1_8BigSum U1)
)
:+: (C1 C1_9BigSum U1
:+: (C1 C1_10BigSum U1 :+: C1 C1_11BigSum U1)
)
)
)
:+: ( ( (C1 C1_12BigSum U1
:+: (C1 C1_13BigSum U1 :+: C1 C1_14BigSum U1)
)
:+: (C1 C1_15BigSum U1
:+: (C1 C1_16BigSum U1 :+: C1 C1_17BigSum U1)
)
)
:+: ( (C1 C1_18BigSum U1
:+: (C1 C1_19BigSum U1 :+: C1 C1_20BigSum U1)
)
:+: ( (C1 C1_21BigSum U1 :+: C1 C1_22BigSum U1)
:+: (C1 C1_23BigSum U1 :+: C1 C1_24BigSum U1)
)
)
)
It also generates the following function (or method): (I haven't
figured out the correct type yet. A correct version might need to use
type families or functional dependencies)
conPath :: String -> Maybe (C1 ? ? ? -> SumOfBigSum)
conPath "F01" = Just $ L1 . L1 . L1 . L1
conPath "F02" = Just $ L1 . L1 . L1 . R1 . L1
conPath "F03" = Just $ L1 . L1 . L1 . R1 . R1
conPath "F04" = Just $ L1 . L1 . R1 . L1
conPath "F05" = Just $ L1 . L1 . R1 . R1 . L1
conPath "F06" = Just $ L1 . L1 . R1 . R1 . R1
conPath "F07" = Just $ L1 . R1 . L1 . L1
conPath "F08" = Just $ L1 . R1 . L1 . R1 . L1
conPath "F09" = Just $ L1 . R1 . L1 . R1 . R1
conPath "F10" = Just $ L1 . R1 . R1 . L1
conPath "F11" = Just $ L1 . R1 . R1 . R1 . L1
conPath "F12" = Just $ L1 . R1 . R1 . R1 . R1
conPath "F13" = Just $ R1 . L1 . L1 . L1
conPath "F14" = Just $ R1 . L1 . L1 . R1 . L1
conPath "F15" = Just $ R1 . L1 . L1 . R1 . R1
conPath "F16" = Just $ R1 . L1 . R1 . L1
conPath "F17" = Just $ R1 . L1 . R1 . R1 . L1
conPath "F18" = Just $ R1 . L1 . R1 . R1 . R1
conPath "F19" = Just $ R1 . R1 . L1 . L1
conPath "F20" = Just $ R1 . R1 . L1 . R1 . L1
conPath "F21" = Just $ R1 . R1 . L1 . R1 . R1
conPath "F22" = Just $ R1 . R1 . R1 . L1 . L1
conPath "F23" = Just $ R1 . R1 . R1 . L1 . R1
conPath "F24" = Just $ R1 . R1 . R1 . R1 . L1
conPath "F25" = Just $ R1 . R1 . R1 . R1 . R1
conPath _ = Nothing
conPath is given the name of the constructor. If it's a valid name it
will return a function that constructs a SumOfBigSum given the
corresponding constructor. Of course, since the types of the
constructors can vary (not in this case) coming up with a correct
implementation is a challenge.
Using conPath in my gParseJSON is easy:
instance (GFromJSON a, GFromJSON b) => GFromJSON (a :+: b) where
gParseJSON (Object (M.toList -> [(key, val)])) =
case conPath key of
Nothing -> mzero
Just path -> path <$> gParseJSON val
gParseJSON v = typeMismatch "sum (:+:)" v
{-# INLINE gParseJSON #-}
I suspect this to be much more efficient.
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The type class wilderness + Separating instances and implementations into separate packages
On 3 November 2011 14:56, Ryan Newton wrote: >> Aside: The problem with collections is that we don't have the programming >> language means to do this well yet (although soon!). The issue is that we >> want to declare a type class where the context of the methods depends on the >> instance e.g. >> class MapLike m where >> type Ctx :: Context -- Can't do this today! >> insert Ctx => k -> v -> m -> m >> Java et all cheats in their container hierarchy by doing unsafe casts (i.e. >> they never solved this problem)! > > Ah, interesting. Is there a proposal to do this? Even better: it's already implemented by Max Bolingbroke and will be in ghc-7.4! See: http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11 So be patient and wait for your Christmas present ;-) Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
* syb: toJSON and fromJSON from the Data.Aeson.Generic module. Uses the Data type class. .. 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! Not that it matters much if you're going with other tools, but your SYB code has a long linear chain of type rep comparisons, at every level of the recursive traversals. That is partially inherent in the SYB design (reducing everything to cast), but could probably be improved? Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
2011/11/3 Claus Reinke : > Not that it matters much if you're going with other tools, but your SYB code > has a long linear chain of type rep comparisons, at every > level of the recursive traversals. That is partially inherent in the SYB > design (reducing everything to cast), but could probably be improved? I'm not an expert on the SYB code. So if you have an idea how to improve it please file a ticket or even better send a pull request. Cheers, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] cereal-0.3.4.0
Hi Everyone, I'm happy to announce version 0.3.4.0 of the cereal serialization library. This release includes a patch from Adam Foltzer to provide support for IEEE754 encoded Float/Double values. This functionality is exposed through Serialize instances for both types, and specialized get/put functions in the new Data.Serialize.IEEE754 module. Happy hacking! --trevor smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System calls and Haskell threads
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is generic information dumpable?
Hi, I am learning the new generic feature of ghc. I'd have to say, it is harder than template to enter. When I started to learn template, ghc -ddump-slices really helped. So I wonder if I could get the representation generated when deriving Generic. I think that would be a great help. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System calls and Haskell threads
On Thu, Nov 3, 2011 at 8:35 AM, Andreas Voellmy wrote: > 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". > That's correct. Blocking syscalls will not prevent other Haskell threads from running. IIRC it will block the OS thread used to run the Haskell thread making the blocking syscall, but the RTS always has one free OS thread (i.e. it will allocated more if needed) that it can use to continue running other Haskell threads with. Your best reference is probably "Extending the Haskell Foreign Function Interface with Concurrency". -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is generic information dumpable?
"-ddump-deriv" will print (most of) it. Cheers, Pedro On Thu, Nov 3, 2011 at 16:26, Magicloud Magiclouds < magicloud.magiclo...@gmail.com> wrote: > Hi, > I am learning the new generic feature of ghc. I'd have to say, it is > harder than template to enter. > When I started to learn template, ghc -ddump-slices really helped. > So I wonder if I could get the representation generated when deriving > Generic. I think that would be a great help. > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
On 03/11/11 11:16, Bas van Dijk wrote:
...
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 #-}
Perhaps relying on Attoparsec backtracking for picking out the right
alternative from the sum is the problem. You could try it with Maybe:
class GFromSum f where
gParseSum :: Pair -> Maybe (Parser (f a))
instance (Constructor c, GFromJSON a, ConsFromJSON a)
=> GFromSum (C1 c a) where
gParseSum (key, value)
| key == pack (conName (undefined :: t c a p))
= Just (gParseJSON value)
| otherwise = Nothing
instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where
gParseSum keyVal = (fmap L1 <$> gParseSum keyVal)
<|> (fmap R1 <$> gParseSum keyVal)
{-# INLINE gParseSum #-}
instance (GFromSum a, GFromSum b) => GFromJSON (a :+: b) where
gParseJSON (Object (M.toList -> [keyVal]))
| Just p <- gParseSum keyVal -> p
gParseJSON v = typeMismatch "sum (:+:)" v
Twan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] compiler construction
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System calls and Haskell threads
On Thu, Nov 3, 2011 at 8:35 AM, Andreas Voellmy wrote: > 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? > It is correct in context. Mighttpd does not use the -Nx argument to create multiple OS threads, instead uses a `prefork` model that creates separate processes to balance user invocations. Using multiple processes instead of multiple Haskell threads avoids issues with garbage collection. Regards, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] System calls and Haskell threads
On Thu, Nov 3, 2011 at 10:22 AM, David Barbour wrote: > It is correct in context. Mighttpd does not use the -Nx argument to create > multiple OS threads, instead uses a `prefork` model that creates separate > processes to balance user invocations. Using multiple processes instead of > multiple Haskell threads avoids issues with garbage collection. > I should rephrase that: using multiple processes in place of -Nx threads avoids issues with GC. Mighttpd does use multiple Haskell threads per Haskell process. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to speedup generically parsing sum types?
On 3 November 2011 17:38, Twan van Laarhoven wrote: > Perhaps relying on Attoparsec backtracking for picking out the right > alternative from the sum is the problem. You could try it with Maybe: Good idea. I implemented and committed it and the BigSum/fromJSON/generic benchmark goes from 13.6 us to 11.3 us. Still a lot slower than the 4.1 us of SYB or the 414.9 ns of TH but an improvement nonetheless. Thanks for the idea! Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] compiler construction
Hi Timo, > 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. > I currently work in a research group that is well known for their compiler construction research. You may have heard of UHC, the Utrecht Haskell Compiler [1]? If not, you should look into it. We have a master's course on compiler construction [2] taught by one of the architects [3] of UHC. There is even a second Haskell-ish compiler, Helium [4], that has shone the way towards better error messages. The people [5] in the Software Technology group [6] at Utrecht University do a lot of other interesting work, too. The topics include functional programming, generic programming, dependently typed programming, parser combinators, static analysis, type systems, etc. UU is based in the Netherlands, not one of the English-speaking locations you seem to prefer. But the lingua franca here is English and there are students and staff from all over, so it can seem like a "more foreign" place at times. We're happy to have more students interested in pushing the boundaries of language research. Regards, Sean [1] http://www.cs.uu.nl/wiki/UHC [2] http://www.cs.uu.nl/wiki/Cco [3] http://www.cs.uu.nl/wiki/Atze [4] http://www.cs.uu.nl/wiki/Helium [5] http://www.cs.uu.nl/wiki/Center/People [6] http://www.cs.uu.nl/wiki/Center ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] compiler construction
Chalmers University in Gothenburg, Sweden has a master's programme that includes a compiler construction course. For the lectures from last term, see: http://www.cse.chalmers.se/edu/course/TDA282/lectures.html When I took it in 2006 it was a very practical course -- your task was to implement a basic compiler and the final grade was based on the number of features you implemented. You could choose to do it in Haskell, Java or C++. The master's course is "Secure and Dependable Computer Systems" and takes 2 years. You could also become an exchange student at Chalmers via Erasmus, but the course is only given once a year, so if you plan to do a 6 month exchange then you have to time it right. Of course, Chalmers is in Sweden and therefore in none of your preferred countries. However, all MSc courses are taught in English and almost everyone in Sweden speaks English very well. Learning Swedish also isn't very difficult if you're (I assume) German. If you stick to it, you can be fluent in 6 months (I didn't, but I can read a lot of Swedish). As an alternative in the UK, you might consider Nottingham University. They too have a strong FP research group and their compiler construction course seems to use Haskell as well: http://www.cs.nott.ac.uk/~nhn/G53CMP/ Other Universities in your preferred countries you might want to check out (though I don't know anything about their taught programs), they are known to have FP researchers: - UNSW, Sydney - Oxford, England - Edinburgh Univ. or Harriot Watts (though HW is more O'Caml/SML) - Univ. of St. Andrews, Scotland - Univ. of Strathclyde, Glasgow, Scotland - Leicester, England (teaches Haskell to undergrads, not sure about compiler constr.) - Imperial College, London - University College London (UCL) - (there're probably more...) On 3 November 2011 17:02, Timo von Holtz wrote: > 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 > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mailing lists at haskell.org
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mailing lists at haskell.org
On 3 November 2011 23:11, Giovanni Tirloni wrote: > Does anyone know what's the procedure to create a new mailing list at > haskell.org for a forming user group? community.haskell.org provides MailMan mailing lists: Cheers, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is generic information dumpable?
2011/11/3 José Pedro Magalhães :
> "-ddump-deriv" will print (most of) it.
But it doesn't print the most useful piece of information: the
definition of Rep.
It would be great if this could be added.
Currently when I have a type that I want to know the Rep of, say:
data Foo = Bar Int
| Boo {hello :: String}
deriving Generic
I just convert it to a Rep and show it:
err = show $ from $ Boo "World"
However Reps don't have Show instances so GHC complains:
No instance for
(Show (D1 D1Foo ( C1 C1_0Foo (S1 NoSelector (Rec0 Int))
:+: C1 C1_1Foo (S1 S1_1_0Foo (Rec0 String))
)
x0
)
)
arising from a use of `show'
And there you go. This is the only time when I'm happy to see an error
message :-)
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is generic information dumpable?
Hi, 2011/11/3 Bas van Dijk > 2011/11/3 José Pedro Magalhães : > > "-ddump-deriv" will print (most of) it. > > But it doesn't print the most useful piece of information: the > definition of Rep. > Yes... I am aware of this. > > It would be great if this could be added. > I'll do it. Cheers, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is generic information dumpable?
2011/11/4 José Pedro Magalhães : > Hi, > > 2011/11/3 Bas van Dijk >> >> 2011/11/3 José Pedro Magalhães : >> > "-ddump-deriv" will print (most of) it. >> >> But it doesn't print the most useful piece of information: the >> definition of Rep. > > Yes... I am aware of this. > >> >> It would be great if this could be added. > > I'll do it. > > > Cheers, > Pedro > > > Great, thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
> I have interfaced Erlang and Haskell... And delivered it as a product. I > just came up with a dead-simple text based communication syntax from Erlang > to Haskell that was very easily testable. It allowed for complete isolation Interesting. I can't imagine there are too many people who have done this. So I must ask -- given the explicit attempt to imitate Erlang in recent CloudHaskell work, does that come close to giving you everything you would have wanted in this app? (Hot code update being the big missing piece.) Cheers, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 99, Issue 9
On 4 November 2011 16:21, yrazes wrote: > Hi > This is a very simple basic case, but I have a little trouble with this... I > hope somebody can help me First of all, it would help if you said what your actual trouble is. > main :: IO() > main = return :: f The "return :: f" bit here doesn't make any sense: * :: is used in type signatures, not as an operator in code; you shouldn't need it (assuming your definition of f below is meant to be there). > tipos :: Int -> Int -> Int -> Float > tipos a b c > f = b / a * c > where > (a,b,c) = (8,3,15) Your definition of tipos isn't complete... what you've actually defined is a new top-level value `f' (which is of type Fractional a => a). You need to actually have "tipos a b c" _equal_ something. Now, if you want to calculate "b/a*c" for inputs a, b and c, try something like this: import System.Environment(getArgs) main :: IO () main = do [a,b,c] <- getArgs print $ tipos (read a) (read b) (read c) tipos :: Int -> Int -> Int -> Double tipos a b c = fromIntegral b / fromIntegral b * fromIntegral c -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 99, Issue 9
Thank you so much Ivan!!! main :: IO ( ) main = let a = 8 b = 3 c = 15 in print(b / a * c) This code works!!! :) Julita On Fri, Nov 4, 2011 at 12:53 AM, Ivan Lazar Miljenovic < ivan.miljeno...@gmail.com> wrote: > On 4 November 2011 16:21, yrazes wrote: > > Hi > > This is a very simple basic case, but I have a little trouble with > this... I > > hope somebody can help me > > First of all, it would help if you said what your actual trouble is. > > > main :: IO() > > main = return :: f > > The "return :: f" bit here doesn't make any sense: > > * :: is used in type signatures, not as an operator in code; you > shouldn't need it (assuming your definition of f below is meant to be > there). > > > tipos :: Int -> Int -> Int -> Float > > tipos a b c > > f = b / a * c > > where > > (a,b,c) = (8,3,15) > > Your definition of tipos isn't complete... what you've actually > defined is a new top-level value `f' (which is of type Fractional a => > a). You need to actually have "tipos a b c" _equal_ something. > > Now, if you want to calculate "b/a*c" for inputs a, b and c, try > something like this: > > import System.Environment(getArgs) > > main :: IO () > main = do [a,b,c] <- getArgs > print $ tipos (read a) (read b) (read c) > > tipos :: Int -> Int -> Int -> Double > tipos a b c = fromIntegral b / fromIntegral b * fromIntegral c > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
