[scala] unexpectedly abrupt end for such an innocent mistake

[Meredith Gregory]

All,

See the trace below. Is this how we'd like this error to be handled?

Best wishes,

--greg

Welcome to Scala version 2.7.4.final (Java HotSpot(TM) Client VM, Java 1.5.0_16).
Type in expressions to have them evaluated.
Type :help for more information.

scala> List( 1, 2, 3 ) match { case List( 1, x* ) => x case _ => throw new Exception() }
Exception in thread "main" java.lang.Error: symbol value x does not exist in line1$object$$iw$$iw.<init>
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:912)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:402)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:455)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:939)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genStat(GenICode.scala:171)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genStat$1.apply(GenICode.scala:146)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genStat$1.apply(GenICode.scala:145)
    at scala.List.foreach(List.scala:841)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genStat(GenICode.scala:145)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:938)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:114)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:71)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:71)
    at scala.List.foreach(List.scala:841)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:71)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:136)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:90)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:71)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:71)
    at scala.List.foreach(List.scala:841)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:71)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:81)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:67)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:63)
    at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:267)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:246)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:246)
    at scala.Iterator$class.foreach(Iterator.scala:414)
    at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
    at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:246)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:56)
    at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
    at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
    at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
    at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:494)
    at scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
    at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
    at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
    at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
    at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
    at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

Process inferior-scala exited abnormally with code 1


--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Paul Phillips-3]

On Fri, Jun 26, 2009 at 02:34:06PM -0700, Meredith Gregory wrote:
> See the trace below. Is this how we'd like this error to be handled?

There was a fierce debate between outputting a brief error message and
spewing a long stack trace, but in the end we went with the stack trace.

(Perhaps you don't realize how "Is this how we'd like this error to be
handled?" comes across.)

Can I give some general encouragement to people to use the bug database
to report bugs rather than sending them to the lists, unless there is
something super unusual and fascinating about that particular bug,
keeping in mind there are hundreds of open tickets which should be no
less important for being a little (or a lot) older.

--
Paul Phillips      | Where there's smoke, there's mirrors!
Apatheist          |
Empiricist         |
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

[Meredith Gregory]

Paul,

Thanks for all your kind feedback. i wasn't really concerned about the long stack trace. i was concerned about the termination of the REPL process.

Best wishes,

--greg

On Fri, Jun 26, 2009 at 2:44 PM, Paul Phillips <paulp@...> wrote:

On Fri, Jun 26, 2009 at 02:34:06PM -0700, Meredith Gregory wrote:
> See the trace below. Is this how we'd like this error to be handled?

There was a fierce debate between outputting a brief error message and
spewing a long stack trace, but in the end we went with the stack trace.

(Perhaps you don't realize how "Is this how we'd like this error to be
handled?" comes across.)

Can I give some general encouragement to people to use the bug database
to report bugs rather than sending them to the lists, unless there is
something super unusual and fascinating about that particular bug,
keeping in mind there are hundreds of open tickets which should be no
less important for being a little (or a lot) older.

--
Paul Phillips      | Where there's smoke, there's mirrors!
Apatheist          |
Empiricist         |
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Paul Phillips-3]

On Fri, Jun 26, 2009 at 02:47:35PM -0700, Meredith Gregory wrote:
> Thanks for all your kind feedback. i wasn't really concerned about the
> long stack trace. i was concerned about the termination of the REPL
> process.

Oh, I realize.  My point is that there are endless ways to crash the
repl, and this bug is in no way unique or even unusual, so it should
probably get in line behind all the others.  I was making a pretty good
dent in the database for a while there but I decided I'd spent enough
effort on one-bug-at-a-time and am trying to get whole handfuls.  This
means that for now they're stacking up again.

--
Paul Phillips      | Giving every man a vote has no more made men wise
Everyman           | and free than Christianity has made them good.
Empiricist         |     -- H. L. Mencken
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

[Raoul Duke]

> This means that for now they're stacking up again.

so what does this mean? any of:

* scala needs a tighter development proces
* scala is happening too fast
* scala is insufficiently staffed
* software is just plain hard
* all us whiners should be assigned one bug to fix a week.

[Meredith Gregory]

Paul,

Cool. i honestly had no idea if it was intended behavior or not. i thought i'd check, because it might not be seen as a bug.

Best wishes,

--greg

On Fri, Jun 26, 2009 at 3:08 PM, Paul Phillips <paulp@...> wrote:

On Fri, Jun 26, 2009 at 02:47:35PM -0700, Meredith Gregory wrote:
> Thanks for all your kind feedback. i wasn't really concerned about the
> long stack trace. i was concerned about the termination of the REPL
> process.

Oh, I realize.  My point is that there are endless ways to crash the
repl, and this bug is in no way unique or even unusual, so it should
probably get in line behind all the others.  I was making a pretty good
dent in the database for a while there but I decided I'd spent enough
effort on one-bug-at-a-time and am trying to get whole handfuls.  This
means that for now they're stacking up again.

--
Paul Phillips      | Giving every man a vote has no more made men wise
Everyman           | and free than Christianity has made them good.
Empiricist         |     -- H. L. Mencken
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Ismael Juma]

