Bug with ScalaCheck's Arbitrary?

On Thu, Oct 07, 2010 at 05:43:02PM -0300, Daniel Sobral wrote:
> I'm writing some tests for the Scala library using ScalaCheck, and
> something very strange is happening: Arbitrary.arbitrary[Boolean]
> always returns true. Is this a known bug? Given that it is
> Scala-embedded ScalaCheck's related, where would I look it up?

I found it. That's quite a serious bug. Every generator is created
with its last value cut off. More noticeable with a list of booleans
than some other types.

I'll fix it in trunk and the real scalacheck. Nobody consulted me about
dropping the scalacheck source into trunk so I don't know who is
responsible for keeping them in sync. I hope the answer to that doesn't
involve lots of blank paper.

On Thu, Oct 07, 2010 at 05:43:02PM -0300, Daniel Sobral wrote:
> I'm writing some tests for the Scala library using ScalaCheck, and
> something very strange is happening: Arbitrary.arbitrary[Boolean]
> always returns true. Is this a known bug? Given that it is
> Scala-embedded ScalaCheck's related, where would I look it up?

I find it was fixed in scalacheck trunk in r508 july 29th. It merrily
lives on in scala trunk, providing yet another powerful argument for not
dumping a huge blob of code into a repository and then hoping it takes
care of itself. Does anyone know what plan if any is in place for
tracking scalacheck?

Another recent example where bugs fixed at the source find refuge in
trunk:

https://lampsvn.epfl.ch/trac/scala/ticket/3629

Hey Paul,

After some discussion, we've decided to avoid the previous approach of
keeping a scalacheck jar in trunk. Some time ago this caused binary
compatibility errors when library code changed (collections, last time).

Two other approaches presented themselves - first was keeping an svn
external link to a scalacheck branch. Some people were heavily against
this, as it made hard to track which version of scalacheck a certain
branch or tagged version was compiled and successfully tested with.

The other was to keep a scalacheck copies in trunk. Whenever something
goes wrong due to our changes, the recipe was to update the copies.
There is a script called scalacheckupdate, which updates the sources for
scalacheck from an svn branch.

Alex

> I find it was fixed in scalacheck trunk in r508 july 29th. It merrily
> lives on in scala trunk, providing yet another powerful argument for not
> dumping a huge blob of code into a repository and then hoping it takes
> care of itself. Does anyone know what plan if any is in place for
> tracking scalacheck?
>

On Fri, Oct 08, 2010 at 09:35:11AM +0200, Aleksandar Prokopec wrote:
> After some discussion, we've decided to avoid the previous approach of
> keeping a scalacheck jar in trunk. Some time ago this caused binary
> compatibility errors when library code changed (collections, last
> time).

I am all for the pursuit of having a working scalacheck in trunk. The
issue is that branching someone else's repo imposes a significant
obligation. There are a lot of ways one might deal with it, but it has
to be dealt with. I'm not really a fan of spending time diagnosing and
fixing a bug only to find it was fixed two months ago somewhere else.

I inherit all unmet obligations by default (self-imposed, but
nonetheless) which means I have an interest in how things come together
whether either of us prefers this or not. And while you're under no
obligation to include me in "some discussion", I'm the only scalacheck
committer in this group, a fact I would have hoped would make my input
worthy of solicitation.

So can we pinpoint this one thing: who is the responsible party for
following changes in scalacheck and importing critical bugfixes like the
one from july 29th? (I am not volunteering for the role.) And I'll leave
it for another day, but that question needs to be answered about all
imported source, the more so if it has been locally modified. I take
responsibility for jline but that's not too severe a challenge since the
main fork is abandonware.

Email Ricky and ask?

