Re: Can we do better than duplicate APIs? [was: Data.CompactString 0.3]

> I think I don't master cabal distribution mechanism well enough yet.
> Till I get better, please use the darcs repo:
> http://darcs.haskell.org/packages/collections-ghc6.6/

This has now been fixed (thanks to Ross). To make things clear:

http://darcs.haskell.org/packages/collections-ghc6.6/
repository working against the latest stable release of ghc/base

http://darcs.haskell.org/packages/collections/
development repository (you basically need ghc 6.7 for this one)

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3
latest snapshot of the former (ie. stable version).

Cheers,
JP.

Re: Automated tests for the libraries?

I've been working on getting test running Cabalized and finally have a
patch to send. Extracting tests from the source code is, I think, an
independent problem.

http://jeffrey.yasskin.info/darcs/filepath/Setup.hs has the main
instructions for running the test (with the same test extraction as
the original GenTests.hs), and
http://jeffrey.yasskin.info/darcs/filepath/SingleFileOps.hs has some
operations that I'd like to add to Cabal itself. With some more
experience writing tests like this, we'll definitely want to extract
most of this Setup.hs into a shared module.

The basic idea is that I want to base the tests as much as possible on
production code, but I may need to #define TESTING or some other
symbol in a particular file to get that file's tests to run. So each
file "foo.hs" may be compiled with the 'tag' "foo" (practically, into
the dist/build/foo directory) with -DTESTING, and then its test is run
in the context of ["foo", ""] (look for "foo" object files, and then
the results of `Setup.hs build`). Putting testing builds in a
different place also makes sure that they don't get installed or
released accidentally.

What would be the best way to proceed? Is this system overkill and I
should start over with something simpler (either a single -DTESTING
build tree or just `runhaskell -DTESTING`)? Should I clean up
SingleFileOps and submit it to Cabal? Should I take what I have and
apply it to base?

This patch is based on http://www.cs.york.ac.uk/fp/darcs/filepath/, so
it's a little out of date. Neil, if you're interested in accepting

