April 2009 - Libraries

Failure to install time package
by Neil Mitchell 20 Apr '09

20 Apr '09

Hi, Time is an important library, it got unbundled from GHC, and it seems Windows users can't install the time package! C:\Neil\hoogle>cabal install time --global Resolving dependencies... [1 of 1] Compiling Main ( C:\Users\Neil\AppData\Local\Temp\time-1.1. 2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884 \time-1.1.2.3\dist\setup\Main.o ) Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu p\setup.exe ... Configuring time-1.1.2.3... setup.exe: sh: runGenProcess: does not exist (No such file or directory) cabal: Error: some packages failed to install: time-1.1.2.3 failed during the configure step. The exception was: exit: ExitFailure 1 C:\Neil\hoogle>ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.2 My guess is that it would work if I installed mingw, but that it hasn't been tested without. I consider this problem fatally serious - we may have managed to make GHC 6.10.2 unuseable for many Windows users... Thanks Neil

7 16

unix-2.3.2.0 fails to install in ghc 6.10.1
by Ahn, Ki Yung 17 Apr '09

17 Apr '09

kyagrd@kyagrd:~$ uname -a Linux kyagrd 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux kyagrd@kyagrd:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 kyagrd@kyagrd:~$ which ghc /usr/bin/ghc kyagrd@kyagrd:~$ ghc-pkg list /usr/lib/ghc-6.10.1/./package.conf: ALUT-2.1.0.0, Cabal-1.6.0.1, Diff-0.1.2, GLUT-2.1.1.2, HDBC-2.1.0, HDBC-postgresql-2.1.0.1, HGL-3.2.0.0, HUnit-1.2.0.3, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-2.1.0.1, Stream-0.2.2, X11-1.4.5, X11-xft-0.3, array-0.2.0.0, arrows-0.4.1, base-3.0.3.0, base-4.0.0.0, binary-0.5, bytestring-0.9.1.4, cairo-0.10.0, cgi-3001.1.7.1, containers-0.2.0.0, convertible-1.0.2, directory-1.0.0.2, editline-0.2.1.0, fgl-5.4.2.2, filepath-1.1.0.1, gconf-0.10.0, (ghc-6.10.1), ghc-prim-0.1.0.0, gio-0.10.0, glade-0.10.0, glib-0.10.0, gstreamer-0.10.0, gtk-0.10.0, gtkglext-0.10.0, gtksourceview2-0.10.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, hslogger-1.0.8, html-1.0.1.2, integer-0.1.0.0, irc-0.4.3, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-3.0.0, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.93.1, regex-compat-0.92, regex-posix-0.93.1, rts-1.0, soegtk-0.10.0, stm-2.1.1.2, svgcairo-0.10.0, syb-0.1.0.0, syb-with-class-0.5.1, tagsoup-0.6, template-haskell-2.3.0.0, terminfo-0.3.0.1, time-1.1.2.3, unix-2.3.1.0, utf8-string-0.3.4, xhtml-3000.2.0.1, xmonad-0.8.1, xmonad-contrib-0.8.1, zlib-0.5.0.0 /home/kyagrd/.ghc/i386-linux-6.10.1/package.conf: Cabal-1.6.0.1, Cabal-1.6.0.2, HGL-3.2.0.0, HTTP-3001.1.3, HTTP-4000.0.4, HTTP-4000.0.5, InfixApplicative-1.0.1, QuickCheck-1.2.0.0, Stream-0.3.1, arrows-0.4.1, binary-0.5.0.1, cgi-3001.1.7.1, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, ghc-paths-0.1.0.5, haddock-2.4.1, haskell98-1.0.1.0, irc-0.4.3, lazysmallcheck-0.3, network-2.2.0.1, network-2.2.1, old-time-1.0.0.2, parsec-2.1.0.1, process-1.0.1.1, random-1.0.0.1, sparsebit-0.5, terminfo-0.3.0.2, zlib-0.4.0.4, zlib-0.5.0.0 kyagrd@kyagrd:~$ cabal upgrade unix Resolving dependencies... Configuring unix-2.3.2.0... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for an ANSI C-conforming const... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking for string.h... (cached) yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking pty.h usability... yes checking pty.h presence... yes checking for pty.h... yes checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking for getgrgid_r... yes checking for getgrnam_r... yes checking for getpwnam_r... yes checking for getpwuid_r... yes checking for getpwnam... yes checking for getpwuid... yes checking for getpwent... yes checking for getgrent... yes checking for lchown... yes checking for setenv... yes checking for sysconf... yes checking for unsetenv... yes checking for nanosleep... yes checking for ptsname... yes checking for setitimer... yes checking for shm_open in -lrt... yes checking for shm_open... yes checking for shm_unlink... yes checking value of SIGABRT... 6 checking value of SIGALRM... 14 checking value of SIGBUS... 7 checking value of SIGCHLD... 17 checking value of SIGCONT... 18 checking value of SIGFPE... 8 checking value of SIGHUP... 1 checking value of SIGILL... 4 checking value of SIGINT... 2 checking value of SIGKILL... 9 checking value of SIGPIPE... 13 checking value of SIGQUIT... 3 checking value of SIGSEGV... 11 checking value of SIGSTOP... 19 checking value of SIGTERM... 15 checking value of SIGTSTP... 20 checking value of SIGTTIN... 21 checking value of SIGTTOU... 22 checking value of SIGUSR1... 10 checking value of SIGUSR2... 12 checking value of SIGPOLL... 29 checking value of SIGPROF... 27 checking value of SIGSYS... 31 checking value of SIGTRAP... 5 checking value of SIGURG... 23 checking value of SIGVTALRM... 26 checking value of SIGXCPU... 24 checking value of SIGXFSZ... 25 checking value of SIG_BLOCK... 0 checking value of SIG_SETMASK... 2 checking value of SIG_UNBLOCK... 1 checking for _SC_GETGR_R_SIZE_MAX... yes checking for _SC_GETPW_R_SIZE_MAX... yes checking return type of usleep... int checking return type of unsetenv... int checking for RTLD_NEXT from dlfcn.h... no checking for RTLD_DEFAULT from dlfcn.h... no checking for RTLD_LOCAL from dlfcn.h... yes checking for RTLD_GLOBAL from dlfcn.h... yes checking for RTLD_NOW from dlfcn.h... yes checking for openpty... no checking for openpty in -lutil... yes checking for /dev/ptmx... yes checking for /dev/ptc... no checking for dlopen in -ldl... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: creating ./config.status config.status: creating unix.buildinfo config.status: creating include/HsUnixConfig.h Preprocessing library unix-2.3.2.0... Building unix-2.3.2.0... [ 1 of 21] Compiling System.Posix.User ( dist/build/System/Posix/User.hs, dist/build/System/Posix/User.o ) [ 2 of 21] Compiling System.Posix.Unistd ( dist/build/System/Posix/Unistd.hs, dist/build/System/Posix/Unistd.o ) [ 3 of 21] Compiling System.Posix.Time ( dist/build/System/Posix/Time.hs, dist/build/System/Posix/Time.o ) [ 4 of 21] Compiling System.Posix.Resource ( dist/build/System/Posix/Resource.hs, dist/build/System/Posix/Resource.o ) [ 5 of 21] Compiling System.Posix.Process.Internals ( System/Posix/Process/Internals.hs, dist/build/System/Posix/Process/Internals.o ) System/Posix/Process/Internals.hs:10:17: Module `GHC.Conc' does not export `Signal' cabal: Error: some packages failed to install: unix-2.3.2.0 failed during the building phase. The exception was: exit: ExitFailure 1

