the unauthorized biography of $colon$colon

sweet!
should we worry about bytecode changes triggered by (alleged) documentation-only changes? (I only looked at commit messages)(see e.g., r18230 and r23063)
is the automatic output concise enough to have nightly reports about changes?
adriaan
On Fri, Aug 12, 2011 at 7:53 AM, Paul Phillips <paulp@improving.org> wrote:

Hot off the presses.

 http://mysticpaste.com/view/9676

I chose :: as my subject because he was alive in my grandpappy's time, and as a case class and a collection he's seen the world.

Unfortunately the commit message which accompanies each bytecode diff is not always correct, I believe because when trunk is broken I don't have any jars, so now I need to go collapse the sequences between working builds into single changes and show a range of possible commits.  (This is what I'm talking about when I say "broken build is bad.")

But when it is correct, it's neat.  A few examples below.  And there's all kinds of weird bytecode drift if you look at the whole history: I know what is or was the cause of most things I see, but there should still be plenty of mysteries to solve and things to question.  I'll put the whole repo and tools up as soon as I figure out some details.



=== r17916 ===

commit 4872e1cc0afc6c028b0822616b5d7be48575800b
Author: rytz <rytz@5e8d7ff9-d8ef-0310-90f0-a4852d11357a>
Date:   Sat May 30 07:36:31 2009 +0000

   Named and default arguments
    - MethodTypes now have (params: List[Symbol])
    - "copy"-methods for case classes
    - the "copy" object in the compiler is now called "treeCopy"

   git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@17916 5e8d7ff9-d8ef-0310-90f0-a4852d11357a


diff --git a/scala/collection/immutable/$colon$colon.class b/scala/collection/immutable/$colon$colon.class
index e78bf5e..940f2ab 100644

On 8/11/11 11:49 PM, Adriaan Moors wrote:
> should we worry about bytecode changes triggered by (alleged)
> documentation-only changes? (I only looked at commit messages)
> (see e.g., r18230 and r23063)

I think those are both caused by the commit prior. It's probably my bug
somehow, I wrote this whole thing today. Although, your documentation
for "conforms" is also very suspicious.

> is the automatic output concise enough to have nightly reports about
> changes?

We're not going to let that start slowing us down now! It's pretty
variable. When the changes in the bytecode are a result of changes in
the corresponding code, then it's rate-limited by commit size. When the
compiler starts compiling things differently, all bets are off. But
that's when things should most be examined, so lack of concision is not
a problem.

The attentive student of the earlier paste may find an obscene pattern
matcher regression which went undetected for too long a time.

On 12 August 2011 07:53, Paul Phillips <paulp@improving.org> wrote:

Unfortunately the commit message which accompanies each bytecode diff is not always correct, I believe because when trunk is broken I don't have any jars, so now I need to go collapse the sequences between working builds into single changes and show a range of possible commits.  (This is what I'm talking about when I say "broken build is bad.")

I support "don't break build" camp. If build is broken then usefulness of tools like `git bisect` is greatly reduced. I faced that problem yesterday.
Probably "automatically verify before commit" mechanism would help a lot but I don't know what's general mood here about such solutions. Also, this would require really beefy build farm to get speedy feedback. Not sure if we have one.
--
Grzegorz Kossakowski

On 8/12/11 1:47 AM, Grzegorz Kossakowski wrote:
> Probably "automatically verify before commit" mechanism would help a
> lot but I don't know what's general mood here about such solutions.

It's happening. It's one of my first orders of business after we move
to git. Anyone who feels otherwise had best prepare themselves for the
fight of their lives.

You push to something other than the mainline. A robot monitors that
branch, automatically merges the commit on a test machine and runs the
test suite. If everything passes, it pushes it to the mainline. *Only
the robot can commit to the mainline*. Voila, the build is never broken
again.

> Also, this would require really beefy build farm to get speedy
> feedback. Not sure if we have one.

Don't need speedy feedback. Commit instantly, don't worry about it.
Reality will take care of supplying you with any needed feedback.