Ironically, test/files/run/tailcalls.scala fails on runtimes with proper tail calls ...

[Simon Ochsenreither]

... does someone have a opinion on what's the appropriate way to fix this test?

It fails with “calibration failure”, while it tries to run a supposedly non-tail-call-optimized method (which is of course optimized on platforms which support tail calls).

  def calibrate: Int = {
    val calibrator = new Calibrator();
    var stop = false;
    var n = 1;
    while (!stop) {
      try {
        calibrator.f(n, n);
        if (n >= Int.MaxValue / 2) sys.error("calibration failure");
        n = 2 * n;
      } catch {
        case exception: compat.Platform.StackOverflowError => stop = true
      }
    }
    4 * n
  }

Apart from that, it also hardcodes that certain methods fail with a StackOverflowError in the checkfile, which is not true on all platforms.

Does someone see a good option how to keep this test running properly?
Or should this just be skipped when runtime == "Avian"? As long as we are still testing it on other platforms, the chance of e regression should be low, right?

Thanks and bye,

Simon

[Jason Zaugg]

I think that's a good approach. So long as we don't need to do that in *too* many of the 'run' tests, I'm happy to put that check into the test itself.

-jason

[Paul Phillips]

On Sat, May 11, 2013 at 8:49 AM, Jason Zaugg <jza...@gmail.com> wrote:

I think that's a good approach. So long as we don't need to do that in *too* many of the 'run' tests, I'm happy to put that check into the test itself.

Maybe this is a good time to ask why there's a "jvm" category.

[√iktor Ҡlang]

+1

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[Jason Zaugg]

On Sat, May 11, 2013 at 5:52 PM, Paul Phillips <pa...@improving.org> wrote:

Good point: should that have been squashed into 'run' after we expunged MSIL?

-jason

[Paul Phillips]

On Sat, May 11, 2013 at 8:55 AM, Jason Zaugg <jza...@gmail.com> wrote:

Good point: should that have been squashed into 'run' after we expunged MSIL?

Oh right, that's the now-invisible distinction it was drawing. It should be squashed into run now - even if we wanted to maintain a separate category of jvm-specific tests, the current division between run and jvm is meaningless.

[Simon Ochsenreither]

Good point: should that have been squashed into 'run' after we expunged MSIL?

Not sure, I'll probably be adding a new 'avian' dir shortly.

[Simon Ochsenreither]

Not sure, I'll probably be adding a new 'avian' dir shortly.

In fact, Id' like to do this right now! Can someone give some guidance?

The first test case would actually be this one, just with the right expected test results and running it with deactivated tail call optimization in scalac (is there something like -no-specialization for that?), so that it solely relies on Avian doing its job.

Thanks,

Simon