Pipes updates

[Gabriel Gonzalez]

Okay, I'm finally done preparing for my defense so I spent the weekend
uploading the latest round of small updates to libraries.

Probably the nicest thing these updates add is a set of high-efficiency
rewrite rules in `pipes`. There are two sets of rules:

1) The first set of rules is in the `Pipes` module and uses the category
laws to rewrite things to more optimal versions. In isolation these
rules don't do very much, but they synergize with the second set of
rules. You can find these rules here:

https://github.com/Gabriel439/Haskell-Pipes-Library/blob/ec12094ae9ae89fd9900ba206ec8236867615ec6/src/Pipes.hs#L165

2) The second set of rules is in `Pipes.Prelude`. These rewrite rules
rewrites certain pipes to more efficient for loops when possible. For
example, here's one such rewrite rule:

p >-> print = for p (\a -> liftIO (Prelude.print a))


So what happens is that if you write something like this:

P.stdinLn >-> P.map foo >-> P.print

... the second set of rewrite rules will first transform the `map`:

for P.stdinLn (\a -> yield (foo a)) >-> P.print

... then it will transform the `print`:

for (for P.stdinLn (\a -> yield (foo a))) (\b -> liftIO (print b))

Then the first set of rewrite rules will kick in, using the
associativity law to reorder the for loops:

for P.stdinLn (\a -> for (yield (foo a)) (\b -> liftIO (print b))

Then the left identity law will kick in, too!

for P.stdinLn (\a -> liftIO (print (foo a)))

... which is what a `pipes` expert might write by hand. In other words,
the rewrite rules will now transform naive pipes code to
high-performance for loops.

What that means for downstream pipes libraries is that any time you have
a pipe that is a `for cat` loop, like:

myPipe = for cat (\a -> doSomethingWith a)

You can take advantage of these optimizations by adding a rewrite rule like:

{-# RULES "p >-> myPipe" forall p . p >-> myPipe = for p (\a ->
doSomethingWith a) #-}

This will then trigger all the rest of the optimizations.

Note that I can't just add a general rewrite rule that says:

p >-> for cat f = for p f

The reason why is that this is a free theorem that you only get if `f`
never `await`s. I don't know of a way to have rewrite rules detect that
sort of condition.

The next most important change is that I finally uploaded the
`pipes-safe` change that adds `MonadIO (Base m)` to the class constraint
for `MonadSafe`, which means that now downstream libraries can get rid
of the `MonadIO (Base m)` constraint from utilities. (See
Pipes.Safe.Prelude for a concrete example of how to do this)

Another important change is that `pipes` now has a QuickCheck test suite
for all the `Pipes.Core` category laws (thanks to Csernik Flaviu Andrei)
as well as manual proofs of pipes laws, too. Paolo has also worked out
how to prove these laws in Agda for unidirectional pipes, so it
shouldn't be very long before there are Agda proofs for the
bidirectional category laws.

Also, you can now compile a Haskell98 subset of `pipes` by using `cabal
install -f haskell98 pipes` (again thanks to Csernik Flaviu Andrei).

Also, `pipes` has a benchmark suite (thanks to, you guessed it, Csernik
Flaviu Andrei).

Another important change is that `Pipes.Lift` now has the super-useful
`distribute` function, thanks to Patrick Wheeler. You can use this to
easily write `runEitherP` (I know that Renzo wanted this):

runEitherP = runEitherT . distribute

`distribute` is really magical because it works for any monad
transformer that implements `MFunctor` and doesn't require any pipes
internals to work. It's pretty sweet.

`pipes-parse` also now re-exports `transFreeT` and also adds
`takeProducers`. This is so that you can write something like the
following code that takes the first three words of each line:

unlines . transFreeT (unwords . takeProducers 3 . words) . lines

The next thing on my radar is fixing up the `pipes-text` library and
then working on a `pipes`-based high-efficiency serialization library.

[Renzo Carbonara]

On Sun, Nov 17, 2013 at 11:42 PM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

Okay, I'm finally done preparing for my defense so I spent the weekend uploading the latest round of small updates to libraries.

Exciting news! I thank you and everyone else involved for these useful contributions to mankind :)

I wish all goes well in your defense!


Regards,

Renzo Carbonara.

[Pierre R]