On Friday, October 8, 2010, Paul Phillips wrote:
> On Fri, Oct 08, 2010 at 09:35:11AM +0200, Aleksandar Prokopec wrote:
>> After some discussion, we've decided to avoid the previous approach of
>> keeping a scalacheck jar in trunk. Some time ago this caused binary
>> compatibility errors when library code changed (collections, last
>> time).
>
> I am all for the pursuit of having a working scalacheck in trunk.  The
> issue is that branching someone else's repo imposes a significant
> obligation.  There are a lot of ways one might deal with it, but it has
> to be dealt with.  I'm not really a fan of spending time diagnosing and
> fixing a bug only to find it was fixed two months ago somewhere else.
>
> I inherit all unmet obligations by default (self-imposed, but
> nonetheless) which means I have an interest in how things come together
> whether either of us prefers this or not.  And while you're under no
> obligation to include me in "some discussion", I'm the only scalacheck
> committer in this group, a fact I would have hoped would make my input
> worthy of solicitation.
>
> So can we pinpoint this one thing: who is the responsible party for
> following changes in scalacheck and importing critical bugfixes like the
> one from july 29th? (I am not volunteering for the role.) And I'll leave
> it for another day, but that question needs to be answered about all
> imported source, the more so if it has been locally modified.  I take
> responsibility for jline but that's not too severe a challenge since the
> main fork is abandonware.
>
> --
> Paul Phillips      | These are the climbs that apply men's soles.
> Apatheist          |
> Empiricist         |
> pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------
>

> I inherit all unmet obligations by default (self-imposed, but
> nonetheless) which means I have an interest in how things come together
> whether either of us prefers this or not. And while you're under no
> obligation to include me in "some discussion", I'm the only scalacheck
> committer in this group, a fact I would have hoped would make my input
> worthy of solicitation.
>
>

Sorry for omitting you from d iscussion. This was discussed on a
Scala meeting on the 27th July, and mentioned in the GoogleWave we've
used back then. I didn't write notes that time, and implicitly thought
you saw it there and were aware of it.

But, you're right - I've had a few followup discussions with the people
in the lab about SVN externals, etc. These were not written down
anywhere. In the future, I will keep you informed.

> So can we pinpoint this one thing: who is the responsible party for
> following changes in scalacheck and importing critical bugfixes like the
> one from july 29th? (I am not volunteering for the role.)

I guess I am currently the responsible party for keeping scalacheck in
check, since I've originally made changes. However, I do currently not
have access to the its scala-nightly branch in the googlecode scalacheck
repo. I'll talk to Rickard Nilsson about this.

> And I'll leave
> it for another day, but that question needs to be answered about all
> imported source, the more so if it has been locally modified.
>

The only local modification wrt scalacheck scala-nightly I'm aware of
was removing one source file - which relies on the scalatools package.

On Fri, Oct 08, 2010 at 06:02:18PM +0200, √iktor Klang wrote:
> Email Ricky and ask?

And ask him what?

I've just rechecked my e-mails. Just to clarify the below:
- it was agreed that I pull changes from the scalanightly branch to
scala trunk
- if Rickard or other committers make some changes in the scalacheck
repo, he just promotes them to the scalanightly branch
If this process is or ever becomes a burden to scalacheck maintainers, I
will volunteer to become a committer there, in order to fix issues that
might arise.

> I guess I am currently the responsible party for keeping scalacheck in
> check, since I've originally made changes. However, I do currently not
> have access to the its scala-nightly branch in the googlecode scalacheck
> repo. I'll talk to Rickard Nilsson about this.
>
>

On Fri, Oct 08, 2010 at 06:08:47PM +0200, Aleksandar Prokopec wrote:
> Sorry for omitting you from d iscussion. This was discussed on a Scala
> meeting on the 27th July, and mentioned in the GoogleWave we've used
> back then. I didn't write notes that time, and implicitly thought you
> saw it there and were aware of it.

I know my time zone doesn't make it that easy to keep me in the loop.
And often by the time I hear about something like this it is a fait
accompli, at which point I am more likely to try to preserve whatever
capital I have than to try to move a boat which is halfway into the
slip.

I propose there is a relatively inexpensive measure we could take to
achieve better outcomes, and that is: if I heard about this sort of
thing earlier (like before the meeting where it is discussed and a
course of action is chosen which implicitly must be "unseated" ) then I
could inject whatever I know earlier in the process. Even if I'm not
able to be present for meetings in the middle of my night, I don't think
it would hurt too much to have a little printout of an email standing in
for me. You could draw a funny moustache on it.

