- Libraries - Haskell.org

ANN: TextRegexLazy-0.66 devel release
by Chris Kuklewicz 08 Aug '06

08 Aug '06

(when (compilesOk) (announce newVersion)) This is a development release announcement of "TextRegexLazy" The "TextRegexLazy" package is dead. Long Live [regex-base -- interfaces ,regex-compat -- replace Text.Regex ,regex-posix -- PosixRE backend ,regex-pcre -- PCRE backend ,regex-parsec -- My lazy Haskell backend ,regex-dfa -- DFA based on modified CTKLight (LGPL) ] Note: Everything is BSD licensed except the regex-dfa engine which is LGPL. The darcs repository at http://evenmere.org/~chrisk/trl/head/ has the new version. The regex-compat package is a single Text.Regex.New module that uses regex-posix to replace Text.Regex (I cut and pasted from the Text.Regex module and re-implemented some of the functions). The old Text.Regex.Posix module is bypassed (so it could be removed in the future). Changing the dependency to a different backend is as simply as changing the import statement. Changing from String to ByteString would be a simple search-and-replace (and import Data.ByteString). The regex-posix package does not have a personal copy of the posix regex library like the copy GHC brings to Windows: http://darcs.haskell.org/packages/base/cbits/regex/ If someone can get regex-posix working on Windows, then [regex-base,regex-posix,regex-compat] will be functionally ready to be included along with GHC. TODO: * Much Haddock fixing for the new module hierarchy * Point the test cases at the new packages * Benchmark -- Chris Kuklewicz

1 0

ANN: TextRegexLazy-0.56, (=~) and (=~~) are here
by Chris Kuklewicz 02 Aug '06

02 Aug '06

Announcing: TextRegexLazy version 0.56 Where: Tarball from http://sourceforge.net/projects/lazy-regex darcs get --partial [--tag=0.56] http://evenmere.org/~chrisk/trl/stable/ License : BSD, except for DFAEngine.hs which is LGPL (derived from CTK light) Development/unstable version is at: darcs get [--partial] http://evenmere.org/~chrisk/trl/devel/ This is the version that has eaten John Meacham's JRegex library and survived to become strong. Thanks John! It now compiles against the posix regexp provided by the c library and the pcre library, in addition to the "full lazy" and the "DFA" backends. All 4 backends can accept regular expressions given as String and as ByteString. All 4 backends can run regular expressions against String and ByteString. In particular, the PosixRE and PCRE can run very efficiently against ByteString. (Though the input for the PosixRE needs to end in a \NUL character for efficiency). So there are 4*2*2 = 16 ways to use to provide input to this library. And the RegexContext class has at least 11 instances that both (=~) and (=~~) can target. So that is 4*2*2*11*2 = 352 things you can do with this library! Get your copy today! To run with cabal before 1.1.4 you will need to comment out the "Extra-Source-Files:" line in the TextRegexLazy.cabal file. The Example.hs file: > {-# OPTIONS_GHC -fglasgow-exts #-} > import Text.Regex.Lazy > import Text.Regex.Full((=~),(=~~)) -- or DFA or PCRE or PosixRE > > main = let b :: Bool > b = ("abaca" =~ "(.)a") > c :: [MatchArray] > c = ("abaca" =~ "(.)a") > d :: Maybe (String,String,String,[String]) > d = ("abaca" =~~ "(.)a") > in do print b > print c > print d This produces: > True > [array (0,1) [(0,(1,2)),(1,(1,1))],array (0,1) [(0,(3,2)),(1,(3,1))]] > Just ("a","ba","ca",["b"]) You can also use makeRegex and makeRegexOpts to compile and save a regular expression which will be used multiple times. Each of the 4 backends has a separate "Regex" data type with its own option types. For low level access, the WrapPCRE and WrapPosix modules expose a typesafe layer around the c libraries. You can query the "getVersion :: Maybe String" to see if the have been compiled into the library. It may be possible to use WrapPCRE and the UTF8 option flags to do unicode regex matching with PCRE. ( The Full and DFA backends use the Haskell unicode Char already ). Adding new types to String/ByteString is a matter of adding instances to the existing classes. Feedback and comments of any length is welcome. -- Chris Kuklewicz

