- Libraries - Haskell.org

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

ANN: logfloat 0.12.0.1
by wren ng thornton 03 Apr '09

03 Apr '09

-------------------------------------------- -- logfloat 0.12.0.1 -------------------------------------------- This package provides a type for storing numbers in the log-domain, primarily useful for preventing underflow when multiplying many probabilities as in HMMs and other probabilistic models. The package also provides modules for dealing with floating numbers correctly. -------------------------------------------- -- Now using FFI -------------------------------------------- We now use the FFI to gain access to C's accurate log1p (and expm1) functions. This greatly increases the range of resolution, especially for very small LogFloat values. These are currently exposed from Data.Number.LogFloat, though they may move to a different module in future versions. On GHC 6.10 the use of -fvia-C had to be disabled because it conflicts with the FFI (version 0.12.0.0 still used it, which is fine on GHC 6.8). I'm still investigating the use of -fasm and getting proper benchmarking numbers. Contact me if you notice significant performance degradation. Using the FFI complicates the build process for Hugs; details are noted in the INSTALL file. It may also complicate building on Windows (due to ccall vs stdcall), though I'm not familiar with Windows FFI and don't have a machine to test on. The calling convention is "unsafe" in order to avoid overhead. However, in the past this has been noted to cause issues with multithreaded applications since it locks all RTS threads instead of just the calling thread. If you're using logfloat in a multithreaded application and notice a slowdown, or if you're more familiar with these details than I, tell me so I can fix things. If you have any difficulties with the FFI, let me know. As an interim solution the FFI can be disabled by turning off the useFFI Cabal flag during configure, which will compile the package to use the naive log1p implementation from earlier versions. -------------------------------------------- -- Other changes since 0.11.0 -------------------------------------------- * (0.11.1) Felipe Lessa added an instance for IArray UArray LogFloat. On GHC we use newtype deriving; On Hugs we fall back to unsafeCoerce to distribute the newtype over IArray UArray Double. * (0.11.2 Darcs) Moved the log/exp fusion rules from Data.Number.LogFloat into Data.Number.Transfinite where our log function is defined. * Added a Storable LogFloat instance for GHC. No implementation is available yet for Hugs. * Removed orphaned toRational/fromRational fusion rules, which were obviated by the introduction of the Data.Number.RealToFrac module in 0.11.0. * Changed the Real LogFloat instance to throw errors when trying to convert transfinite values into Rational. -------------------------------------------- -- Compatibility / Portability -------------------------------------------- The package is compatible with Hugs (September 2006) and GHC (6.8, 6.10). For anyone still using GHC 6.6, the code may still work if you replace LANGUAGE pragma by equivalent OPTIONS_GHC pragma. The package is not compatible with nhc98 and Yhc because Data.Number.RealToFrac uses MPTCs. The other modules should be compatible. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat/ Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren

1 0

[network] #6: Network.Socket.sClose should change socket status
by network 03 Apr '09

03 Apr '09

#6: Network.Socket.sClose should change socket status ---------------------+------------------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/2996 ---- The current implementation of sClose in Network.Socket leaves the socket in a Connected state but frees the underlying OS resource. Thus, any further operations on the socket may apply to a different OS object if something else was assigned the same FD after the socket was closed. For example, sClose'ing the socket a second time can lead to some arbitrary other file or socket being closed. The attached test case was run in ghci 6.8.2 on Debian Linux sid, though by inspection of the Network.Socket source in 6.10.1, this is still present and the test case should work. It takes advantage of the way *NIX allocates file descriptors to demonstrate specific misbehaviors, so may or may not misbehave in the intended way on other platforms. ---- Test case ---- Simple patch to add a Closed state and make sClose idempotent. Operations that perform state transitions already check the socket state and will refuse to operate on a Closed socket, but this does not add checks for other operations like send/recv. ---- I should mention that closed-state.patch is against the 6.8.2 network library. It applies cleanly (with offsets) against the 6.10.1 library, but I can't test it. ---- Proposed patch in addition to closed-state.patch that adds checks for a valid FD in all operations. This is a fairly simple approach. In particular, it punts on the problem of one thread closing the socket in the middle of a socket operation in another thread. Arguably, the semantics of this are sufficiently unclear (especially for blocking operations) that applications should be doing their own synchronization in such situations. ---- Thanks for the patches! We'll take a look. ---- tibbe, this looks related to things you've been working on recently, and I think you are considering becoming the network maintainer? Can you take a look please? Thanks! ---- Sorry for the late reply. closed-state.patch looks fine to me. As for the second patch I think we need to figure out the performance consequences of checking an MVar for every op before we make the change. Perhaps it would be worthwhile to write down which guarantees the API currently gives and could give when used in multi-threaded code. I'm not even entirely sure what guarantees we give at the moment, without your patches. If nothing else that would serve as good documentation. ---- I pushed the closed-state.patch. -- Ticket URL: <http://trac.haskell.org/network/ticket/6> network <http://projects.haskell.org/network/> Networking-related facilities