Maybe meeting agendas are already created beforehand - I've seen them
before, somewhere, but I don't generally. I don't want to impose new
organizational burdens on anyone here, but I am morally certain we can
all save on total effort if I can find out how the wheels are turning
before the gears start to grind.

On 10/08/2010 12:35 AM, Aleksandar Prokopec wrote:
>
> Hey Paul,
>
> After some discussion, we've decided to avoid the previous approach of
> keeping a scalacheck jar in trunk. Some time ago this caused binary
> compatibility errors when library code changed (collections, last time).
>
> Two other approaches presented themselves - first was keeping an svn
> external link to a scalacheck branch. Some people were heavily against
> this, as it made hard to track which version of scalacheck a certain
> branch or tagged version was compiled and successfully tested with.

One can use an svn external with a fixed revision, so Scala's checkout
do not automatically pull new commits from scalacheck. You can put -r
in the external line, such as the following:

-r 1234 http://example.com/repos/zig foo/bar

That way, the Scala project can decide if and when they want to use an
updated revision from the scalacheck repository.

Blair

On 10/08/2010 09:29 AM, Aleksandar Prokopec wrote:
> I've just rechecked my e-mails. Just to clarify the below:
> - it was agreed that I pull changes from the scalanightly branch to
> scala trunk
> - if Rickard or other committers make some changes in the scalacheck
> repo, he just promotes them to the scalanightly branch
> If this process is or ever becomes a burden to scalacheck maintainers, I
> will volunteer to become a committer there, in order to fix issues that
> might arise.
>
>> I guess I am currently the responsible party for keeping scalacheck in
>> check, since I've originally made changes. However, I do currently not
>> have access to the its scala-nightly branch in the googlecode scalacheck
>> repo. I'll talk to Rickard Nilsson about this.

Is the intention to have all commits in scalacheck trunk be merged to
scalacheck's scalanighltybranch? If so, that sounds like more work than
necessary. I suggest using an svn:external with a fixed revision number
to scalacheck's trunk, then when you want to test a new scalacheck
revision, just bump the revision number in the external, if it builds,
then commit the svn:external change.

There is one advantage to merging the source into scala's repository and
that is is Google Code is down, then the checkout can fail. In that,
you can take a look at Piston for doing the mirroring:

http://piston.rubyforge.org/

Blair

Den 2010-10-08 20:55:47 skrev Blair Zajac :

> On 10/08/2010 09:29 AM, Aleksandar Prokopec wrote:
>> I've just rechecked my e-mails. Just to clarify the below:
>> - it was agreed that I pull changes from the scalanightly branch to
>> scala trunk
>> - if Rickard or other committers make some changes in the scalacheck
>> repo, he just promotes them to the scalanightly branch
>> If this process is or ever becomes a burden to scalacheck maintainers, I
>> will volunteer to become a committer there, in order to fix issues that
>> might arise.
>>
>>> I guess I am currently the responsible party for keeping scalacheck in
>>> check, since I've originally made changes. However, I do currently not
>>> have access to the its scala-nightly branch in the googlecode
>>> scalacheck
>>> repo. I'll talk to Rickard Nilsson about this.
>
> Is the intention to have all commits in scalacheck trunk be merged to
> scalacheck's scalanighltybranch? If so, that sounds like more work than
> necessary. I suggest using an svn:external with a fixed revision number
> to scalacheck's trunk, then when you want to test a new scalacheck
> revision, just bump the revision number in the external, if it builds,
> then commit the svn:external change.

The reason for the separate scalanightly branch is if I ever need to
make changes in ScalaCheck for it to compile with Scala nightly,
and those changes breaks compilation with the current Scala version.
That happened before 2.8 was released but it might be unnecessary
now, maybe such rather extraordinary situations could be handled
in some other way?

/ Rickard

The reason for the separate scalanightly branch is if I ever need to
make changes in ScalaCheck for it to compile with Scala nightly,
and those changes breaks compilation with the current Scala version.
That happened before 2.8 was released but it might be unnecessary
now, maybe such rather extraordinary situations could be handled
in some other way?