Announcing Scala.js 0.6.0-M3

[Sébastien Doeraene]

Hi all,

We are excited to announce the third milestone of Scala.js 0.6.0, aka 0.6.0-M3! This release is mostly about the (hopefully) last binary incompatible changes for the 0.6.x series. It also substantially reworks the `scala.scalajs.js` package to simplify it.

Read all the details in announcement on the Website:

http://www.scala-js.org/news/2014/12/22/announcing-scalajs-0.6.0-M3/

Cheers,
Sébastien and Tobias

[Sérgio Silva]

Hi Sébastien,

This will sound like a major newbie question - which it will be due to my inexperience with SBT. Where are these versions published to? How can I use them in my current sbt project?

Cheers,

[Sébastien Doeraene]

Hi,

They are published on Maven, so you don't have any special resolver to specify. However, groupIds and artifact names have changed since 0.5.x. See this commit for the appropriate changes to apply to your project:
https://github.com/sjrd/scala-js-example-app/commit/11c56d9700eff3922fb98472ebcf5e9b19f18e1e

Cheers,
Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/459766ba-c4c9-4e5e-ad59-d8c3ef862692%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sérgio Silva]

Hi Sebastien,

Thanks for your help. Will scala-js-jquery also be updated?

Cheers,

[Sébastien Doeraene]

scalajs-jquery is already published. See https://github.com/scala-js/scalajs-tutorial/commit/847e9ab204a88166b7c16aa086821354476e8a16 for the coordinates.

Cheers,
Sébastien

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/489a7c9e-d69f-4695-a858-7947293dcdba%40googlegroups.com.

[Tim Nieradzik]

Thanks for the release. Finally I could get rid of some workarounds needed for < 0.6. It's also nice to see that ``fastOptJS`` slightly reduces the size as compared to previous versions.

It took me some time to figure out which imports to use for a ``Build.scala`` setup:

    import org.scalajs.sbtplugin._

    import org.scalajs.sbtplugin.ScalaJSPlugin.autoImport._

If this is the way to go, it should be documented somewhere.

I noticed that the new sbt plugin fails to find the main class (``sbt run``) in cross-project configurations. It seems that this is not specific to my configuration as I could reproduce it with Vincent's sample project: https://github.com/vmunier/scalajs-cross-project-intellij/

The readme file of scala-js-dom doesn't mention its latest version. If you don't object to mention pre-releases, I'd be happy to submit a merge request.

As some package names were refactored in this release, I was also wondering why the distinction between ``org.scalajs`` and ``scala.scalajs`` remains. Wouldn't it make sense to merge these two?

[Vincent Munier]

Hi,

As discussed on GitHub on how to run scalajs-cross-project-intellij, use `sbt exampleJS/run` and `sbt exampleJVM/run`.

Cheers,

Vincent

[Jakub Liska]

Hi Sebastien,

I'm in the process of upgrading my stuff to 0.6.0-M3, my conf is basically : 

addSbtPlugin("org.scala-js" % "sbt-scalajs" % "0.6.0-M3")

addSbtPlugin("com.lihaoyi" % "utest-js-plugin" % "0.2.5-M3")

import sbt.Keys._
import sbt._
import utest.jsrunner.Plugin.internal._

import org.scalajs.sbtplugin.ScalaJSPlugin
import org.scalajs.sbtplugin.ScalaJSPlugin.autoImport._
import org.scalajs.jsenv.phantomjs.PhantomJSEnv

object Build extends sbt.Build {

  lazy val `scalajs-rx-idb` =
    project.in(file("."))
      .enablePlugins(ScalaJSPlugin)
      .settings(utestJsSettings:_*)
      .settings(
        organization := "com.viagraphs",
        name := "scalajs-rx-idb",
        version := "0.0.6-SNAPSHOT",
        scalaVersion := "2.11.4",
        scalacOptions ++= Seq(
          "-unchecked", "-deprecation", "-feature", "-Xfatal-warnings",
          "-Xlint", "-Xfuture",
          "-Yinline-warnings", "-Ywarn-adapted-args", "-Ywarn-inaccessible",
          "-Ywarn-nullary-override", "-Ywarn-nullary-unit", "-Yno-adapted-args"
        ),
        libraryDependencies ++= Seq(
          "org.scala-js" %%% "scalajs-dom" % "0.7.1-SNAPSHOT",
          "org.monifu" %%% "monifu" % "0.1-SNAPSHOT",
          "com.lihaoyi" %%% "upickle" % "0.2.6-M3",
          "com.lihaoyi" %%% "utest" % "0.2.5-M3" % "test"
        ),
        autoAPIMappings := true,
        requiresDOM := true,
        scalaJSStage := FastOptStage,
        persistLauncher in Test := false,
        postLinkJSEnv in Test := new PhantomJSEnv(autoExit = true)
      )
}

But there is a missing eclipse jetty dependency in runtime :

