April 2009 - Libraries

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

04 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 04 Apr '09

04 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