June 2012 - Libraries

Re: Proposal: Control.Concurrent.Async
by Sjoerd Visscher 03 Jul '12

03 Jul '12

On Fri, 15 Jun 2012 09:07:54 0100, Simon Marlow <marlowsd(a)gmail.com> wrote: > I still need to ponder the Applicative version, I'm not familiar with > Control.Newtype. I would still like the Traversable abstraction I > mentioned in my last message. Control.Newtype is not important. I added it just to be able to write ala' Concurrently traverse getURL urls instead of runConcurrently $ traverse (Concurrently . getURL) urls But it is probably nicer to have doConcurrently :: Traversable t => (a -> IO b) -> t a -> IO (t b) then you could write doConcurrently getURL urls and your doConcurrently would just be "doConcurrently id". I updated the code at https://gist.github.com/2926572 greetings, Sjoerd

2 2

Proposal: Remove Data.HashTable from base
by Ian Lynagh 30 Jun '12

30 Jun '12

Hi all, Historically, Data.HashTable has been in base because Data.Typeable used it, but that is no longer the case. I propose that we: * Mark it as deprecated in the base that comes with GHC 7.6. * Remove it from the base that comes with GHC 7.8. Rationale: * Historically there have been performance problems with it, and we have been recommending people not to use it. I'm not sure if that's still the case or not. * If it is still useful then it would fit better in the containers package. However, as there is no reason that it needs to be tied to the GHC release schedule etc, it would be even better to put it in another package. In GHC, deSugar/Coverage.lhs does use the module, but only for hashString. We could put this elsewhere in base, but I think it would be better just to copy the definition into the GHC source. Suggested discussion deadline: Fri 29 June 2012. Thanks Ian

8 7

Proposal: add Data.Data instances for Foreign.C.Types
by Ryan Newton 29 Jun '12

29 Jun '12

I recently was wanting to use SYB for an AST datatype which includes constants like CDouble/CFloat. Currently Data.Data exports Int8...Int64 and Word instances, but no instances for Foreign.C.Types: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Data.html Is there any reason these instances should not be exported by Data.Data? The proposal here is simply to add them. It's just a matter of copy-pasting the existing instances and I can provide the patch. -Ryan

2 1

Proposal: Add getFullProgName
by Johan Tibell 26 Jun '12

26 Jun '12

Hi, getProgName is only useful in case you want to print the program name to the screen. You cannot actually use it to do anything interesting programmatically (like execv:ing the program.) I suggest we add getFullProgName which does the sensible thing of returning argv[0]. Here's an implementation: getFullProgName :: IO String getFullProgName = alloca $ \ p_argc -> alloca $ \ p_argv -> do getFullProgArgv p_argc p_argv peek p_argv >>= peek >>= peekCString foreign import ccall unsafe "getFullProgArgv" getFullProgArgv :: Ptr CInt -> Ptr (Ptr CString) -> IO () Discussion deadline: 2 weeks -- Johan

16 39

ANNOUNCE: dbus 0.10
by John Millikin 23 Jun '12

23 Jun '12

This is completing the merger of the "dbus-core" and "dbus-client" packages. The new package does everything they can do, but better. Hackage: http://hackage.haskell.org/package/dbus Homepage: https://john-millikin.com/software/haskell-dbus/ API reference: https://john-millikin.com/software/haskell-dbus/reference/haskell-dbus/0.10/ Examples: Included in the tarball, and also at https://john-millikin.com/branches/haskell-dbus/0.10/head:/examples/ Notable changes: * The module hierarchy was simplified. Most users will only ever need the "DBus" and "DBus.Client" modules. * Exports which were not used or useful have been removed. * Much better documentation -- most exports now have a description, and several have examples. * The source code isn't "literate" any more. Too many people expressed frustration at trying to contribute, so I just converted it all to standard flat .hs files. * Better support for custom socket transports and authentication mechanisms. * Added support for listening for socket connections. This allows users to implement both sides of a peer-peer session. * Various improvements to performance, including moving from "binary" to "cereal". * Various minor improvements to correctness.

1 0

Patch: add ByteString.Unsafe.unsafePackMallocCStringLen
by Lauri Alanko 20 Jun '12

20 Jun '12

Hello. There's a minor lapse in Data.ByteString.Unsafe: unsafePackMallocCString, unlike the other unsafePack* -functions, doesn't have a variant with an explicit length. This is useful when interfacing with C libraries that return a blob of binary data that the caller must free. Attached is a darcs patch that adds it. Lauri

2 1

Re: The vector-random package regression
by Don Stewart 16 Jun '12

16 Jun '12