On Fri, 2009-06-26 at 15:13 -0700, Meredith Gregory wrote:
> Paul,
>
> Cool. i honestly had no idea if it was intended behavior or not. i
> thought i'd check, because it might not be seen as a bug.

If the compiler or interpreter show a stacktrace that is not caused by
an exception thrown by your code, it's generally safe to assume that
it's a bug.

Best,
Ismael

[Ismael Juma]

On Fri, 2009-06-26 at 15:13 -0700, Raoul Duke wrote:
> * scala is insufficiently staffed

This is the main one.

> * software is just plain hard

A bit of this.

> * all us whiners should be assigned one bug to fix a week.

If us whiners actually solved one bug a week instead of just being
assigned one, maybe the problem would go away. :)

Best,
Ismael

[Paul Phillips-3]

On Fri, Jun 26, 2009 at 03:13:01PM -0700, Raoul Duke wrote:
> * scala needs a tighter development proces
> * scala is happening too fast
> * scala is insufficiently staffed
> * software is just plain hard
> * all us whiners should be assigned one bug to fix a week.

All open source projects are insufficiently staffed, so that one is
safe.  Learning the compiler well enough to fix even simple-ish bugs
took me months, so the barrier to entry is high.  It's very difficult to
be sure a bug fix hasn't broken something else without rebuilding and
running the whole test suite.  Very slight changes in a trait can force
rebuilding many files because of the extensive interdependencies, and
the ant-based build system has no intelligence at all so you're on your
own if you want to do anything less than a total clean.

In summary, there are a lot of little things that conspire together to
make it a very slow process.  And, fixing bugs is pretty much as unsexy
as it gets, so you have to be really into it for its own sake on top of
everything else.  I probably now know approximately how to fix every bug
in the database except those revolving around some abstruse aspect of
the type system, but even if I worked on bugs full time, they're opening
faster than I can close them.

Fortunately most of them do things like crash the compiler, or fail to
infer the type when you think they should, or involve other behaviors
which though annoying should not be deal breakers.  Scala is still very
useful, but it could be a lot more robust at the edges.

I won't say development is happening too fast, but it's true that having
a bunch of huge patches land on trunk makes life interesting.  We don't
need lots of people trying to fix one bug a week -- we need a very small
number of people to invest the time and effort necessary to learn the
compiler, and then for them to fix a few bugs a day.

(Anyone out there with nothing to do for the next year or so, who needs
no paycheck and enjoys closing tickets? Opportunities abound!)

--
Paul Phillips      | It's not enough to bash in heads - you've got to
Apatheist          | bash in minds.
Empiricist         |     -- Capt Hammer
all hip pupils!    |----------* http://www.improving.org/paulp/ *----------

[Raoul Duke]

> On Fri, Jun 26, 2009 at 3:31 PM, Paul Phillips<paulp@...> wrote:

ok, that sounds like pretty classical less-than-idea software
engineering! more is the pity. i mean, in some sense it is the "good
problems to have" because it means Scala caught on, for which we are
(perhaps not always obviously) grateful -- thank you! -- but i feel
like it is past the point where somebody has to actually step up and
deal with the blankety-blank technical debt, already.

here i am living in a glass house, by the way :-)

sincerely.

[Paul Phillips-3]

On Fri, Jun 26, 2009 at 03:36:57PM -0700, Raoul Duke wrote:
> ok, that sounds like pretty classical less-than-idea software
> engineering! more is the pity. i mean, in some sense it is the "good
> problems to have" because it means Scala caught on, for which we are
> (perhaps not always obviously) grateful -- thank you! -- but i feel
> like it is past the point where somebody has to actually step up and
> deal with the blankety-blank technical debt, already.