2 1

Re: cabal: confusing dependencies conflict between ghc-6.10.1 and process
by Duncan Coutts 16 Apr '09

16 Apr '09

On Thu, 2009-04-16 at 10:52 +0200, Martijn van Steenbergen wrote: > Duncan Coutts wrote: > > For future reference this is now in the new Cabal FAQ: > > http://haskell.org/cabal/FAQ.html > > > > which is now linked from the cabal home page. > > Neat. That's gonna be helpful. > > "The default version of the parsec package is version 2.x." > > Is parsec special in this regard? Only slightly special: http://hackage.haskell.org/packages/archive/preferred-versions -- A global set of preferred versions. -- -- This is to indicate a current recommended version, to allow stable and -- experimental versions to co-exist on hackage and to help transitions -- between major API versions. -- -- Tools like cabal-install take these preferences into account when -- constructing install plans. -- base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 Duncan

1 0

strict version of operations on IntMap and IntSet
by Manlio Perillo 14 Apr '09

14 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. - From a discussion I had some time ago on haskell-cafe, it seems that all operations on IntMap and IntSet are lazy. The only exception is `alter`, for IntMap. This can be a problem. As an example, using `fromList` (both from IntMap and IntSet) seems to be rather unfriendly to the garbage collector. Is it possible to have strict variants of the most common operations? Thanks Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknkja0ACgkQscQJ24LbaUThzACffL9JTJv9LqmdZIEJeY9EFobT tZgAnitfwGvaHM+kpOEHX8/mNtnYGVsF =E7+2 -----END PGP SIGNATURE-----