> test

[info] Fast optimizing /home/lisak/src/viagraphs/scalajs-rx-idb/target/scala-2.11/scalajs-rx-idb-test-fastopt.js

[trace] Stack trace suppressed: run last test:loadedTestFrameworks for the full output.

[error] (test:loadedTestFrameworks) java.lang.NoClassDefFoundError: org/eclipse/jetty/util/log/Logger

[error] Total time: 12 s, completed Jan 2, 2015 3:13:20 PM

Would you please help me with this ?

[Sébastien Doeraene]

Hi,

Remove the sbt plugin of uTest, and the postLinkJSEnv setting. The former is not needed anymore, and the latter is implied by `requiresDOM := true`.

The issue comes from postLinkJSEnv, which must be set differently now if you really need it.

I won't expand right now because I'm on mobile.

Cheers,
Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/c3b8405a-3178-464f-b2db-96290a834bf7%40googlegroups.com.

[Jakub Liska]

Hi,

I'd need "autoExit = false", from the source code it looks I should do :

import org.scalajs.sbtplugin.ScalaJSPlugin.AutoImport.PhantomJSEnv

testFrameworks += new TestFramework("utest.runner.Framework")

postLinkJSEnv := PhantomJSEnv(autoExit = false).value

But it only works for as expected for "autoExit =true", if I set autoExit to false it gets stuck indefinitely, no tests are actually executed, the utest runner doesn't even seem to be started.

[Alexandru Nedelcu]

So when do you think that 0.6 final will be out? :-)

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAJwkOg6xFdc-yyyFaZh3jKRsnC6RkPSZeLfd50XbaFcRoocnqw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alexandru Nedelcu
www.bionicspirit.com

PGP Public Key:
https://bionicspirit.com/key.aexpk

[Sébastien Doeraene]

Hi,

The RC should be available in a week or two. Then a couple more weeks until the final, I suppose.

Cheers,
Sébastien

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAN9KCotB6B8O6mAT3XkOLqAkBx30eP3%2Bc6Q_9AQ8oVBemOOraQ%40mail.gmail.com.

[Jakub Liska]

Is there a way to enable more logging or traces in 0.6.0-M3? I'm migrating the tests to be compliant with scalajs-test-interface, but new errors are coming up and the only information I get is that this error has been logged to console on line 42037. Which is basically no information what so ever that would lead me at least to the library from where the exception is thrown. I covered all my Promises, but it turned out to be thrown from a third party library Promise.

Uncaught failure in async execution: java.lang.IllegalStateException: Promise already completed.

  /tmp/phantomjs-launcher3561967228214270298.js:9 in onError

  /tmp/phantomjs-launcher3561967228214270298.js:11 in onError  file:///.../client-test-fastopt.js:42037 (in function "doWriteLine__p4__T__V")

  /tmp/phantomjs-launcher3561967228214270298.js:13

[Sébastien Doeraene]

What kind of logging are you hoping for?

Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/8345ba34-c78f-4f60-a1ce-2f3d642993f6%40googlegroups.com.

[Jakub Liska]

I haven't paid much attention to these stack traces so far because often when I looked at it was missing any relevant information (as in the case above), sometimes there was a useful stack trace in the sense that it pointed me to where the "IllegalStateException: Promise already completed." has been thrown, or at least approximately.

Now in java for instance the behavior of stack traces is 100% clear. You basically always know why that stack trace looks as it does.

But in scalajs it is a blackbox that sometimes provides us with anything or nothing. Because JS has no stacktraces as java and because of the asynchronicity I guess. My apps might be so stacktraceless because I'm using highly asynchronous Rx for instance and a lot of Futures.

Yet you are somehow collecting the stacktrace. Is there any general set of rules? Like, you get nothing if an exception is thrown in a callback, you only get a stacktrace if the execution starts and ends within the initial queue task, etc...  It was a little bit dumb question :-)

[Sébastien Doeraene]

Normally you get the stack trace from the event loop up to the exception. For a callback invoked by the event loop, that means you get nothing. Async stuff on the JVM behaves in the same way.

Cheers,
Sébastien

[Matthew Pocock]

This is a real problem for debugging. For reactive apps it effectively means you have no idea what went wrong.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAJwkOg7OuXXFJgt24wC%2B6X9SGyGNov7KfR1Kv%2BPqpY8wOcBJ4w%40mail.gmail.com.

[Jakub Liska]

More specifically it's problem for instance when migrating and upgrading libraries and it just appears out of the blue. Otherwise you usually know from where the wind blows... However I'm glad to know the protocol, thank you Sebastien.

In regards to M3, I just migrated 8 applications and libraries to it, including making test suites compliant with scalajs-test-interface. It went quite well, I expected it would take much more time. It took me ~ day.

I just have a bunch of TODOs resulting from the fact that I was using uTest programmatically which allowed me to do : 