I have a handle on a lot of it.  I think if I had one more person of
comaprable ability working full time under my guidance, we would cover a
lot of ground in a hurry.  I'm sure money can be thrown at this problem,
but I'm not interested in handling logistics or organizing or etc, I am
only interested in writing software.

--
Paul Phillips      | A Sunday school is a prison in which children do
Stickler           | penance for the evil conscience of their parents.
Empiricist         |     -- H. L. Mencken
i'll ship a pulp   |----------* http://www.improving.org/paulp/ *----------

[Raoul Duke]

> I have a handle on a lot of it.  I think if I had one more person of
> comaprable ability working full time under my guidance, we would cover a
> lot of ground in a hurry.  I'm sure money can be thrown at this problem,
> but I'm not interested in handling logistics or organizing or etc, I am
> only interested in writing software.

many thanks to all who have brought Scala as far as it has come. for
sure it has blazed an important trail, and i hope it continues to do
so. in order to do so, i'd suggest (easy to do as an outsider) that
somebody should work on coming up with a plan for paying down the debt
and keeping it low, rather than just sort of dealing with how it is
already.

& now i'm shutting up. really!
sincerely.

p.s. and, seriously, thanks to all.

[Meredith Gregory]

All,

Many excellent points taken. i spse i should take it to heart and look into what can be fixed in Scala bug db. Given the kindergarden level of my understanding of Scala, and the kindergarden level of the code i write, i've been more than a little reluctant to contribute in this manner. Others are vastly more qualified than i to handle these problems. But, i see that i should put in some sweat if i'm going to use the platform.

Best wishes,

--greg

On Fri, Jun 26, 2009 at 3:49 PM, Raoul Duke <raould@...> wrote:

> I have a handle on a lot of it.  I think if I had one more person of
> comaprable ability working full time under my guidance, we would cover a
> lot of ground in a hurry.  I'm sure money can be thrown at this problem,
> but I'm not interested in handling logistics or organizing or etc, I am
> only interested in writing software.

many thanks to all who have brought Scala as far as it has come. for
sure it has blazed an important trail, and i hope it continues to do
so. in order to do so, i'd suggest (easy to do as an outsider) that
somebody should work on coming up with a plan for paying down the debt
and keeping it low, rather than just sort of dealing with how it is
already.

& now i'm shutting up. really!
sincerely.

p.s. and, seriously, thanks to all.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Esko Luontola-2]

Paul Phillips wrote on 27.6.2009 1:31:
> It's very difficult to
> be sure a bug fix hasn't broken something else without rebuilding and
> running the whole test suite.  Very slight changes in a trait can force
> rebuilding many files because of the extensive interdependencies, and
> the ant-based build system has no intelligence at all so you're on your
> own if you want to do anything less than a total clean.

Does the Scala compiler support compiling multiple source files in
parallel? That should speed up compiling as the number of cores per CPU
increases. Would other build systems be more intelligent than Ant and
compile only the affected files?

Is there some high-level documentation about the compiler's internals,
so that a new developer could quickly get an overview of the
architecture and begin to dig in deeper?

--
Esko Luontola
www.orfjackal.net

[Paul Phillips-3]

On Mon, Jun 29, 2009 at 01:23:57AM +0300, Esko Luontola wrote:
> Does the Scala compiler support compiling multiple source files in
> parallel?

Not yet.

> That should speed up compiling as the number of cores per CPU
> increases. Would other build systems be more intelligent than Ant and
> compile only the affected files?

It's hard to be less intelligent than ant, but it's non-trivial to
determine what needs recompilation.  There is a lot of ongoing work on
this front, and I don't know where it stands at this second.

> Is there some high-level documentation about the compiler's internals,
> so that a new developer could quickly get an overview of the
> architecture and begin to dig in deeper?

There is some, but all of it must be consumed with salt because it's
always dated to a greater or lesser degree.  Here is a key document,
which I can improve if I find some time:

  https://lampsvn.epfl.ch/trac/scala/wiki/OverviewOfCompilerPhases

--
Paul Phillips      | Beware of bugs in the above code; I have only
Future Perfect     | proved it correct, not tried it.
Empiricist         |     -- Knuth
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------