- Libraries - Haskell.org

network-alt patch
by Dominic Steinitz 07 May '06

07 May '06

Einar, This wouldn't build for me. I've created a patch for configure.ac. May I suggest you try it on your system to check I haven't broken anything? Dominic. BTW I got this but assume it's because I don't have IPv6 support. Running test: Plain TCP IPv6 server @ 10380 > FAILED: user error (no socket to listen on)

2 1

Non-exhaustive pattern in Socket.hsc
by Dominic Steinitz 07 May '06

07 May '06

I'm getting [root@tility pcap]# ./test test: Socket.hsc:(1434,17)-(1523,20): Non-exhaustive patterns in case The problem is caused because pcap_findalldevs is returning an address family value of 17 #define PF_PACKET 17 /* Packet family. */ #define AF_PACKET PF_PACKET and the ghc Family datatype doesn't support it :-( data Family = AF_UNSPEC | AF_UNIX | AF_INET | AF_INET6 | AF_SNA | AF_DECnet | AF_APPLETALK | AF_ROUTE | AF_X25 | AF_AX25 | AF_IPX -- Imported from Network.Socket *Main> map packFamily [AF_UNSPEC,AF_UNIX,AF_INET,AF_INET6,AF_SNA,AF_DECnet,AF_APPLETALK,AF_ROUTE,AF_X25,AF_AX25,AF_IPX] [0,1,2,10,22,12,5,16,9,3,4] I think I have two choices: 1. Amend ghc. I haven't built ghc for a long time. Would I have to build the whole of ghc? I presume I would have to because of dependencies. 2. Use Network.Alt since http://www.cs.helsinki.fi/u/ekarttun/network-alt/doc/Network.Alt.Types.html defines type Family = Int Any advice? What is the long term plan for Network anyway? Thanks, Dominic.

6 6

Unsafe Functions
by Ashley Yakeley 05 May '06

05 May '06

I would like to start a discussion on the role of unsafe functions in Haskell: unsafePerformIO :: IO a -> a unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveST :: ST s a -> ST s a unsafeIOToST :: IO a -> ST s a unsafeIOToSTM :: IO a -> STM a unsafeFreeze, unsafeThaw, unsafePreservingMatrix, unsafeRenderPrimitive perhaps also unsafeForeignPtrToPtr :: ForeignPtr a -> Ptr a (which is already under Foreign.*) hGetContents :: Handle -> IO String (which is lazy rather than unsafe per se) * Do you use these, and what for? * Is there safe functionality that can currently only be obtained with them? * Do you think they should be standardised, and how? I'm thinking the unsafe functions should be moved from System.IO.Unsafe and elsewhere to Unsafe, similar to Foreign.*, to better separate them from "real Haskell" conceptually. Also, I would add: unsafeCoerce :: a -> b -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/

3 5

Cabal and fps merge into base-package
by Einar Karttunen 04 May '06

04 May '06

Hello How is one supposed to handle fps being merged to the base package in a Cabal file? Clearly GHC 6.4 will need to depend on the fps package while with GHC 6.5 such a dependency is superfluous, and actually having fps installed will cause conflicts. What is the right solution? - Einar Karttunen

4 3

Cabal 1.1.4 and a new Cabal-devel mailing list
by Duncan Coutts 02 May '06

02 May '06

=== Cabal 1.1.4 release === Cabal-1.1.4, the version shipped with GHC 6.4.2 is now available to download as a separate tarball: http://haskell.org/cabal/download.html http://haskell.org/cabal/release/cabal-1.1.4/cabal-1.1.4.tar.gz Note that there was some confusion over the version number. If you got a darcs development snapshot in the last few months it will likely have been marked 1.1.4, however it should have been marked 1.1.5. 1.1.4 is the version shipped with GHC 6.4.2 and available as the tarball above. The current darcs development version is 1.1.5. We'll try to avoid such confusion in the future. === New Cabal-devel mailing list === There is also a new cabal-devel(a)haskell.org mailing list for Cabal development discussion including patch review. This is where patches sent via "darcs send" will end up. We welcome anyone to join the list and help discuss ongoing Cabal development or just to keep an eye on what's going in. Sign up here: http://haskell.org/mailman/listinfo/cabal-devel We'd also like to take the opportunity to invite people to get involved in Cabal development, either new features or squashing annoying bugs. It's as simple as: darcs get --partial http://darcs.haskell.org/packages/Cabal # write patch darcs record darcs send People who already commit directly via darcs push are welcome to continue to do so for patches they consider obvious. If they would like some review and feedback then they are welcome to "darcs send" instead and discuss the patch on the mailing list before committing. Note that this new list is not intended to take discussions of Cabal away from the libraries list. Issues affecting users should still go to libraries(a)haskell.org. The intention is to have more discussion and review of Cabal development. Duncan (who is wearing his new Cabal release manager's hat)

1 0

cabal-install, cabal-setup, new world order
by Isaac Jones 01 May '06

01 May '06

Greetings, I've just pushed some recent work by Alson Kemp to the cabal repository. Alson has integrated the cabal-get tool (by Lemmih) and dependencies into the cabal source tree. This brings in a bunch of unwanted dependencies, though, and we'll be working to trim these out in order to make it a manageable size. Another thing is that I changed cabal-get to be called cabal-install, and removed the (never released) old version of cabal-install from the repo. The reason is that the role of cabal-get will expand to include what cabal-install was meant to do. That is, cabal-install will be used for installing groups of inter-dependent packages, whether they are on hackage.haskell.org or on your local machine. It doesn't do that yet, though; it can only install stuff from hackage. Also, Simon pushed his cabal-setup tool. Cabal-setup is basically like a boilerplate Setup.lhs, but smarter. So the Hackage toolchain will look like this: * Cabal is the library / package * cabal-setup is for building / installing one package. It's very simple * cabal-install is for installing a group of packages. It's pretty complex. If you grab the current darcs head of cabal, you should be able to "sudo make install" and get each of these tools. Then copy etc-cabal-install to /etc/cabal-install, and "cabal-install update" to get the list of packages, "cabal-install install helloWorld2" _should_ work. Your milage may vary. In other news, Duncan Coutts has agreed to become the release manager for Cabal, and we're working on a 1.1.4 release now, which will be the version of Cabal that came with ghc 6.4.2. peace, isaac

1 0

ANNOUNCE: Crypto-3.0.3
by Dominic Steinitz 29 Apr '06

29 Apr '06

I should like to announce a new version of the Haskell Cryptography Library. Version 3.0.3 supports: • DES • Blowfish • AES • Cipher Block Chaining (CBC) • PKCS#5 and nulls padding • SHA-1 • MD5 • RSA • OAEP-based encryption (Bellare-Rogaway) • PKCS#1v1.5 signature scheme • ASN.1 • PKCS#8 • X.509 Identity Certificates • X.509 Attribute Certificates It also includes Base64, a hexdump function, support for Word128, Word192, Word256 (key sizes for AES) and beyond. The ASN.1 handling has been re-written. Details on how to use it are contained in the user guide http://www.haskell.org/crypto/ReadMe.pdf. Haddock documentation is available at http://www.haskell.org/crypto/doc/html. See the home page (http://www.haskell.org/crypto) for downloading. Dominic.

2 2

[RFC] Faster implementation of Integer to string conversion.
by Bertram Felgenhauer 28 Apr '06

28 Apr '06

Hi, several people have noted that printing integers is slow. The attached patch implements a faster version of the jtos (read: positive integer to string) function in GHC's Num library. The algorithm is a divide and conquer algorithm, that converts numbers to base b by converting them to base b^2 first, and then splitting the digits. Notes: - I've tested the speed on my computer (which has an Athlon XP processor) and it seems to be of comparable speed as the original for small numbers and way faster for big numbers (read: a few hundred or thousand digits). - The changed conversion code is a much better list producer than the original one, which generates digits starting with the last. - There's similar code in Numeric.lhs, that deals with arbitrary bases. The current patch does not deal with this. (see questions below) - musabi on #haskell mentioned that there's interest in replacing GMP as the bignum implementation. This is independent of changing this string conversion, as far as I can see. Questions: - Is this really GHC specific? - Unfortunately I see no nice way to share code between the Numeric and Num modules. Does anyone have an idea how to do this without sacrificing performance for the common base 10 case? regards, Bertram

2 2

FPS/Data.ByteString candidate
by dons＠cse.unsw.edu.au 28 Apr '06

28 Apr '06

Following discussion, I've tagged FPS 0.4, a candidate for the base library. Changes: * Renamed to Data.ByteString(ByteString) * Improved documentation * Tweaks to build under ghc 6.6 * Added: getLine, getContents, putStr, putStrLn, zip, unzip, zipWith * Much faster: elemIndices, lineIndices, split, replicate * More automagic benchmarks and QuickCheck tests. As usual, code is here: http://www.cse.unsw.edu.au/~dons/fps.html -- Don

10 41

implementation of UTF-8 conversion for text I/O: iconv vs hand-made
by Bulat Ziganshin 26 Apr '06

26 Apr '06

Hello all this letter describes why i think that using hand-made (de)coder for support of UTF-8 encoded files is better than using iconv. to let other readers know, iconv is wide-spread C library that performs buffer-to-buffer conversion between any text encodings (utf-8, utf-16, latin-1, ucs-2, ucs-4 and more). hand-made (en)coder implemented by me is just "converter", i.e. high-order function, between the getByte/putByte and getChar/putChar operations. so it can be used in any monad and with any purposes, not only for text I/O one can find example of library that uses iconv in the "System\IO\Text.hs" module from http://haskell.org/~simonmar/new-io.tar.gz and example of hand-made encoder in module "Data\CharEncoding.hs" and its usage - in "System\Stream\Transformer\CharEncoding.hs" from http://freearc.narod.ru/Streams.tar.gz i crossposted this letter to Marcin and Simon because you have discussed with me this question and to Einar because he once asked me about one specific feature in this area. why iconv is better: 1) it's lightning fast, making virtually zero speed overhead 2) it's robust 3) it contains already implemented and debugged algorithms for all possible encodings we can encounter 4) it has highly developed error processing facilities (i mean signalling about errors in input data and/or masking them) why hand-made conversion is better: 1) i don't know whether iconv will be available on every Hugs and GHC installation? 2) Einar once asked me about changing the encoding on the fly, that is needed for some HTML processing. it is also possible that some program will need to intersperse text I/O with buffer/array/byte/bits I/O. it's a sort of things that are absolutely impossible with iconv 3) my library support Streams that works in ANY monad (not only IO, ST and their derivatives). it's impossible to implement iconv conversion for such stream types as you can see, while the last arguments says about very specific situations, these situations absolutely can't be handled by iconv, so we need to implement hand-made conversions anyway. on the other side, iconv strong points don't have principal meaning - the speed with hand-made routines will be enough, about several mb/s; all possible encodings can be implemented and debugged sooner or later; only processing of errors in input data is weak point of the current design itself moreover, there are implementation issues that make me more enthusiastic about hand-made solution. it just already implemented and really works. implementation of the CharEncoding for streams is in module "System\Stream\Transformer\CharEncoding.hs", which is very trivial. implementation of different encoders in "Data\CharEncoding.hs" is slightly more complex, but these routines also used in "instance Binary String", i.e. to serialize strings. also, i think that "Data\CharEncoding.hs" module should be a part of standard Haskell library, so implementation of CharEncoding stream transformer is almost "free" on the other side, implementation of text encoding in "new I/O" library is about 1000 lines long. while i don't need to copy them all, using iconv anyway will be much more complex than using hand-made routines. this include complexity of interaction with iconv itself and complexity of implementing various I/O operations over the buffer that contains 4-byte characters. i already implemented 3 buffering transformers and adding one more buffering scheme is the last thing i want to do. vice versa - now i'm searching for ways to omit repetitions of code by joining them all into one. it's very boring - to have 3 or 4 similar things and replicate every change to them all at the same time, the library design is open and it's entirely possible to have two alternative char encoding transformers. everyone can develop additional transformers even without interaction with me - in this case, it should just implement vGetChar/bPutChar operations via the vGetBuf/vPutBuf ones. i just propose to leave the things as they are, and go to implementing of iconv-based transformer only when we will be actually bothered by it's restrictions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 4