2 4

darcs patch: Remove a variable shadowing warning (and 1 more)
by Ian Lynagh 01 Aug '06

01 Aug '06

Sun Jul 30 17:39:33 BST 2006 Ian Lynagh <igloo(a)earth.li> * Remove a variable shadowing warning Sun Jul 30 17:49:44 BST 2006 Ian Lynagh <igloo(a)earth.li> * Silence warnings.

4 3

darcs patch: Eliminate some warnings
by Ian Lynagh 30 Jul '06

30 Jul '06

Sat Jul 29 23:08:54 BST 2006 Ian Lynagh <igloo(a)earth.li> * Eliminate some warnings Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching.

1 0

Re: patch applied (ghc): Generalise Package Support
by Simon Marlow 28 Jul '06

28 Jul '06

Malcolm Wallace wrote: > I would caution against changing the syntax of imports too hastily. As > I recall, the outcome of the mailing list discussion (and wiki) on this > issue was that the proposed syntax changes do not give any new > expressive power over packages, that we do not already have (via > OPTIONS_GHC etc). Given that the user can already say everything about > packages they need to, in the source code, I question whether > arbitrarily breaking source-compatibility with other implementations > (and Haskell'98) is wise. Well, firstly we don't currently support using -package options inside OPTIONS_GHC, but that's certainly one option. Leaving it there is certainly attractive, because there's not much to do, and as you say it keeps the language changes to a minimum. It's also very close to the .NET story. Package-qualified imports give you two qualitative benefits over per-module -package flags: - they let you disambiguate imports in a single module - they let you use packages without populating the global module namespace Some people wanted to move in the direction of using package-qualified imports for *everything*, that is moving away from a single global module namespace. Certainly having a per-package module namespace is useful: for example in the GHC package we don't want to have to rename all our modules to be hierarchical, but in the absence of package-qualified imports we will probalby be forced to do that to avoid probable clashes in the global module namespace. I see the package-qualified import story as quite attractive. It's quite lightweight, easy to understand and not too hard to implement, and the fact that it parallels the story at the module level means that it is intuitive. I wouldn't say I'm completely sold on it (but Simon PJ is, I think). I'm not sure what the Cabal story would be if package flags are allowed in OPTIONS_GHC, it seems a bit hairy. On the other hand, Cabal works quite naturally with package-qualified imports - we just need a way to say in build-depends that a package dependency should not populate the global module namespace. Cheers, Simon

2 1

hSeek on text files
by Bulat Ziganshin 28 Jul '06

28 Jul '06

Hello Simon, Simon, are you remember problem with using hTell+hSeek on handles open in text (not binary) mode on Windows? afair, you was finished with the decision to use NoBuffering for text files on Windows? but this solution is very inefficient. i now thought about dealing with the same problem in my lib and found that there is another solution - prohibit using of hTell/hSeek on files open in text mode (on Unix, too?). i think this is better - one should either open file in binary mode and use random access or open file in text mode and read/write it sequentially. what you think about it? also, i will be glad to hear comments from other haskellers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 4

[RFC] Network.Socket: change get/setSocketOption
by Bertram Felgenhauer 28 Jul '06

28 Jul '06

Hi, (This mail is related to http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/3788 ) What I'm proposing is to make SocketOption a proper ADT and change get- and setSocketOption to functions that take type constructors instead of tags as arguments, i.e. getSocketOption :: Socket -> (a -> SocketOption) -> IO a setSocketOption :: Socket -> (a -> SocketOption) -> a -> IO () To make that work, the two functions are implemented in a type class. I'll attach a patch bundle (in darcs send -o format) of two patches: 1) implement the infrastructure for this change. it is mostly backward compatible: As long as code doesn't explicitely mention the SocketOption type, it should work without modifications. 2) give the options more sensible types. -- this breaks existing code. For example, setSocketOption sock ReuseAddr 1 becomes setSocketOption sock ReuseAddr True (the patch includes the necessary fixes for the network package) What's missing is a solution for the problem that prompted this change, namely setting struct time_val values. To do that, I'd need some Storable type that maps to struct time_val. I think Network.* is not the proper place to implement that. Where should it go? - Foreign.C.Types - not generally useful enough, I think. - System.Time - not portable enough? - System.Posix.* - seems to be the right place to me. related stuff: http://cryp.to/hsdns/System/Posix/GetTimeOfDay.hsc -- quite close to what I'd like to have; conversions to, say, System.Time.ClockTime would be useful though. http://www.haskell.org/~simonmar/time/NewTime.hsc -- looks like a new System.Time to me; the CTimeVal handling seems to be identical to System.Time though Comments, questions and suggestions are welcome. Bertram P.S. thanks to heatsink on #haskell for the suggestion of passing constructors to the functions. That simplified the code a lot at a small loss of safety, and made the interface more similar to the old one.

