[scalaz] scalaz 7.0.2 released

[Lars Hupel]

Just staged on Sonatype:

"org.scalaz" %% "scalaz-core" % "7.0.2"

for Scala binary versions 2.9.2, 2.9.3 and 2.10.

This is a maintenance release for the 7.0.x series. It's a drop-in
replacement for 7.0.0 which is fully* binary backwards compatible
(tested with MiMa)!

* There is one minor exception: New methods have been added to sealed
traits, which is fine if nobody extends those traits using Java.

That means: Libraries compiled against 7.0.0 or 7.0.1 will continue to
work (without recompilation) with version 7.0.2. However, the inverse
direction is not supported.

This release contains two small bug fixes and a couple of additions.
Please refer to the release notes at the end of this mail for a full list.


***

The full list of published submodules is available with this Nexus search:

<https://oss.sonatype.org/index.html#nexus-search;gav~org.scalaz~~7.0.2~~>

***

RELEASE NOTES

New features

* new Lens methods: modo and assigno which modify and return the old value
* add excepting method on Validation to filter the Success side;
generalizes ensure
* safe init and last for NonEmptyList
* sorting functions on NonEmptyList

Fixes

* more trampolining in IO
* new withFilter method in EitherT, aliasing to filter, to work around
warning

<https://github.com/scalaz/scalaz/wiki/7.0.2>

[Tony Morris]

Thanks Legend Lars.

--
Tony Morris
http://tmorris.net/

[Chris Marshall]

Great stuff! Is there a planned release date for the 7.1.x line?

Chris

--
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/groups/opt_out.

[Chris Marshall]

It seems like the build 7.0.2 has "broken" specs2 (v2.0). I have a test which should fail. Run with scalaz 7.0.0 and 7.0.1 it does fail. Run with 7.0.2 it hangs indefinitely. Here's the stack:

Name: main

State: WAITING on java.util.concurrent.CountDownLatch$Sync@48f6492b

Total blocked: 29  Total waited: 1

Stack trace: 

sun.misc.Unsafe.park(Native Method)

java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)

java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)

scalaz.concurrent.Promise$class.get(Promise.scala:20)

scalaz.concurrent.PromiseFunctions$$anon$4.get(Promise.scala:193)

org.specs2.specification.PromisedExecutingFragment.get(ExecutedFragment.scala:157)

org.specs2.specification.ExecutingSpecification$$anonfun$foreach$1.apply(ExecutingSpecification.scala:23)

org.specs2.specification.ExecutingSpecification$$anonfun$foreach$1.apply(ExecutingSpecification.scala:23)

scala.collection.Iterator$$anon$11.next(Iterator.scala:328)

scala.collection.Iterator$class.foreach(Iterator.scala:727)

scala.collection.AbstractIterator.foreach(Iterator.scala:1157)

scala.collection.IterableLike$class.foreach(IterableLike.scala:72)

scala.collection.SeqLike$$anon$2.foreach(SeqLike.scala:635)

scala.collection.GenTraversableViewLike$Mapped$class.foreach(GenTraversableViewLike.scala:80)

scala.collection.SeqViewLike$$anon$3.foreach(SeqViewLike.scala:78)

scala.collection.TraversableOnce$class.foldLeft(TraversableOnce.scala:144)

scala.collection.SeqViewLike$AbstractTransformed.foldLeft(SeqViewLike.scala:43)

scalaz.std.IterableInstances$$anon$5.foldLeft(Iterable.scala:66)

scalaz.std.IterableInstances$$anon$5.foldLeft(Iterable.scala:61)

scalaz.Generators$$anon$2.reduce(Generator.scala:27)

org.specs2.collection.Iterablex$ExtendedIterable.reduceWith(Iterablex.scala:107)

org.specs2.reporter.DefaultStoring$class.org$specs2$reporter$DefaultStoring$$statisticsTotals(Storing.scala:36)

org.specs2.reporter.DefaultStoring$$anonfun$store$1.apply(Storing.scala:30)

org.specs2.reporter.DefaultStoring$$anonfun$store$1.apply(Storing.scala:27)

scalaz.syntax.IdOps$class.$bar$greater(IdOps.scala:15)

scalaz.syntax.ToIdOps$$anon$1.$bar$greater(IdOps.scala:78)

org.specs2.reporter.JUnitReporter$class.report(JUnitReporter.scala:43)

org.specs2.runner.JUnitRunner$$anon$3.report(JUnitRunner.scala:43)

org.specs2.runner.JUnitRunner.run(JUnitRunner.scala:50)

junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)

org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:523)

org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1424)

org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:852)

org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1903)

org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:804)

org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)

sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

java.lang.reflect.Method.invoke(Method.java:601)

org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

org.apache.tools.ant.Task.perform(Task.java:348)

org.apache.tools.ant.Target.execute(Target.java:435)

org.apache.tools.ant.Target.performTasks(Target.java:456)

org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)

