Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:11
    lolgab ready_for_review #1199
  • 13:37
    lolgab synchronize #1199
  • 13:36
    lolgab synchronize #1199
  • 13:35
    lolgab synchronize #1199
  • Apr 20 19:34

    github-actions[bot] on gh-pages

    Updated github pages from commi… (compare)

  • Apr 20 19:24

    lefou on master

    Update sourcecode to 0.2.6 (#12… (compare)

  • Apr 20 19:24
    lefou closed #1287
  • Apr 20 07:23

    github-actions[bot] on gh-pages

    Updated github pages from commi… (compare)

  • Apr 20 07:08
    lefou closed #1092
  • Apr 20 07:06

    github-actions[bot] on gh-pages

    Updated github pages from commi… (compare)

  • Apr 20 07:06

    lefou on master

    Fix #1283, #1021: Windows BSP: … (compare)

  • Apr 20 07:06
    lefou closed #1285
  • Apr 20 07:05
    lefou edited #1285
  • Apr 20 07:05
    lefou edited #1285
  • Apr 20 06:51

    lefou on master

    scalafix: Replaced procedure sy… scalafix: Removed val in for co… Some more TraversableOnce to It… and 8 more (compare)

  • Apr 20 06:51
    lefou closed #1281
  • Apr 20 06:49
    lefou ready_for_review #1281
  • Apr 20 06:48

    github-actions[bot] on gh-pages

    Updated github pages from commi… (compare)

  • Apr 20 06:46

    lefou on master

    Update scalajs-linker, ... to 1… (compare)

  • Apr 20 06:46
    lefou closed #1246
Li Haoyi
@lihaoyi
you can import more stuff using import $ivy
Brandon Stilson
@bbstilson
excellent. thanks, Li.
Tobias Roeser
@lefou
Hi all, we are currently stuck at Scala 2.13.3, as for any bump to 2.13.4 or 2.13.5 our CI fails with a ConcurrentModificationException thrown by zinc. I for some reasons didn't even figured out how to reproduce it locally and also wasn't able to communicate our/my problem in the sbt channel properly. Any help would be really appreciated.
3 replies
Lorenzo Gabriele
@lolgab

Is there anyone maintaining version specific source directories of this form:

/src-2.13+/
/src-2.12-/

or something similar?
I found a usage of this in many many Sbt projects.

In case you do, how do you manage your build.sc?

(it's not super robust, as it basically works by elimination "is this not scala 2.12 and not scala 2.11, then include "2.13+" and so on)
pool
@hamstakilla
Hello, can i run a sequence of commands from cli? Or possibly make a command containing a sequence of commands?
Lorenzo Gabriele
@lolgab
@hamstakilla You can create a command where you call the commands one after the other. mill command1 command2 command3 should work too
Romain DEP.
@rom1dep

hello there :)

Was reading https://medium.com/virtuslab/revisiting-scala-native-performance-67029089f241 and one paragraph caught my attention:

When I’ve finally managed to create a standalone binary program, another problem emerged, this time at runtime. Scala 2.13 and 2.12.12+ use some JVM constructs that are not fully supported by Native Image. This may lead to exceptions at runtime. Luckily in my case it happened at the very beginning of the main method initialization. It can be quite easily omitted if you’re using the sbt-native-image plugin — it includes a fix used to rewrite some of the unsupported usages at compile time. Unfortunately, it was not as easy when I tried to use Native Image on a project that used mill as a build tool. In that case, it was easier and faster to migrate it to sbt.

Is that a known issue?

Lorenzo Gabriele
@lolgab
@rom1dep Native image is not supported out of the box. Since something like 2.13.3 native-image doesn't work out of the box but you need to replace some files that use JVM internals. There is a library made by the scalameta author that once you add to the ivyDeps it should fix the problem. At work we use Sbt without the sbt-native-image and we made it work only by adding the library called "svm-subs"
Romain DEP.
@rom1dep
@lolgab looks like dark magic to me :) means that with just this lib added to the ivyDeps, running native-image on the assembly produced by mill just works?
Romain DEP.
@rom1dep

Error: Main entry point class 'out.jar' not found.

looks like native-image is easily confused by whatever mill does anyway

Lorenzo Gabriele
@lolgab
I tried passing the classpath, never tried with an assembly. Let me find an example to give you
Romain DEP.
@rom1dep
don't worry, I'll try to have it work with SBT first, because I might encounter some other issues later down the road due to some native dependencies
There you go
Romain DEP.
@rom1dep
oh, nice!
Brandon Elam Barker
@bbarker
@davesmith00000 if you (or anyone else) has a mill config for Scala3 (especially with Scala.js), I'd love to take a look. Been away from Scala and Mill for a while
Dave Smith
@davesmith00000