2 3

cabal install doesn't use PATH
by Frederik Eaton 26 Jul '06

26 Jul '06

Hi, What's the reason for not resolving executables through PATH in the cabal Makefile? $ pwd /home/frederik/cabal-1.1.4 $ which ghc /home/frederik/arch/i386/bin/ghc $ make install mkdir -p dist/tmp /usr/bin/ghc --make -Wall -fno-warn-unused-matches -cpp -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: /usr/bin/ghc: Command not found make: *** [setup] Error 127 If I want to specify a different version of GHC than the one I normally use, then I could do: $ PATH=special-version-dir:$PATH make install Why the cabal makefile has to introduce a new variable HCBASE to achieve this functionality, I don't understand. It makes the normal user's life much harder by breaking a standard Unix abstraction layer; and at the same time it barely makes anyone else's life any easier. Also, I think it is more standard to use PREFIX to refer to what appears as PREF in the makefile. Frederik -- http://ofb.net/~frederik/

2 2

ANN: TextRegexLazy 0.44
by Chris Kuklewicz 24 Jul '06

24 Jul '06

TextRegexLazy: The Text.Regex.Lazy replacement and enhancement for Text.Regex New Version: 0.44 Where: http://sourceforge.net/projects/lazy-regex Changes from 0.33 to 0.44 * Cabal * Compile with -Wall -Werror * Change DFAEngineFPS from Data.FastPackedString to Data.ByteString (still fairly untested) This was my first time packaging with cabal, and I am hoping it works for you. The tests have been cleaned up and now Cabal can run them. The change from FPS to ByteString was trivial. Question 1: What more would people want from a Regex engine for Data.ByteString? Question 2: Is there interest in getting this into an official release of the base libraries? The Compat module could at least replace or sit alongside the performance sink of the current Text.Regex code. -- Chris "I define UNIX as 30 definitions of regular expressions living under one roof." * Donald Knuth: Chapter 33 of the book Digital Typography, p. 649.

4 9

Re: Package "mounting" proposal
by Simon Marlow 24 Jul '06

24 Jul '06

Stefan Karrmann wrote: > My 2 cents: > > Sven Moritz Hallberg (Sun, Jul 16, 2006 at 01:24:43AM +0200): > >>[...] >>She must specify it somehow. Two possibilities come to mind: >> >> 1. Add a field to the package description of foo (v1.4, say) that says >> "I'm backwards-compatible with 1.3." When building, this relation >> would have to be inspected to see whether any currently installed >> version of foo satisfies the dependency specified by the mount. >> 2. Declare a convention for version numbers to carry compatibility >> information, like the OpenGL standard, for example: If the new >> version is backwards-compatible, only the minor version number >> changes. If it isn't, the major version number must be incremented. >> > > > I prefer 1. The FSF use 2 for its GNU software and others started with it, > too. But after a while most of them tend to increase major numbers. E.g. > 3.0, 3.11, 95, 98, 2000 I think we should do (1). But we should also keep the current mechanism of allowing a package to specify a range of dependencies, the reason being that even when an interface upgrade isn't fully compatible, the package might still work with it, and this is a property of the consuming package, not the package that is depended on. (incedentally .NET has both of these facilities too, but only for runtime dependencies, not build-time AFAIK). Cheers, Simon

2 1