Small nitpicking, after the updates on hackage both
http://hackage.haskell.org/package/pipes and http://hackage.haskell.org/package/pipes-bytestring seem to have lost the URI links to modules.

Cheers

[Dag Odenhall]

Shouldn’t the for rules be on //>, doesn’t GHC figure out to apply them to for too, then?

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscribe@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

[Gabriel Gonzalez]

It might be because Hackage hasn't generated the documentation yet.  If it is still broken by tonight then I will contact them to see what is up.

--

You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.

[Gabriel Gonzalez]

I have it on both, as a precaution.� The bottom of `Pipes.Core` has the rewrite rule for `(//>)`.

On 11/18/2013 02:47 AM, Dag Odenhall wrote:

Shouldn�t the for rules be on //>, doesn�t GHC figure out to apply them to for too, then?

On Mon, Nov 18, 2013 at 3:42 AM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

Okay, I'm finally done preparing for my defense so I spent the weekend uploading the latest round of small updates to libraries.

Probably the nicest thing these updates add is a set of high-efficiency rewrite rules in `pipes`. �There are two sets of rules:

1) The first set of rules is in the `Pipes` module and uses the category laws to rewrite things to more optimal versions. �In isolation these rules don't do very much, but they synergize with the second set of rules. �You can find these rules here:

https://github.com/Gabriel439/Haskell-Pipes-Library/blob/ec12094ae9ae89fd9900ba206ec8236867615ec6/src/Pipes.hs#L165

2) The second set of rules is in `Pipes.Prelude`. �These rewrite rules rewrites certain pipes to more efficient for loops when possible. �For example, here's one such rewrite rule:

� � p >-> print = for p (\a -> liftIO (Prelude.print a))

So what happens is that if you write something like this:

� � P.stdinLn >-> P.map foo >-> P.print

... the second set of rewrite rules will first transform the `map`:

� � for P.stdinLn (\a -> yield (foo a)) >-> P.print

... then it will transform the `print`:

� � for (for P.stdinLn (\a -> yield (foo a))) (\b -> liftIO (print b))

Then the first set of rewrite rules will kick in, using the associativity law to reorder the for loops:

� � for P.stdinLn (\a -> for (yield (foo a)) (\b -> liftIO (print b))

Then the left identity law will kick in, too!

� � for P.stdinLn (\a -> liftIO (print (foo a)))

... which is what a `pipes` expert might write by hand. �In other words, the rewrite rules will now transform naive pipes code to high-performance for loops.

What that means for downstream pipes libraries is that any time you have a pipe that is a `for cat` loop, like:

� � myPipe = for cat (\a -> doSomethingWith a)

You can take advantage of these optimizations by adding a rewrite rule like:

� � {-# RULES "p >-> myPipe" forall p . p >-> myPipe = for p (\a -> doSomethingWith a) #-}

This will then trigger all the rest of the optimizations.

Note that I can't just add a general rewrite rule that says:

� � p >-> for cat f = for p f

The reason why is that this is a free theorem that you only get if `f` never `await`s. �I don't know of a way to have rewrite rules detect that sort of condition.

The next most important change is that I finally uploaded the `pipes-safe` change that adds `MonadIO (Base m)` to the class constraint for `MonadSafe`, which means that now downstream libraries can get rid of the `MonadIO (Base m)` constraint from utilities. �(See Pipes.Safe.Prelude for a concrete example of how to do this)

Another important change is that `pipes` now has a QuickCheck test suite for all the `Pipes.Core` category laws (thanks to Csernik Flaviu Andrei) as well as manual proofs of pipes laws, too. �Paolo has also worked out how to prove these laws in Agda for unidirectional pipes, so it shouldn't be very long before there are Agda proofs for the bidirectional category laws.

Also, you can now compile a Haskell98 subset of `pipes` by using `cabal install -f haskell98 pipes` (again thanks to Csernik Flaviu Andrei).

Also, `pipes` has a benchmark suite (thanks to, you guessed it, Csernik Flaviu Andrei).

Another important change is that `Pipes.Lift` now has the super-useful `distribute` function, thanks to Patrick Wheeler. �You can use this to easily write `runEitherP` (I know that Renzo wanted this):

� � runEitherP = runEitherT . distribute

`distribute` is really magical because it works for any monad transformer that implements `MFunctor` and doesn't require any pipes internals to work. �It's pretty sweet.

`pipes-parse` also now re-exports `transFreeT` and also adds `takeProducers`. �This is so that you can write something like the following code that takes the first three words of each line:

� � unlines . transFreeT (unwords . takeProducers 3 . words) . lines

The next thing on my radar is fixing up the `pipes-text` library and then working on a `pipes`-based high-efficiency serialization library.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.

[Carter Schonwald]

you can push haddocks directly:  https://github.com/haskell/hackage-server/issues/56 links to some directions

On Mon, Nov 18, 2013 at 9:49 AM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

I have it on both, as a precaution.  The bottom of `Pipes.Core` has the rewrite rule for `(//>)`.

On 11/18/2013 02:47 AM, Dag Odenhall wrote:

Shouldn’t the for rules be on //>, doesn’t GHC figure out to apply them to for too, then?

On Mon, Nov 18, 2013 at 3:42 AM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

Okay, I'm finally done preparing for my defense so I spent the weekend uploading the latest round of small updates to libraries.

Probably the nicest thing these updates add is a set of high-efficiency rewrite rules in `pipes`.  There are two sets of rules:

1) The first set of rules is in the `Pipes` module and uses the category laws to rewrite things to more optimal versions.  In isolation these rules don't do very much, but they synergize with the second set of rules.  You can find these rules here:

https://github.com/Gabriel439/Haskell-Pipes-Library/blob/ec12094ae9ae89fd9900ba206ec8236867615ec6/src/Pipes.hs#L165

2) The second set of rules is in `Pipes.Prelude`.  These rewrite rules rewrites certain pipes to more efficient for loops when possible.  For example, here's one such rewrite rule:

    p >-> print = for p (\a -> liftIO (Prelude.print a))


