0.4 release of scalaz-stream against 7.0.6 and 7.1.0-M6

[Paul Chiusano]

Thanks to all our contributors! You can get it at:

resolvers += "Scalaz Bintray Repo" at "http://dl.bintray.com/scalaz/releases"

// Against Scalaz 7.0.6

libraryDependencies += "org.scalaz.stream" %% "scalaz-stream" % "0.4"

// Against Scalaz 7.1.0-M6

libraryDependencies += "org.scalaz.stream" %% "scalaz-stream" % "0.4a"

There is a lot of new stuff in this release, though it should be mostly source compatible. Frank Thomas has been nice enough to maintain release notes which I think are up to date. (Frank, feel free to chime in and/or update the page if those notes are missing anything). There are only a few source-breaking changes that I am aware of, caused by moving some definitions around, see the release notes.

We are hoping to release 0.5 relatively soon, Pavel is working on a change to the internal representation of Process that addresses some performance and subtle resource safety issues. After that, I'll feel like the fundamentals of the library are pretty solid and would like to start working on polishing the library and working toward a 1.0.

Cheers,

Paul :)

[Pascal Voitot Dev]

great work guys ;)

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

[Frank Thomas]

I'd like to add that the ScalaDoc for this release is available at http://docs.typelevel.org/api/scalaz-stream/stable/0.4/doc/

Cheers
Frank

P.S.: The release notes should be up to date, to the best of my knowledge.

[Paul Chiusano]

Also, wanted to give a quick mention of an interesting (very new) project that is using scalaz-stream, the scodec-stream project. I've been working on it with Michael Pilquist - it's a library for streaming binary decoding and encoding, built using scodec and scalaz-stream.

Also see projects that are using scalaz-stream and feel free to submit a PR if you are using the library and want to link to it in the README.

Cheers,

Paul :)

[etorreborre]

Great job guys!

It's way too early to announce a new project on the list but I'm largely basing the next version of specs2 on scalaz-stream. I think I got some interesting results out of my recent experiments and I will present them at the next LambdaJam in Brisbane.

I have one issue however. Some of the things I'm doing rely on the the "lazy" branch that Runar did and apparently this didn't get mixed in. Is it because this is going to be superseded anyway by Pavel's new internal model or for another reason? Because I really need this!

Thanks,

Eric.

[Paul Chiusano]

Yep, the lazy branch will be superseded by the stuff that Pavel is working on. :)

[Pascal Voitot Dev]

Hey guys,

my 2p question: what do you think about the reactive-streams stuff recently released (and.... potentially implement the SPI)?

Pascal

[Pavel Chlupacek]

Pascal, 

I just briefly looked at stuff and not sure if I understand it correctly. 

to be honest I am not really friend of this manifestoXXX stuff. I think spending more resources on actual product and less resources on that sort of marketing will be IMHO much better. I just much rather work on concrete product than a bunch of interfaces and what-if causalities.

From the paper I have read I have feeling bit of over-engineering, where simple stuff (i.e. back pressure) that we effectively have in scalaz-stream since the very early time and in fact sort  of for-free is indicated as one of the main `reasons` for reactive-streams. On other hand I am missing resource safety story, type awareness, execution control, etc, that I think are in fact more important. 

I can’t refrain from the feeling that the stuff is market-ware with reinventing of the wheel in not-that-good fashion. 

I hope I am at least partially wrong there….

I have no idea what will be the benefits of implementing the proposed SPI for scalaz-streams. I don’t see any ecosystem so far behind it. Maybe after we will see more products really using it I think we shall not have any significant issues implementing that in scalaz.stream. 

Pavel. 

[Pascal Voitot Dev]

Hi Pavel,

Actually this was a 2p question ;);););)

As you, I don't like any manifesto stuff... I'm not receptive to any marketting arguments!

I don't think reactivestreaming will change our Scala stream world much because it's more something aimed at standardizing streaming approach following RX philosophy than a real evolution. Actually I think it's less interesting than Iteratee for Scala because it doesn't bring much more type safety, error management, resource control (except back-pressure maybe) etc...
Actually this is RX made more generic to be portable for every language and technology. As any generic approach, it gets the intersection of everything making an average (good or bad, future will say???)! I can understand why Typesafe tries to push this kind of approach with respect to their policy for Akka & Scala. One can disagree but this is a fact and it doesn't prevent us from studying more innovative solutions...

Anyway, I think the real interest of reactive-streaming is to focus on the back-pressure aspects of streaming which is something people don't really take into account or understand in general. This is a complex subject and managing precise back-pressure with models like Iteratees isn't so obvious IMHO. BTW, I think we could try to bring tooling for back-pressure in scalaz-stream...

I believe scalaz-stream is the only "post-iteratee" technology that seems to bring something better to the subject in the Scala world.

Yet, I think implementing reactive-streaming SPI with scalaz-stream could draw a bridge between worlds: one could feed/consume a scalaz-stream very easily with/from a AkkaStream or RxStream for example and then use the power of scalaz-stream "purer" API. It doesn't reduce scalaz-stream excellence while showing it can plug on other APIs & provide much more. I also think that with your recent evolutions, scalaz-stream becomes so powerful at merging streams that it would a shame not to allow connections with these "more basic" streams.

Pascal