org.apache.tools.ant.Project.executeTarget(Project.java:1364)

org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)

org.apache.tools.ant.Project.executeTargets(Project.java:1248)

org.apache.tools.ant.Main.runBuild(Main.java:851)

org.apache.tools.ant.Main.startAnt(Main.java:235)

org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)

org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

[Lars Hupel]

Hi Chris,

I have no idea what's going on there. Is this a spurious error or
reproducible? I tried running the example from the specs2 homepage with
7.0.2, and a failing test failed as expected.

This is the diff between 7.0.1 and 7.0.2:
<https://github.com/scalaz/scalaz/compare/v7.0.1...v7.0.2>. I can't see
anything relevant to the stack trace there.

I already pinged Eric on that issue, let's see if we can work it out.

Cheers
Lars

[Lars Hupel]

> Great stuff! Is there a planned release date for the 7.1.x line?

Not yet. I originally planned a milestone release for the past week, but
since a couple of new things got introduced then, I was postponing it a
little.

Since I have a number of things on my to-do list, I don't think that we
can get a final release this year. However, I'm confident that we can
enter the RC cycle for scalaz 7.1.0 around the same time as Scala 2.11.

[etorreborre]

I don't see anything wrong really.

I was planning to release 2.1 with scalaz 7.0.2 as a dependency tomorrow. I just updated the dependency to scalaz-7.0.2 and all my tests are passing ok, both locally and on the Travis server (which sometimes shows better concurrency issues).

Maybe you can try the latest 2.1-SNAPSHOT and see if anything changes (but that would be strange). Otherwise I think that a reduced use case is going to be necessary so that we can undo the 7.0.1 -> 7.0.2 commits one by one and see which one precisely is problematic.

E.

[Mark Hibberd]

On Tue, Jul 9, 2013 at 9:22 PM, etorreborre <etorr...@gmail.com> wrote:
> Otherwise I think that a reduced use case is going
> to be necessary so that we can undo the 7.0.1 -> 7.0.2 commits one by one
> and see which one precisely is problematic.

The only thing near it is -
https://github.com/scalaz/scalaz/commit/718ef70c90fb464a612fb75ad238e2ea45a668cf
but I can't see anything obvious.

[Chris Marshall]

Well, it's reproducible in that it always fails with 7.0.2 and always passes in 7.0.0. I think that this is a coincidence, however - the issue is really with my own code and is a race condition. There must be something about running with 7.0.2 which means it's tripped. Apologies for the misdirection

Chris

[Chris Marshall]

I should add that the only difference is the scalaz version at runtime (so it was reasonable-ish of me to assume this was the cause)

[etorreborre]

You might not be the only one with this issue: https://twitter.com/noelmarkham/status/354624685104824320.

[Chris Marshall]

The "bug" in my code was along these lines:

in package a.b.c I have this structure

  package a.b.c

  trait Oxbow {

     val Bippy = a.b.c.d.Bippy //**

  }

  object Oxbow extends Oxbow

Where and I have a.b.c.d.Bippy, which looks like:

  package a.b.c.d

  object Bippy {

    val lakes = 0 //$$

  }

But I also have in a.b.c

  packge a.b

  package object c extends Oxbow

Now in my tests, I had one test doing "import a.b.c._" but in another test, I was doing an "import a.b.c.Oxbow._". In *neither test* was I accessing the values Bippy or lakes

Where I sent you the thread stack from the apparently blocked thread, two other threads' stacks looked like this:

  a.b.c.Oxbow$class.$init$(Oxbow.scala:45) //this is line **

  a.b.c.package$.<init>(package.scala:89)

  a.b.c.package$.<clinit>(package.scala)

  a.b.c.lang.ConversionsSpec$$anonfun$4$$anonfun$apply$2.apply$mcZI$sp(ConversionsSpec.scala:54)

...

And:

  a.b.c.d.Bippy$.<init>(Bippy.scala:245) //this is line $$

  a.b.c.d.Bippy$.<clinit>(Bippy.scala)

  a.b.c.Oxbow$class.$init$(Oxbow.scala:45)

  a.b.c.Oxbow$.<init>(Oxbow.scala:235)

  a.b.c.Oxbow$.<clinit>(Oxbow.scala)

There was no deadlock here (according to JConsole) - both threads were in state "RUNNABLE" and I'm somewhat confused because the threads were quite plainly blocked (or at least over a period of ten minutes they did not change). There's no obvious reason for anything to be blocked either. Does anyone have a view on what might have been going on?

Chris

[Chris Marshall]

I've created a test case which can reproduce the deadlock. I think it's a bug in scalac  - I mailed it to the scala-user group here: https://groups.google.com/d/msg/scala-user/F8A4u-LyhGM/0kwMPnir4qAJ

Chris

[etorreborre]

That's good to have a test case, especially one that doesn't depend on Scalaz and specs2. This means for me that I can do a 2.1 release soon :-)

Thanks for the update.

E.