December 2004 - Libraries

RE: Cabal and installing packages.
by Simon Marlow 09 Dec '04

09 Dec '04

On 03 December 2004 17:10, Keean Schupke wrote: > I find that even on package managed systems I use CPAN to install perl > modules... I would have thought a nice central repository on > haskell.org (with mirrors of course) where users can contibute their > packages, that would be built into a Haskell package tool would be > useful even for systems where there is package management. > > I find that debian/gentoo etc do not have all the packages available > for say perl, and it is nice to have a consistant interface on any > platform... I'm arguing for a consistent interface for all packages (not just Haskell) on any given platform, whereas you're arguing for a consistent interface for Haskell packages across platforms. There are advantages to both approaches of course, so ideally we'd have both. That means correctly managing interactions between the Haskell package manager (whatever that is) and the native package manager, such that you can uninstall packages in the native way, for example. We all agree what would be useful. Now it's time to write some code! Cheers, Simon

3 3

Regexp substitution in fptools?
by John Goerzen 09 Dec '04

09 Dec '04

Hi, I have the following code in my MissingH tree. I think it would make a good addition to Text.Regex in fptools. Is this the right place to ask? -- John {- | Replaces every occurance of the given regexp with the replacement string. In the replacement string, @\"\\1\"@ refers to the first substring; @\"\\2\"@ to the second, etc; and @\"\\0\"@ to the entire match. @\"\\\\\\\\\"@ will insert a literal backslash. -} subRe :: Regex -- ^ Search pattern -> String -- ^ Input string -> String -- ^ Replacement text -> String -- ^ Output string subRe _ "" _ = "" subRe regexp inp repl = let bre = mkRegex "\\\\(\\\\||[0-9]+)" lookup _ [] _ = [] lookup [] _ _ = [] lookup match repl groups = case matchRegexAll bre repl of Nothing -> repl Just (lead, _, trail, bgroups) -> let newval = if (head bgroups) == "\\" then "\\" else let index = (read (head bgroups)) - 1 in if index == -1 then match else groups !! index in lead ++ newval ++ lookup match trail groups in case matchRegexAll regexp inp of Nothing -> inp Just (lead, match, trail, groups) -> lead ++ lookup match repl groups ++ (subRe regexp trail repl) {- | Splits a string based on a regular expression. The regular expression should identify one delimiter. -} splitRe :: Regex -> String -> [String] splitRe _ [] = [] splitRe delim str = case matchRegexAll delim str of Nothing -> [str] Just (firstline, _, remainder, _) -> if remainder == "" then firstline : [] : [] else firstline : splitRe delim remainder

1 0

Renaming the User and Org hierachies
by Andreas Sewe 08 Dec '04

08 Dec '04

Hello, given that at least the current prefix for the Org hierarchy is suboptimal, I would like to propose renaming both the User and Org hierarchy to Prs and Vnd, respectively. The rationale behind those names is that they are the ones the IETF/IANA chose for very much the same purpose: to name two registration trees (for MIME types, in this case), Prs and Vnd denoting the "Personal or Vanity" and "Vendor" tree, respectively. See "RFC 2048 - MIME Registration Procedures", sections 2.1.2 and 2.1.3, for a detailed description of the two trees <ftp://ftp.rfc-editor.org/in-notes/rfc2048.txt>. Does this look like an improvement over User and Org (or Contrib, for that matter)? Regards, Andreas Sewe

2 1

RE: Distribution.PreProcess
by Simon Marlow 08 Dec '04

08 Dec '04

On 07 December 2004 17:56, Isaac Jones wrote: > Ross Paterson <ross(a)soi.city.ac.uk> writes: >> It might be preferable not to unlit .lhs files, as all >> implementations can handle them, and the originals are better for >> human readers (such as Hugs users curious about their libraries). >> There's no real need to unlit .ly files either, though some other >> preprocessors will need it. (And should unlit be treated as just >> another preprocessor?) > > Yeah... should we get rid of the unlit preprocessor? > >> As I understand it, preprocessing with cpp is only needed for Hugs, >> as the compilers have -cpp flags, and will do it properly >> themselves. For Hugs, cpp will need a -D__HUGS__ option, plus extra >> options that are often system-dependent (and will also be needed by >> the compilers). This harks back to the need to separate >> system-dependent build parameters from the package description, and >> provide hooks to generate and use them. > > I'll try to think more about this. Another thing to bear in mind: at some point we want to provide './setup haddock' (or maybe './setup haddock-html', './setup haddock-docbook', ...) and unlit/CPP will be required for that. Cheers, Simon

1 0

RE: Cabal and installing packages.
by Simon Marlow 07 Dec '04

07 Dec '04

On 07 December 2004 12:30, Keean Schupke wrote: > As someone who nearly always uses -fvia-C, I find there are just as > many nifty performance enhancing flags usable for example: > > -O2 -fvia-C -ffast-math -mfpmath=sse,387 -fomit-frame-pointer > -fexpensive-optimizations Interesting that you use -fomit-frame-pointer, especially since the frame pointer register is already used for another purpose by GHC on x86 :-) And I think you forgot -optc-O2 and -fexcess-precision, although I'm not entirely sure what -fexcess-precision does in conjuction with -mfpmath=sse. Cheers, Simon