@bbarker I wish I could help but unfortunately it doesn't work for me. I have this very simple build that works perfectly in 2.13.5 (feel free to clone the repo and try it):
https://github.com/PurpleKingdomGames/indigo-examples/blob/master/demos/snake/build.sc

mill snake.test
mill snake.runGame

It's using Mill 0.9.6 and Scala.js 1.5.1.
If I switch to 3.0.0-RC2 - good news it compiles! (that actually is progress I'm not having a go) ..but the tests don't run and fastOpt for scala.js returns an empty js file.
It's entirely possible that I'm just missing some Scala 3 specific config but I haven't come across any documentation anywhere. Any pointers are very welcome if anyone has any! :-)

I thought previously that the game itself was building but that appears not to be the case - probably just a bad build last time.
Brandon Elam Barker
@bbarker
@davesmith00000 thanks - i've not tried yet but I did see this issue tracking it, which appears to have some sample code: com-lihaoyi/mill#1103
Dave Smith
@davesmith00000
Ah thanks! Unfortunately, contrary to @lolgab's comment, the magic doesn't seem to be happening for me. Maybe you'll have more luck @bbarker? 🙂
Do let me know if you get it working so I can compare build files!
Lorenzo Gabriele
@lolgab
@bbarker The sample code was a workaround before Mill officially supported Scala 3 on Scala.js . Now those options are included in ScalaJSModule since com-lihaoyi/mill#1187
@davesmith00000 I tried to compile your project on Scala 3 some time ago but it wasn't compiling because of compatibility with Scala 3. I have to try again now.
Lorenzo Gabriele
@lolgab
Dave Smith
@davesmith00000

Right @lolgab - thanks for sharing - here is how I fixed my build - testing and fastOpt now work!

// I commented out places where I was setting scalacOptions....
// def scalacOptions = ScalacOptions.compile
// def scalacOptions = ScalacOptions.test

Bug?

@bbarker Looks like it should indeed "just work". :) (...aside from the above.)
Dave Smith
@davesmith00000
Oh in case you wondered, also I tried setting scalacOptions to an empty Seq and it still broke - I thought maybe I just had a bad flag in there somewhere.
Brandon Elam Barker
@bbarker
oh, awesome
Lorenzo Gabriele
@lolgab
@davesmith00000 Maybe I now why.. Because you didn't add super.scalacOptions() ++ and removed the -scalajs option for the Scala3 compiler to compile for Scalajs.. We should change it to avoid this footgun if possible.
Dave Smith
@davesmith00000
I wondered if it was something like that! I couldn't work out the alternative at the time, but it's obvious now you've said it. I'll try it later - thanks @lolgab.
I think use of super is a bit surprising in Scala-land. Maybe depending on which end of the OO/FP spectrum you're used to?
Tobias Roeser
@lefou
Using super is pretty usual in mill land ;-) But in cases like this, where to option is not optional, it's better to change to module as @lolgab suggested.
More generally speaking: Use of super makes only sense if you deal with inheritance. It IS typical for scala, but not needed if you deal with more functional code which does not use any kind of inheritance.
Dave Smith
@davesmith00000
I agree with all of that. I do think super is unusual though and a bit of a stumbling block on the Mill learning curve. On the other hand, Mill is generally so easy to learn that if that's the only problem... maybe it's just something to shout about a bit louder in the docs so people see it coming?
Anyway! Thanks again, I've tested @lolgab's suggestion and that has done the trick. 👍
Lorenzo Gabriele
@lolgab
Cool! @davesmith00000 I'm happy it fixed your problem 🥳
Brandon Elam Barker
@bbarker
i'm trying out yesterday's suggestions in a test project now. I ran into a stumbling block with scalajs-dom, as it hasn't had a scala 3 release, but due to backwards compatibility, it should be possible to use. Apparently the SBT syntax for this would be ("org.scala-js" %%% "scalajs-dom" % "1.1.0").cross(CrossVersion.for3Use2_13) - is there a way to achieve the same results in mill?
Lorenzo Gabriele
@lolgab
@bbarker Sure thing :) ivy"org.scala-js::scalajs-dom::1.1.0".withDottyCompat(scalaVersion())
Brandon Elam Barker
@bbarker
@lolgab , excellent, thanks! I knew that Scala 3 was somewhat backward compatible with Scala 2 sources, but didn't expect the whole project to compile without changes (other than these dependencies). But it did!
Lorenzo Gabriele
@lolgab
@bbarker Yes! It left me astonished too when I tried on a project of mine!
Rich
@Rich2
So can I currently translate either of these Sbt lines into a Mill dependency?
libraryDependencies += "org.openjfx" % "javafx-controls" % "15.0.1",
libraryDependencies += "org.openjfx" % "javafx-controls" % "15.0.1" classifier "linux",
heksesang
@heksenlied:matrix.org
[m]
ivy"org.openjfx:javafx-controls:15.0.1" and then add it to ivyDeps
def ivyDeps = super.ivyDeps ++ Agg(
  ivy"org.openjfx:javafx-controls:15.0.1"
)
Not sure about the classifier, but should probably be possible to specify that as well.
Piotr Buszka
@pbuszka