Re: Proposal [Trac #1212]: add IPv6 support to network library

I've downloaded your darcs repo, and it built fine (openSUSE 10.2 x86_64). Two 
remarks:

   * You use an internal class HostAddr and make two type synonyms an instance 
of it. This has 2 drawbacks: It is not H98 and Haddock complains about a 
missing link destination. I think one could handle things easily without a 
class, because all possible instances are known at compile time.

   * The types and values of AddrInfoFlags/NameInfoFlags are not very 
Haskell-like. Using

        data AddrInfoFlag = Passive | CanonName | NumericHost | ...

     and [AddrInfoFlag] instead of AddrInfoFlags is much nicer. The only cost 
is that a tiny marshaling function has to be written. Same for NameInfoFlags. 
Interfaces writte this way are more type safe and one can easily see which 
alternatives are possible for a given set of flags in a single place.

Alas, the X11 package is not nice regarding the last item, either... 

Cheers,
   S.

Re: Why the Prelude must die

David House wrote:
> On 24/03/07, Stefan O'Rear <stefanor <at> cox.net> wrote:
>> This is a ranty request for comments, and the more replies the better.
> 
> Without responding to any particular comment, my opinion is that we
> should have a minimal Prelude with functions like (.) that couldn't be
> reasonably redefined in any function.

I can recall two variations on (.)...

Strict composition, perhaps (.!), that is somehow strict in the
functions that are its arguments.

Unicode composition, i.e. use the Unicode character for function
composition (?) instead of the overloaded (with module system syntax)
"." symbol

Not that these are worthy alternatives for our Prelude, just reasons
that I don't entirely like the idea of any implicitly included prelude.

Isaac

Re: Proposal [Trac #1212]: add IPv6 support to network library

On Sat, Mar 31, 2007 at 01:47:09PM +0000, Bryan O'Sullivan wrote:
> 
> http://hackage.haskell.org/trac/ghc/attachment/ticket/1212/ipv6.2.patch

This contains:

    hunk ./network.cabal 2
    -version:       2.0
    +version:       2.0.1

I don't think patches should include changes to the version number, as
they will then depend/conflict with every other patch. Instead, changes
should accumulate in the darcs repo, and the version number incremented
by a patch (that does nothing else) just before a release is made.

Thanks
Ian

Re: Dubious behavior in TH pretty printer

On Sat, Mar 31, 2007 at 01:00:06AM -0700, Stefan O'Rear wrote:
> 
> stefan <at> stefans:~/daanpp$ ghci -fth
> Prelude> :m + Language.Haskell.TH
> Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr
> GHC.Num.+ 2 2
> 
> I am trying to use the Template Haskell AST system for internal
> representation of terms in a derivation library that can output
> Haskell or feed directly into a splice.  This "bug", unfixed, would
> force me to fork the TH pretty printer.  What would people think of a
> patch changing the behavor to "Always produce parsable output"?  (Yes,
> I'm offering to implement it.)

Sounds great - the pretty-printer is intended to print in valid Haskell
syntax.

Thanks
Ian

darcs patch: Create showName, which takes an addition... (and 4 more)

Adds support for handling prefix and infix names to the (Template
Haskell) pretty printer; parenthesis and backticks are added as needed
to match the intrinsic fixity of symbols with fixity contexts.  Also
contains a one-line fix causing irrefutable patterns to be properly
printed.  NB: changes Show Name output.

Sun Apr  1 09:46:35 PDT 2007  Stefan O'Rear <stefanor <at> cox.net>
  * Create showName, which takes an additional prefix-context argument

Sun Apr  1 09:48:14 PDT 2007  Stefan O'Rear <stefanor <at> cox.net>
  * Thread prefix-context argument through pprName

Sun Apr  1 09:56:55 PDT 2007  Stefan O'Rear <stefanor <at> cox.net>
  * Use pprName False in pretty printer

Sun Apr  1 09:59:45 PDT 2007  Stefan O'Rear <stefanor <at> cox.net>
  * Typo fixes, missing {in,ex}ports

Sun Apr  1 12:02:15 PDT 2007  Stefan O'Rear <stefanor <at> cox.net>
  * Properly handle tilde-patterns

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal [Trac #1212]: add IPv6 support to network library

On Sun, 2007-04-01 at 16:56 +0100, Ian Lynagh wrote:
> On Sat, Mar 31, 2007 at 01:47:09PM +0000, Bryan O'Sullivan wrote:

> I don't think patches should include changes to the version number, as
> they will then depend/conflict with every other patch. Instead, changes
> should accumulate in the darcs repo, and the version number incremented
> by a patch (that does nothing else) just before a release is made.

Indeed. 

It'd be nice to make cabal make it easier to work in this way, for
example by making dated snapshot versions easier to make.

cabal-setup sdist [release|snapshot] ?

Duncan

Re: Proposal [Trac #1212]: add IPv6 support to network library

On Mon, Apr 02, 2007 at 09:05:00AM +1000, Duncan Coutts wrote:
> It'd be nice to make cabal make it easier to work in this way, for
> example by making dated snapshot versions easier to make.
> 
> cabal-setup sdist [release|snapshot] ?

Like setup sdist --snapshot ?

Re: Proposal [Trac #1212]: add IPv6 support to network library

On Mon, 2007-04-02 at 00:08 +0100, Ross Paterson wrote:
> On Mon, Apr 02, 2007 at 09:05:00AM +1000, Duncan Coutts wrote:
> > It'd be nice to make cabal make it easier to work in this way, for
> > example by making dated snapshot versions easier to make.
> > 
> > cabal-setup sdist [release|snapshot] ?
> 
> Like setup sdist --snapshot ?

You'd think that being Cabal release manager I'd know about this kind of
thing wouldn't you?  Ah well.

Duncan