So what happens is that if you write something like this:

    P.stdinLn >-> P.map foo >-> P.print

... the second set of rewrite rules will first transform the `map`:

    for P.stdinLn (\a -> yield (foo a)) >-> P.print

... then it will transform the `print`:

    for (for P.stdinLn (\a -> yield (foo a))) (\b -> liftIO (print b))

Then the first set of rewrite rules will kick in, using the associativity law to reorder the for loops:

    for P.stdinLn (\a -> for (yield (foo a)) (\b -> liftIO (print b))

Then the left identity law will kick in, too!

    for P.stdinLn (\a -> liftIO (print (foo a)))

... which is what a `pipes` expert might write by hand.  In other words, the rewrite rules will now transform naive pipes code to high-performance for loops.

What that means for downstream pipes libraries is that any time you have a pipe that is a `for cat` loop, like:

    myPipe = for cat (\a -> doSomethingWith a)

You can take advantage of these optimizations by adding a rewrite rule like:

    {-# RULES "p >-> myPipe" forall p . p >-> myPipe = for p (\a -> doSomethingWith a) #-}

This will then trigger all the rest of the optimizations.

Note that I can't just add a general rewrite rule that says:

    p >-> for cat f = for p f

The reason why is that this is a free theorem that you only get if `f` never `await`s.  I don't know of a way to have rewrite rules detect that sort of condition.

The next most important change is that I finally uploaded the `pipes-safe` change that adds `MonadIO (Base m)` to the class constraint for `MonadSafe`, which means that now downstream libraries can get rid of the `MonadIO (Base m)` constraint from utilities.  (See Pipes.Safe.Prelude for a concrete example of how to do this)

Another important change is that `pipes` now has a QuickCheck test suite for all the `Pipes.Core` category laws (thanks to Csernik Flaviu Andrei) as well as manual proofs of pipes laws, too.  Paolo has also worked out how to prove these laws in Agda for unidirectional pipes, so it shouldn't be very long before there are Agda proofs for the bidirectional category laws.

Also, you can now compile a Haskell98 subset of `pipes` by using `cabal install -f haskell98 pipes` (again thanks to Csernik Flaviu Andrei).

Also, `pipes` has a benchmark suite (thanks to, you guessed it, Csernik Flaviu Andrei).

Another important change is that `Pipes.Lift` now has the super-useful `distribute` function, thanks to Patrick Wheeler.  You can use this to easily write `runEitherP` (I know that Renzo wanted this):

    runEitherP = runEitherT . distribute

`distribute` is really magical because it works for any monad transformer that implements `MFunctor` and doesn't require any pipes internals to work.  It's pretty sweet.

`pipes-parse` also now re-exports `transFreeT` and also adds `takeProducers`.  This is so that you can write something like the following code that takes the first three words of each line:

    unlines . transFreeT (unwords . takeProducers 3 . words) . lines

The next thing on my radar is fixing up the `pipes-text` library and then working on a `pipes`-based high-efficiency serialization library.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

[Tony Day]

Can anyone point me to useful documentation of rewrite rules and GHC?  In particular, I'm interested in whether the rewrites can somehow be picked up by hlint.  It seems like an excellent way to increase pipes-fu.

[Gabriel Gonzalez]

The official documentation on rewrite rules is here:

http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html

On 11/18/2013 07:44 PM, Tony Day wrote:

Can anyone point me to useful documentation of rewrite rules and GHC?� In particular, I'm interested in whether the rewrites can somehow be picked up by hlint.� It seems like an excellent way to increase pipes-fu.

On Tuesday, November 19, 2013 6:34:04 AM UTC+10, Carter Schonwald wrote:

you can push haddocks directly:� https://github.com/haskell/hackage-server/issues/56 links to some directions

On Mon, Nov 18, 2013 at 9:49 AM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

I have it on both, as a precaution.� The bottom of `Pipes.Core` has the rewrite rule for `(//>)`.

On 11/18/2013 02:47 AM, Dag Odenhall wrote:

Shouldn�t the for rules be on //>, doesn�t GHC figure out to apply them to for too, then?

On Mon, Nov 18, 2013 at 3:42 AM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

Okay, I'm finally done preparing for my defense so I spent the weekend uploading the latest round of small updates to libraries.

Probably the nicest thing these updates add is a set of high-efficiency rewrite rules in `pipes`. �There are two sets of rules:

1) The first set of rules is in the `Pipes` module and uses the category laws to rewrite things to more optimal versions. �In isolation these rules don't do very much, but they synergize with the second set of rules. �You can find these rules here:

https://github.com/Gabriel439/Haskell-Pipes-Library/blob/ec12094ae9ae89fd9900ba206ec8236867615ec6/src/Pipes.hs#L165

2) The second set of rules is in `Pipes.Prelude`. �These rewrite rules rewrites certain pipes to more efficient for loops when possible. �For example, here's one such rewrite rule:

� � p >-> print = for p (\a -> liftIO (Prelude.print a))

So what happens is that if you write something like this:

� � P.stdinLn >-> P.map foo >-> P.print

... the second set of rewrite rules will first transform the `map`:

� � for P.stdinLn (\a -> yield (foo a)) >-> P.print

... then it will transform the `print`:

� � for (for P.stdinLn (\a -> yield (foo a))) (\b -> liftIO (print b))

Then the first set of rewrite rules will kick in, using the associativity law to reorder the for loops:

� � for P.stdinLn (\a -> for (yield (foo a)) (\b -> liftIO (print b))

Then the left identity law will kick in, too!

� � for P.stdinLn (\a -> liftIO (print (foo a)))

... which is what a `pipes` expert might write by hand. �In other words, the rewrite rules will now transform naive pipes code to high-performance for loops.

What that means for downstream pipes libraries is that any time you have a pipe that is a `for cat` loop, like:

� � myPipe = for cat (\a -> doSomethingWith a)

You can take advantage of these optimizations by adding a rewrite rule like:

� � {-# RULES "p >-> myPipe" forall p . p >-> myPipe = for p (\a -> doSomethingWith a) #-}

This will then trigger all the rest of the optimizations.

Note that I can't just add a general rewrite rule that says:

� � p >-> for cat f = for p f

The reason why is that this is a free theorem that you only get if `f` never `await`s. �I don't know of a way to have rewrite rules detect that sort of condition.

The next most important change is that I finally uploaded the `pipes-safe` change that adds `MonadIO (Base m)` to the class constraint for `MonadSafe`, which means that now downstream libraries can get rid of the `MonadIO (Base m)` constraint from utilities. �(See Pipes.Safe.Prelude for a concrete example of how to do this)

Another important change is that `pipes` now has a QuickCheck test suite for all the `Pipes.Core` category laws (thanks to Csernik Flaviu Andrei) as well as manual proofs of pipes laws, too. �Paolo has also worked out how to prove these laws in Agda for unidirectional pipes, so it shouldn't be very long before there are Agda proofs for the bidirectional category laws.

Also, you can now compile a Haskell98 subset of `pipes` by using `cabal install -f haskell98 pipes` (again thanks to Csernik Flaviu Andrei).

Also, `pipes` has a benchmark suite (thanks to, you guessed it, Csernik Flaviu Andrei).

Another important change is that `Pipes.Lift` now has the super-useful `distribute` function, thanks to Patrick Wheeler. �You can use this to easily write `runEitherP` (I know that Renzo wanted this):

� � runEitherP = runEitherT . distribute

`distribute` is really magical because it works for any monad transformer that implements `MFunctor` and doesn't require any pipes internals to work. �It's pretty sweet.

`pipes-parse` also now re-exports `transFreeT` and also adds `takeProducers`. �This is so that you can write something like the following code that takes the first three words of each line:

� � unlines . transFreeT (unwords . takeProducers 3 . words) . lines

The next thing on my radar is fixing up the `pipes-text` library and then working on a `pipes`-based high-efficiency serialization library.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

[Pierre R]

Well the hackage links are still broken ...

Two small questions:
  - will you upload the packages to stackage ? (the FPComplete IDE seems like a good tool to help discovering Pipes materials)
  - what is the status of Pipes-safe done I remember hearing about some issues concerning finalization, indexed monads ....

Thanks again for the update.

Cheers

[Dan Burton]

You (Gabriel) should definitely get the pipes ecosystem up on Stackage. It's easy. Just make a pull request, adding your name and packages you will maintain to this file:

https://github.com/fpco/stackage/blob/master/Stackage/Config.hs

If you don't want to be responsible for pipes on Stackage, then I would be more than happy to put it under my name and bridge communication between Stackage and pipes maintenance. I presume, though, that you have no qualms about doing this yourself. Am I right?

-- Dan Burton

[Gabriel Gonzalez]

I really, really want to add `pipes` to Stackage.  I wanted to write the `pipes` tutorial using School of Haskell.

I just haven't had a chance to test it because I use an old Haskell platform.  Can somebody test really quickly that Stackage compiles with `pipes`?  If so, then I'll send the pull request today.

[Gabriel Gonzalez]

As I mentioned in my other reply, if somebody can test Stackage with `pipes` then I'll send a pull request to add it.

The status of `pipes-safe` is that it is pretty much stable.  If I release a separate finalization solution it will be as a separate package.  I can roughly summarize the potential alternative solution that I'm contemplating as something that automatically detects where to insert finalizers, but it's very experimental and pie-in-the-sky.  For right now I still advise that people either use `pipes-safe` or `withXXX` idioms.

However, my higher priority at the moment is making `pipes-safe` form a proper category of its own.  If you guys have read my article on reimplementing the parsing subset of conduits using pipes:

http://www.haskellforall.com/2013/10/how-to-reimplement-conduit-parsing-api.html

... then the idea I have in mind is basically a minor variation on that that appears to form a true category (basically by fixing pushback to correctly propagate further upstream).  If it works out then I will blog more about it and perhaps even switch `pipes-parse` to use this conduit-like type that forms a category.  That would simplify the types greatly and improve type inference.

[Dan Burton]

I just haven't had a chance to test it because I use an old Haskell platform.  Can somebody test really quickly that Stackage compiles with `pipes`?  If so, then I'll send the pull request today.

I tried compiling Stackage when I added my own packages, but it is an onerous process and I gave up after various failed attempts. I submitted the pull request anyways, with the disclaimer that I had not completed the testing process on my own. My pull request was accepted anyways, and I haven't heard anything about my packages causing breakage.

I believe Michael Snoyberg said the other day that they were contemplating the removal of this step (verify on your own that it works) from the process of adding things to Stackage. It is my opinion that if you have already made the good faith effort to make your package(s) be well-behaved members of Hackage, then you're probably good to go and don't need to perform this testing yourself. That is, after all, part of the point of Stackage: they do the testing for you.

Normally I would offer to just do this compile test myself, but due to the "ugh" factor that I've ran into previously while trying to accomplish this same task, I'd really rather leave it to someone else this time.

[Jack Henahan]

For what it’s worth, adding pipes to my FPComplete project was fine, so `pipes` doesn’t seem to step on anything there, but `pipes-parse` failed unless I also included a newer version of `free` than the one in Stackage.

[Gabriel Gonzalez]

I'm not in a hurry to get `pipes-parse` in just yet. Getting `pipes`
alone is enough for me right now.

On 11/21/2013 09:24 AM, Jack Henahan wrote:
> For what it�s worth, adding pipes to my FPComplete project was fine, so `pipes` doesn�t seem to step on anything there, but `pipes-parse` failed unless I also included a newer version of `free` than the one in Stackage.

[Carter Schonwald]

https://github.com/haskell/hackage-server/issues/56 gives links for how to upload locally built haddocks to hackage, worth trying that out

On Thu, Nov 21, 2013 at 1:15 PM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

I'm not in a hurry to get `pipes-parse` in just yet.  Getting `pipes` alone is enough for me right now.

On 11/21/2013 09:24 AM, Jack Henahan wrote:

For what it’s worth, adding pipes to my FPComplete project was fine, so `pipes` doesn’t seem to step on anything there, but `pipes-parse` failed unless I also included a newer version of `free` than the one in Stackage.

On Nov 20, 2013, at 6:46 PM, Dan Burton <danburt...@gmail.com> wrote:

I just haven't had a chance to test it because I use an old Haskell platform.  Can somebody test really quickly that Stackage compiles with `pipes`?  If so, then I'll send the pull request today.

I tried compiling Stackage when I added my own packages, but it is an onerous process and I gave up after various failed attempts. I submitted the pull request anyways, with the disclaimer that I had not completed the testing process on my own. My pull request was accepted anyways, and I haven't heard anything about my packages causing breakage.

I believe Michael Snoyberg said the other day that they were contemplating the removal of this step (verify on your own that it works) from the process of adding things to Stackage. It is my opinion that if you have already made the good faith effort to make your package(s) be well-behaved members of Hackage, then you're probably good to go and don't need to perform this testing yourself. That is, after all, part of the point of Stackage: they do the testing for you.

Normally I would offer to just do this compile test myself, but due to the "ugh" factor that I've ran into previously while trying to accomplish this same task, I'd really rather leave it to someone else this time.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscribe@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscribe@googlegroups.com.

[Gabriel Gonzalez]

Alright, I fixed the docs on Hackage.

On 11/21/2013 11:49 AM, Carter Schonwald wrote:

https://github.com/haskell/hackage-server/issues/56 gives links for how to upload locally built haddocks to hackage, worth trying that out

On Thu, Nov 21, 2013 at 1:15 PM, Gabriel Gonzalez <gabri...@gmail.com> wrote:

I'm not in a hurry to get `pipes-parse` in just yet.  Getting `pipes` alone is enough for me right now.

On 11/21/2013 09:24 AM, Jack Henahan wrote:

For what it’s worth, adding pipes to my FPComplete project was fine, so `pipes` doesn’t seem to step on anything there, but `pipes-parse` failed unless I also included a newer version of `free` than the one in Stackage.


On Nov 20, 2013, at 6:46 PM, Dan Burton <danburt...@gmail.com> wrote:

I just haven't had a chance to test it because I use an old Haskell platform.  Can somebody test really quickly that Stackage compiles with `pipes`?  If so, then I'll send the pull request today.

I tried compiling Stackage when I added my own packages, but it is an onerous process and I gave up after various failed attempts. I submitted the pull request anyways, with the disclaimer that I had not completed the testing process on my own. My pull request was accepted anyways, and I haven't heard anything about my packages causing breakage.

I believe Michael Snoyberg said the other day that they were contemplating the removal of this step (verify on your own that it works) from the process of adding things to Stackage. It is my opinion that if you have already made the good faith effort to make your package(s) be well-behaved members of Hackage, then you're probably good to go and don't need to perform this testing yourself. That is, after all, part of the point of Stackage: they do the testing for you.

Normally I would offer to just do this compile test myself, but due to the "ugh" factor that I've ran into previously while trying to accomplish this same task, I'd really rather leave it to someone else this time.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Haskell Pipes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipe...@googlegroups.com.

[Carter Schonwald]

yay! 

glad i could incidentally help :)