1 3

System.Posix.User: make get{Group,User}EntryFor* more portable
by Matthias Kilian 03 Apr '09

03 Apr '09

Hi, some oddities let the user001 test of the unix package fail on getGroupEntryFor*. One reason is that sysconf(_SC_GETGR_R_SIZE_MAX) returns 1024 on OpenBSD, while getgr*_r(3) actually need a buffer of 1024 + 200 * sizeof(char*) bytes. Note that the grBufSize = 2048 workaround in User.hsc did not work on 64 bit machines with OpenBSD, even before the _SC_GETGR_R_SIZE_MAX sysconf had been introduced. Instead of fiddling with stupid numbers again, I just implemented the try / enlarge / try harder scheme mentioned for example at http://www.opengroup.org/onlinepubs/9699919799/functions/getgrgid.html And I did so for all four functions, just in case there are existing problems with other unices (OpenBSD only needs the getGroupEntryFor* fixes). My Haskell sucks badly, so if someone has a cleaner solution: feel free use it instead of my patch ;-) Ciao, Kili

2 1

some comments about bytestring-show package
by Manlio Perillo 02 Apr '09

02 Apr '09

Hi. I have started to use the bytestring-show package, since I need to serialize a big data structure in a lazy bytestring. However I have noted some possible problems with the API: - sometime it is used the put<xxx> prefix, other times the show<xxx> prefix - the module Text.Show.ByteString, IMHO, should re-export the Put class from the Data.Binary.Put. Thanks to the author of the package. Manlio Perillo

2 2

Haskell Platform: status update and call for volunteers
by Duncan Coutts 31 Mar '09

31 Mar '09

All, We'd like to give you an update on the status of the Haskell Platform. Background ---------- For background on what the Haskell Platform is about see these slides: http://blog.well-typed.com/wp-content/uploads/2008/11/haskell-platform.pdf The wiki page also gives an overview and links to further resources: http://www.haskell.org/haskellwiki/Haskell_Platform Current status -------------- There are no more policy questions to resolve for the first release. It is a matter of getting things done. The first platform release will contain: * ghc-6.10.2 * the "extra libs" (exact list on the issue tracker wiki below) * haddock, happy and alex * the cabal command line tool and it's dependencies. The plan calls for binary installers for Windows and OSX, a generic source tarball for Unix, and native packages for distros. Currently however things are stalled because Don and I have been too busy to put serious time into the task of building installers. It is not fair for our time problems to hold everything up. Call for volunteers ------------------- We are calling for volunteers for an action group. We need volunteers to take charge of various platforms and to manage the overall release. We would like to release a beta at the upcoming Haskell Hackathon in Utrecht (April 17-19). However this will *only* happen if people volunteer to help build distributions for different platforms. In particular we need: * Release manager / coordinator * Website with downloads and release notes * Someone in charge of each platform: * Windows installer * OSX installer * Generic Unix source tarball * Distribution packages: debian, fedora, gentoo, arch, BSD* etc Don and I will be able to help coordinate things and point people in the direction of tasks that need doing. The person in charge of each platform is responsible for building appropriate native packages / installer and coordinating the effort to test that the stuff installs ok and works. If no one volunteers, we simply won't have an Haskell Platform release for that platform. Resources: * Meta-package: darcs get http://code.haskell.org/haskell-platform * Issue tracker: http://trac.haskell.org/haskell-platform/ * Mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Please join the mailing list and volunteer! In the medium term we want to organise things with two overlapping groups. A "doers" group and a "talkers" group. The "doers" group deals with actually building installers and packages and making releases. The "talkers" group is for making decisions (in consultation with the community in general) about which packages go into the platform and what standards to demand of them. We are looking for volunteers for the action group now. As we mentioned, for the first release there is nothing for the talkers to do, though there will be plenty to do for the second major release. Duncan and Don

1 0

Volunteering to take owner maintainer role for the network package
by Johan Tibell 28 Mar '09

28 Mar '09

Hi, Since I'm making changes to the network library and pushing for new release Ian suggested that I take over the maintainer role for that package. Does anyone object to me taking over the maintainer role? Changes to the library will still be discussed on this mailing list of course. Note: There are other people (like the original authors) that know parts of the library better than me. I will defer questions I can't answer or changes I can't review to them. Cheers, Johan

1 0