Re: [Haskell-cafe] Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
On Thu, Mar 17, 2011 at 12:51 AM, C K Kashyap ckkash...@gmail.com wrote: I had started exploring the internal - PS constructor route looking at the base64 encoding implementation by Bryan (which is really fast - http://www.serpentine.com/blog/2010/09/02/fast-base64-encoding-and-decoding-in-haskell/ )- I was wondering if we don't use the PS constructor can we implement base64 encoding that's comparable? I mean, can we create an asymptotically similar implementation? Regards, Kashyap I'm a fan of Data.ByteString.Unsafe.unsafeUseAsCStringLen when I need access to the raw buffer. http://hackage.haskell.org/packages/archive/bytestring/0.9.1.10/doc/html/Data-ByteString-Unsafe.html#v:unsafeUseAsCStringLen Antoine ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
Am 14.03.2011 06:26, schrieb C K Kashyap: Looks like a job for Data.Binary. I'd like to use it with just the libraries that are part of the platform I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple ghc-pkg expose ghc-binary. For future versions of ghc and the platform a single ghc-binary or binary version would be better. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
The ghc-binary package is used internal to GHC, and isn't gauranteed to be present from one version to the next, nor do I expect the GHC team to promise it will have a stable interface. You'd really be better of instaling the package binary, or something similar. On Mar 14, 2011 5:34 AM, Christian Maeder christian.mae...@dfki.de wrote: ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
On 14/03/2011 10:33, Christian Maeder wrote: Am 14.03.2011 06:26, schrieb C K Kashyap: Looks like a job for Data.Binary. I'd like to use it with just the libraries that are part of the platform I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple ghc-pkg expose ghc-binary. For future versions of ghc and the platform a single ghc-binary or binary version would be better. You shouldn't use ghc-binary. It is indeed the same as binary, and is required because GHC uses it internally, but binary is not a platform package so we renamed it to ghc-binary and set it to be hidden by default. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
