Hi. I'm writing a generic log parsing package, and I'm serching a parser combinators library. Parsing log files is a simple task, so I would like to use the more efficient solution. I have looked at attoparsec source code, and it seems very specialized for lazy bytestrings parsing, so I assume it is very efficient. How stable is the attoparsec package? How much more efficient is attoparsec than standard packages like parsec? By the way: there seem to be problems with generated documentation in http://hackage.haskell.org/package/attoparsec. Moreover, there is a similar package: http://hackage.haskell.org/package/bytestringparser what is the status of this package? It has the same API of attoparsec, but its older. However there is no indication that this package is deprecated in favor of attoparsec. Thanks Manlio Perillo
To add to the confusion, I forked `bytestringparser` when I wrote the `json-b` package. The fork is here: http://hackage.haskell.org/package/bytestringparser-temporary/ I have added a number of things to original as well as fixing some problems with it. The reason I went with the older package is that the new one depended on stuff that wouldn't build on Hackage so I was like "whatever"; however, I now consider that it might have been better to work off the newer package. A subtle error, corrected in my version, seems yet to be present in the `attoparsec-0.7.2`, in an operator used internally to build up the result set. {-# LINE 132 "Data/Attoparsec/Internal.hs" #-} -- | Turn our split representation back into a normal lazy ByteString. (+:) :: SB.ByteString -> LB.ByteString -> LB.ByteString sb +: lb | SB.null sb = lb | otherwise = LB.Chunk sb lb Where this operator showed up in `bytestringparser`, I replaced `LB.Chunk` with the smart constructor, `LB.chunk`, to ensure that the "no empty chunks" invariant of lazy `ByteString`s was followed (I discovered this failing one evening when I was fleshing out the JSON parser). -- Jason Dusek
Jason Dusek ha scritto:
To add to the confusion, I forked `bytestringparser` when I wrote the `json-b` package. The fork is here:
http://hackage.haskell.org/package/bytestringparser-temporary/
I have added a number of things to original as well as fixing some problems with it.
The reason I went with the older package is that the new one depended on stuff that wouldn't build on Hackage
I installed attoparsec yesterday without problems.
so I was like "whatever"; however, I now consider that it might have been better to work off the newer package.
A subtle error, corrected in my version, seems yet to be present in the `attoparsec-0.7.2`, in an operator used internally to build up the result set.
{-# LINE 132 "Data/Attoparsec/Internal.hs" #-} -- | Turn our split representation back into a normal lazy ByteString. (+:) :: SB.ByteString -> LB.ByteString -> LB.ByteString sb +: lb | SB.null sb = lb | otherwise = LB.Chunk sb lb
Where this operator showed up in `bytestringparser`, I replaced `LB.Chunk` with the smart constructor, `LB.chunk`, to ensure that the "no empty chunks" invariant of lazy `ByteString`s was followed (I discovered this failing one evening when I was fleshing out the JSON parser).
Did you try to contact the author/maintainer? This test can be added to the test suite. Thanks Manlio
2009/11/15 Manlio Perillo
I installed attoparsec yesterday without problems.
Great; but any package you make with it will also fail to build on Hackage and we won't have browsable docs and so on....
Did you try to contact the author/maintainer?
Yes, I did. However, I was quite keen on releasing my JSON parser in a timely manner; the maintainer was (very reasonably) not on my schedule and I'm not sure my patch was ever applied. -- Jason Dusek
participants (2)
-
Jason Dusek -
Manlio Perillo