1 0

Broken beyond repair: Control.Concurrent.SampleVar
by ChrisK 13 Apr '09

13 Apr '09

Hello all, The SampleVar module in base is not exception safe. I believe that there is no way to fix this module to be exception safe while retaining the current behavior. The problem with the current behavior is that the writeSampleVar pretends to know how many blocked reader threads are waiting on a value. In reality these blocked threads may have been killed. When writeSampleVar sees blocked threads it does a blocking putMVar and then decrements the blocked reader thread count. If any two of the blocked reader threads ever die then eventually you get a blocked writer. I can find no efficient way to retain the current behavior in the presence of exceptions. The logic of the current behavior is that the blocked readers mean that the previously written value should not be discarded, the previous value belongs to the next blocked reader. I propose that SampleVar be either removed, or replaced with a slightly different exception safe version. I propose not considering the previously written value to belong to a blocked reader, and to replace it with the new value. I will open a ticket about this when I get more time. -- Chris

5 10

ANN: MSem replacement for QSem
by ChrisK 11 Apr '09

11 Apr '09

"Grasshopper, try to take the stone from my hand" Hello all, After looking at the code for QSem [1], I realize it is not exception safe. And it does more work than needed. I have a proposed replacement module MSem at http://haskell.org/haskellwiki/SafeConcurrent on the wiki. I claim this is a safer, more correct, and more efficient replacement for QSem. But I may be tragically wrong which is where you come in. Please try and find some strange concurrency bug that I have missed. Once there is reviewed replacement code I will propose changing the base package. Exception safe replacements for QSemN and SampleVar are also needed. The MSem code I have can be generalized into an "MSemN", but the semantics are be different from "QSemN". This MSemN only considers the needs of the first blocked waiter instead of all of them. The code MSemN is on the same wiki page, perhaps someone will find this variant useful. Cheers, Chris [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Conc…

1 0

Problem with cabal-install
by Giuliano Vilela 10 Apr '09

10 Apr '09

Hello, I'm having a problem installing the cabal-install tool on a linux box. Not sure if this list is the right place do task, but was my only direction coming from here: http://www.haskell.org/cabal/download.html The output of the bootstrap.sh script bundled with cabal-install is bellow: Checking installed packages for ghc-6.10.1... parsec is already installed and the version is ok. network is already installed and the version is ok. Cabal is already installed and the version is ok. HTTP is already installed and the version is ok. zlib is already installed and the version is ok. cleaning... Linking Setup ... Configuring cabal-install-0.6.2... Preprocessing executables for cabal-install-0.6.2... Setup: can't find source for Distribution.Client.BuildReports.Anonymous in ., dist/build/autogen Error during cabal-install bootstrap: Building the cabal-install package failed (Note that those dependency packages are already installed from a previous run of this script) Using GHC version 6.10.1, on a Opensuse 11.0 box: > ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 Anyone has a clue on this one? -- []'s Giuliano Vilela.

2 1

Re: GHC threading bug in QSem
by Chris Kuklewicz 08 Apr '09

08 Apr '09