I have a scala js app which uses some js libs that are bundled with webpack (scalajs output + js libs) and then the app runs in a browser - this works fine. I wanted to write some tests and run them from mill with JsDom support but I stumbled on the problem:
if my scalajs test module is ModuleKind.CommonJSModule and test module jsEnvConfig is JsDom then it when tests are run it complains about ReferenceError: require is not defined which makes sense given this scala-js/scala-js-env-jsdom-nodejs#44 in scala-js-env-jsdom-nodejs (TLDR require is not part of browser environment). If I set jsEnvConfig to NodeJs in test module then require works but obviously there is no browser environment so it fails to run tests which access for instance the browser window.
The js library is imported within a static scala object like this

object DataTable {
  @js.native
  @JSImport("@material/data-table", "MDCDataTable")
  class MDCDataTable(ref: dom.html.Element) extends js.Object {
    def layout(): Unit = js.native
  }
....

As a workaround for jsdom and require probelm this fork is proposed but it would require forking mill so it uses this library istead of a standard. Has anyone managed to get to work this type of testing use case or some ideas/pointers how to tackle the problem ?

Rich
@Rich2
@heksenlied:matrix.org No that doesn't work under Mill, because since Java 11, Java Fx is a platform dependent dependency.
def ivyDeps = Agg(ivy"org.openjfx:javafx-controls:15.0.1")
1 targets failed
Graphics.resolvedIvyDeps Failed to load source dependencies
  not found: https://repo1.maven.org/maven2/org/openjfx/javafx-controls/15.0.1/javafx-controls-15.0.1-${javafx.platform}.jar
  not found: https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/15.0.1/javafx-graphics-15.0.1-${javafx.platform}.jar
  not found: https://repo1.maven.org/maven2/org/openjfx/javafx-base/15.0.1/javafx-base-15.0.1-${javafx.platform}.jar
Andrew Richards
@ajrnz

@Rich2 Try the below modified for your versions etc. It uses the coursier high level API to get the artifacts and then adds them as unmanaged classpath entries (credit: someone else). It's not ideal but works:

  def unmanagedClasspath = T{
    import coursier._
    import coursier.parse.DependencyParser
    val javaFXModuleNames = List("base", "controls", "fxml", "graphics", "media", "swing", "web")
    val javaFXModules = (javaFXModuleNames
      .map(m => Dependency(Module(org"org.openjfx", ModuleName(s"javafx-$m")), "12"))) ++
        Seq(dep"org.controlsfx:controlsfx:11.1.0")

    val files = Fetch().addDependencies(javaFXModules: _*).run()
    val pathRefs = files.map(f => PathRef(os.Path(f)))
    Agg(pathRefs : _*)
  }
}

  def forkArgs = Seq(
    "--module-path", sys.env("JAVAFX_HOME") + ":" + "/Users/ajr/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/controlsfx/controlsfx/11.1.0",
    "--add-modules", "javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,org.controlsfx.controls",
    "--add-exports=javafx.controls/com.sun.javafx.scene.control.behavior=org.controlsfx.controls",
    "--add-exports=javafx.controls/com.sun.javafx.scene.control.inputmap=org.controlsfx.controls", 
    "--add-exports=javafx.graphics/com.sun.javafx.scene.traversal=org.controlsfx.controls"
  )

the add-exports are useful if you need to use RangeSlider for example.

Piotr Buszka
@pbuszka

For anyone interested the workaround I found regarding running scalajs JsDom tests with support for require at the same time (a few lines above my own question) is as follows:
The execution environemnt for test should be NodeJs but jsDom is built directly within the test code itself and not by mill test runner. It is not a clean solution but works. The relevant code snippets are:

object JSDOM extends {
  @js.native
  @JSImport("jsdom", "JSDOM")
  class JSDOM(s: String, options: UndefOr[js.Object]) extends js.Object {
    val window: org.scalajs.dom.Window = js.native
    val document: js.Object = js.native
  }

  lazy val jsDom = new JSDOM("<!DOCTYPE html><p></p>", js.undefined)

  def init(): Unit = js.Dynamic.global.global.window = jsDom.window
}

and in the test module in build.sc

  object test extends Tests {
    override def jsEnvConfig: T[JsEnvConfig] = T {
      JsEnvConfig.NodeJs(
       env = Map("NODE_PATH" -> "path/to/your/node_modules")
    ) }
    override def moduleKind = T{ ModuleKind.CommonJSModule }
  }

node_modules dir referenced has to contain jsdom npm package installed and all npm browser packages referenced
the actual test code has to invoke JSDOM.init()