cleanup, profiling, stats, declarative test runs "tests.runAsync(testPath = WhatTestsShouldBeExecuted)" and few other things - SBT should allow for most of these things, but it's extremely time demanding

Without the programmatical uTest usage one seems to always depend on PRs to uTest, I recently wrote about it here. At least I don't see how to implement those things I listed above without changing uTest.

Anyway, great job, transition to M3 and to scalajs-test-interface was really smooth. Thank you

[Justin du coeur]

Yeah, I have to agree that this is a problem: my client has wound up fairly heavily async, using a lot of Futures and Scala.Rx, and debugging is often nightmarish: exceptions in Futures show very little useful information, and exceptions in reactives are often dead-silent.

OTOH, it's easy to see why doing much about this is hard, especially without a causing a major performance hit.  Tracing asynchronous operations usually requires injecting a lot of extra information -- in some fashion or another, adding something like a stack trace that gets recorded with the async call.  We can't afford to just do that with every Future we create: the overhead would be huge.

I don't know if it's feasible, but a debugging switch that turns on that sort of heavy tracing in Futures would be helpful.  Conceptually, it would record the stack trace at the point of the Future call, attach that to the Future, and if an Exception was thrown *inside* the Future, it would include that calling context in the message.  (This would have to be done in a way that nests, so that mapped Futures did the right thing.)  I suspect it would be *ferociously* expensive at runtime (getting a stack trace isn't cheap), but as an sbt switch that you turn on only when you need it, it might be quite worthwhile.

As for exceptions inside reactives, I suspect that we can do a bunch with some modest enhancements to Scala.Rx itself.  I've been waiting until the new version of that settles down (and I've upgraded to it -- I'm always a bit behind the times), but it may be worth a separate discussion on how to make Scala.Rx debugging easier.

In general, though, folks should keep in mind that these problems aren't terribly peculiar to ScalaJS -- debugging asynchronous code is *always* hard, and I have yet to come across a system that's really good at it.  (In my Akka-based backend, I'm planning on some significant rewrites just so I can trace the flow of control myself, by threading a context object that is getting passed around between the Actors...)

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAHQS_eycPi-WuOo7aoqHaVEZ0GcBY4MAcgmPNWzD7YdTgmwyqA%40mail.gmail.com.

[Haoyi Li]

> Without the programmatical uTest usage one seems to always depend on PRs to uTest, I recently wrote about it here. At least I don't see how to implement those things I listed above without changing uTest.

Sorry I haven't merged them yet! I promise I'll get to it...

> Yeah, I have to agree that this is a problem: my client has wound up fairly heavily async, using a lot of Futures and Scala.Rx, and debugging is often nightmarish: exceptions in Futures show very little useful information, and exceptions in reactives are often dead-silent.

Yeah debugging futures in general is harsh. I heard the typesafe/EPFL guys are working on some ideas to make it better. I know the twitter/finagle guys have solutions to these problems since they spend every waking hour living in massive chains of futures.

As for Rxs, I've ideas to make those better too. The current version of Scala.Rx lets you print out the dependency graph of a failed Rx or attach additional observers to make things easier to reason about. The "new" version that i'll publish after Scala.js 0.6.0 should make these things more approachable.

>  I suspect it would be *ferociously* expensive at runtime (getting a stack trace isn't cheap), but as an sbt switch that you turn on only when you need it, it might be quite worthwhile.

What if you make it a thunk () => Array[StackTraceElement]? That way you wouldn't pay for it unless you really asked for it. Though you'd still be keeping a bunch of stuff in memory and possible preventing GC.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAO26FW3__PW5NGWcUD8mTOfMFetMcPmMAG%3DJANWC%3DaNXOFFV9w%40mail.gmail.com.

[Matthew Pocock]

of the rx/future code is pure, one solution is to run it full speed until there is s failure and then run again collecting full traces.

Matthew

[Justin du coeur]

On Sat, Jan 3, 2015 at 11:43 AM, Haoyi Li <haoy...@gmail.com> wrote:

What if you make it a thunk () => Array[StackTraceElement]? That way you wouldn't pay for it unless you really asked for it. Though you'd still be keeping a bunch of stuff in memory and possible preventing GC.

Intriguing.  I suspect that's still too expensive to do routinely, but it seems like putting *that* behind a switch could potentially work fairly well, so long as you are running with enough memory to hold onto all those closures... 

[Sébastien Doeraene]

Hi,

The thunk-based idea cannot work. You'll end up with the initial problem all over again: the generated stack trace will be relative to where you invoke the thunk from. Not relative to where it was created.

Improving this kind of debugging of asynchronous code is not something we can do in Scala.js as such. It is a job for either the debugger (see http://scalacamp.pl/data/async-debugger-slides/index.html) or possibly for a compiler plugin (that would apply both to Scala/JVM and Scala.js).

Cheers,
Sébastien