The code assumes newQsem is never given a negative argument without ever documenting this fact. http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Control-Conc… change not only putMVar sem (0, blocked++[block]) to putMVar sem (avail, blocked++[block]) in waitQSem but also change signalQSem to > signalQSem :: QSemN -> IO () > signalQSem (QSemN sem) = modifyMVar_ free sem > where free (0,(b:bs)) = putMVar b () >> return (0,bs) > free (avail,blocked) = return (avail+1,blocked) Neil: To allow negative values you have to change signalQSem and waitQSem. And really folks, the waitQSem(N) and signalQSem(N) should be exception safe and this is not currently true. They should all be using the modifyMVar_ idiom — currently an exception such as killThread between the take and put will leave the semaphore perpetually empty which is not a valid state. I also hereby lobby that a non-blocking "trySem" be added, and while Control.Concurrent is getting updated I think that Neil's last concurrency puzzle would have been helped by having a non-blocking "tryReadChan" in Control.Concurrent.Chan (note that the isEmptyChan is not useful for making non-blocking read), and how about Control.Concurrent.Pony ? "Control.Concurrent.SampleVar" is also not exception safe. Neil Mitchell wrote: > Hi > > I believe the following program should always print 100: > > import Data.IORef > import Control.Concurrent > > main = do > sem <- newQSem (-99) > r <- newIORef 0 > let incRef = atomicModifyIORef r (\a -> (a+1,a)) > sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem > waitQSem sem > v <- readIORef r > print v > > Unfortunately, it doesn't seem to. Running on a 2 processor machine, > with +RTS -N3 I usually get 100, but have got answers such as 49, 82, > 95. With +RTS -N2 it doesn't seem to fail, but it does with -N4. This > is using GHC 6.10.2 on Windows. Using GHC 6.8.3, I get answers /= 100 > roughly every other time. > >>From reading the implementation of QSem, it doesn't seem that negative > availability was considered. I think it would be need to be changed > as: > > -- Invariant: avail >= 1 ==> null blocked > > waitQSem :: QSem -> IO () > waitQSem (QSem sem) = do > (avail,blocked) <- takeMVar sem -- gain ex. access > if avail > 0 then > putMVar sem (avail-1,[]) > else do > block <- newEmptyMVar > putMVar sem (avail, blocked++[block]) -- changed line > takeMVar block > > signalQSem :: QSem -> IO () > signalQSem (QSem sem) = do > (avail,blocked) <- takeMVar sem > -- changed below > if null blocked || avail < 0 then > putMVar sem (avail+1,blocked) > else > putMVar sem (avail, tail blocked) > putMVar (head blocked) () > > Writing parallel code is hard, so I could have easily got this wrong. > I haven't looked at QSemN, which may need similar fixes (or may > already deal with this) > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

[network] #7: Network.Socket.recv throws IOException on reading 0 bytes
by network 06 Apr '09

06 Apr '09

#7: Network.Socket.recv throws IOException on reading 0 bytes ---------------------+------------------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/3071 ---- My man pages has the following to say about the return value of recv: These calls return the number of bytes received, or -1 if an error occurred. For TCP sockets, the return value 0 means the peer has closed its half side of the connection. This means that it's absolutely fine to read 0 bytes when using e.g. UDP socket. However, the Network.Socket.recv function always throws an exception upon reading 0 bytes regardless of the protocol family. -- Ticket URL: <http://trac.haskell.org/network/ticket/7> network <http://projects.haskell.org/network/> Networking-related facilities

1 2

New maintainer, Darcs repository and Trac for the network library
by Johan Tibell 05 Apr '09

05 Apr '09

Hi, I've taken over the maintainer role for the network library and per Ian's suggestion I've moved the project to community.haskell.org. As a result the Darcs repository and the Trac instance have moved. Here are the new locations: Darcs repository: http://code.haskell.org/network/ Trac: http://trac.haskell.org/network/ Ian and I have migrated most of the active tickets to the new Trac. Please submit bug reports using the above Trac instance instead of the one used for GHC. Discussions about API changes will be conducted on the this mailing list using the same process [1] as before. I'm still not an expert on all parts of the code and I expect that resolving tickets will continue to be a community effort. However, I will be the person the reviewing changes and making (most of) the releases. 1. http://www.haskell.org/haskellwiki/Library_submissions Cheers, Johan

2 2