1 0

RE: Cabal and installing packages.
by Simon Marlow 07 Dec '04

07 Dec '04

On 07 December 2004 09:57, Keean Schupke wrote: > Also a section like gentoo's make.conf (for ebuilds) where local > options can > be set in a file (for things like optimisation flags etc)... I might be on my own here, but I happen to think that the way Gentoo encourages you to have local optimisation flag settings is complete madness. Probably the only good thing that can be said for it is that it's given the gcc developers a lot of good testing. I don't think we want to do this for Haskell, it introduces one more way for things to go wrong, and one more thing to forget in a bug report. Cheers, Simon

3 3

RE: Cabal and installing packages.
by Simon Marlow 07 Dec '04

07 Dec '04

On 03 December 2004 21:01, Daan Leijen wrote: > Keean Schupke wrote: >> But I see what you are saying too, a program to convert a >> cabal-package into say an ebuild for gentoo. > > And a what for Windows? and MacOS X? and Sun Solaris? and ... ;-) It was always part of the plan to auto-generate Windows installers (and ebuilds, and RPMs, etc. etc.) from Cabal packages, see the proposal: http://www.haskell.org/libraryInfrastructure/proposal/index.html That leaves Solaris out in the cold a bit, because they don't have any kind of installer system at all. However, you can still build from source (./Setup.lhs configure; ./Setup.lhs build; ./Setup.lhs install), it's not that hard. Cheers, Simon

2 1

ANN: MissingH 0.7.2 with GZip
by John Goerzen 06 Dec '04

06 Dec '04

Hello, I'm pleased to announce the release of MissingH 0.7.2, available from http://quux.org/devel/missingh. This release incorporates Ian Lynagh's pure-Haskell Inflate algorithm, and CRC-32 and GZip file parsers of my own design, to make a pure-Haskell solution[1] to decompressing .gz files. At present, it is rather slow, as there has been little effort to optimize any of the three components. Patches to address the speed will be happily applied. The Inflate and CRC32 algorithms also provide the necessary support to be able to handle ZIP files. I plan to introduce ZIP and tar file support in upcoming releases of MissingH. Also, MissingH 0.7.0 was not announced on the library list. It introduced the ConfigParser[2] module. This module can parse the flat or hierarchical configuration files made popular by Python's ConfigParser module. The files are simple for both humans and programmers <grin>. If care is taken, it is possible to craft files that are valid both to ConfigParser and to other systems such as the Unix shell or Make. ConfigParser can also completely parse various other formats "out of the box", including SMTP headers, Cabal Setup.description files, and, to a limited extent, /etc/passwd files. All code in MissingH is pure Haskell. There is no C required. [1] http://quux.org/devel/missingh/html/MissingH.FileArchive.GZip.html [2] http://quux.org/devel/missingh/html/MissingH.ConfigParser.html -- John

2 2

RE: Cabal and installing packages.
by Simon Marlow 05 Dec '04

05 Dec '04

On 03 December 2004 16:24, Keean Schupke wrote: > Cool, I should have paid more attention to the Cabal stuff... Next > question is; > > Is there planned to be a front-end for fetching packages, that would > let you download > and install a package (and all its dependancies) from the command > line? All I could > find were the ./setup <option> commands? If you're on a system with a good package manager (i.e. *BSD, Debian, Gentoo) then the plan is that this is all handled by the system package manager. We don't want to duplicate that work, and we want to coexist with the system's package tools as much as possible. Cabal will make it easy to generate package skeletons for these systems. We don't have a good story for the rest yet - that includes systems that don't have a package manager, and when you want to install packages in your own filespace on a multi user machine. A tool to do what you describe would definitely help here. Cheers, Simon

4 8

RE: Cabal and installing packages.
by Simon Marlow 04 Dec '04

04 Dec '04

On 03 December 2004 12:05, Keean Schupke wrote: > My question is does Cabal require the package author to specify > dependancies, and if not, perhaps it should. Yes it does. Next question :) Simon

2 1