Repos at code.haskell.org/~dons/code On Saturday, June 16, 2012, Antoine Latter wrote: > FYI - I don't know if you actively follow the libraries list. > > > ---------- Forwarded message ---------- > From: Dominic Steinitz <idontgetoutmuch(a)googlemail.com <javascript:;>> > Date: Sat, Jun 16, 2012 at 6:52 AM > Subject: Re: The vector-random package regression > To: Henning Thielemann <lemming(a)henning-thielemann.de <javascript:;>> > Cc: libraries(a)haskell.org <javascript:;> > > > On 10/06/2012 16:37, Henning Thielemann wrote: > > > > > > On Sun, 10 Jun 2012, Dominic Steinitz wrote: > > > >> I'm not sure if this is a recent regression but I just installed the > Haskell Platfom 2012.2. The email for the maintainer dons(a)galois.com<javascript:;>(Don Stewart) no longer seems to be valid. > > > > > > As far as I know, earlier versions of GHC didn't check for unused INLINE > pragmas. > > That was relatively easy to fix but I don't think I can submit a patch > as there is no repository for the code and the email of the maintainer > is no longer valid. > > I am probably using the package incorrectly but worse, for some types > it does not seem to generate random values - see below. I don't think > there's anyway of submitting a bug report; I'm reporting it here so > there is at least some awareness there might be a problem. > > Dominic. > > > > import qualified Data.Vector.Unboxed as U > > import System.Random.Mersenne.Pure64 > > import qualified Data.Vector.Random.Mersenne as G > > main = do > > h <- newPureMT > > let b = G.randoms h 10 :: U.Vector Bool > > print b > > > > *Main> main > > fromList [True,True,True,True,True,True,True,True,True,True] > > > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <javascript:;> > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Re[2]: [web-devel] FilePath in WAI
by Bulat Ziganshin 16 Jun '12

16 Jun '12

Hello Vagif, Saturday, June 16, 2012, 2:00:14 AM, you wrote: 1. Currently, filenames are stored as String requiring serializaton to UTF-16 on Windows and (usually) to UTF-8 on Unixes. With Filename=ByteString it will be `id` on Unixes and utf-to-utf conversion on Windows. Actually, it will became much faster on BOTH platforms 2. System calls usually have such large overhead than even conversion from String doesn't have any srious impact on performance. For example, i can open about 10k files/sec and find about 100k files/sec 3. The real difference will be, though, in the operations involving filenames but not requiring system calls. For example, file caching 4. We don't need only to store filenames, but to perform various operations on them. So it's probably better to store filenames in efficient and easy to operation way, leaving all conversions to syscall-shells. since from the user perspective filenames are just strings, the String or Text type looks like the best fit 5. Making its own file manipulation library for the needs of web servers looks like too expensive solution. If we really need this faster library, it may be proposed as general purpose Haskell library 6. Ideally, we should have Unix/Windows/...-specific libraries dealing with files using native filename representation and higher-level universal library, hiding OS differences and in particular converting native filenames from/to String and Text filename representation > Considering that we are talking about the web server, it would be safe to > assume that most people would not run it on windows for production use. > So i say WAI should switch to ByteString, and let the windows users be > penalized just a little bit. You can't please everyone. > On Friday, June 15, 2012 02:47:15 PM Johan Tibell wrote: >> On Fri, Jun 15, 2012 at 2:41 PM, Greg Weber <greg(a)gregweber.info> wrote: >> > The ticket would be to switch the standard libraries to use >> > system-filepath, which probably requires a mailing list discussion >> > somewhere, a lot of boring changes of code, and a more inconvenient >> > API for end users. I will wait for Text to become standardized first >> > >> > :) >> >> The FilePath issue has been discussed at length before. The problem is >> that different OS:es define file paths to be different things (i.e. >> Unicode or bytes.) The FilePath type somehow has to bridge that, that >> will be difficult. My main grip with FilePath right now is that it's >> not an abstract type. >> >> -- Johan >> >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

The vector-random package regression
by Dominic Steinitz 16 Jun '12

16 Jun '12

I'm not sure if this is a recent regression but I just installed the Haskell Platfom 2012.2. The email for the maintainer dons(a)galois.com (Don Stewart) no longer seems to be valid. Dominic. Tests-MacBook-Pro:R Test$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 Tests-MacBook-Pro:R Test$ cabal install vector-random Resolving dependencies... Configuring vector-random-0.2... Building vector-random-0.2... Preprocessing library vector-random-0.2... [1 of 1] Compiling Data.Vector.Random.Mersenne ( Data/Vector/Random/Mersenne.hs, dist/build/Data/Vector/Random/Mersenne.o ) Data/Vector/Random/Mersenne.hs:85:5: The INLINE pragma for default method `random' lacks an accompanying binding cabal: Error: some packages failed to install: vector-random-0.2 failed during the building phase. The exception was: ExitFailure 1

3 3

Re: Proposal/Patch: Add findSublistIndex in Data.List
by Henning Thielemann 16 Jun '12

16 Jun '12

On Sat, 16 Jun 2012, Carlos López Camey wrote: >> How about: >> >> findIndex (isPrefixOf "def") $ tails "abcdefgh" > > I find that much better :-) Maybe we could add advanced uses of functions from Data.List to their Haddock documentation. But where to add this example? To 'isPrefixOf' or 'findIndex' or 'tails'? Or you might setup a HaskellWiki page listing such examples.

2 1