by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 26 23:14

    lihaoyi on gh-pages

    first commit (compare)

  • May 26 22:17

    lefou on master

    Properly generate code for syst… (compare)

  • May 26 13:45

    lihaoyi on gh-pages

    first commit (compare)

  • May 26 12:48

    lefou on master

    Format thread id for thread cou… (compare)

  • May 26 07:33
    lefou labeled #897
  • May 26 07:32
    lefou labeled #902
  • May 26 05:43
    lefou edited #906
  • May 25 21:44

    lihaoyi on gh-pages

    first commit (compare)

  • May 25 20:43
    lefou opened #906
  • May 25 20:40

    lefou on master

    Updated changelog and mill vers… (compare)

  • May 25 10:02
    jodersky synchronize #904
  • May 25 05:38

    lihaoyi on gh-pages

    first commit (compare)

  • May 25 02:38

    lihaoyi on 0.7.3

    (compare)

  • May 25 02:16

    lihaoyi on gh-pages

    first commit (compare)

  • May 25 01:20

    lihaoyi on master

    update example project versions (compare)

  • May 24 23:40
    jodersky opened #904
  • May 24 17:19
    joan38 synchronize #897
  • May 23 18:31
    joan38 synchronize #902
  • May 23 18:30
    joan38 opened #902
  • May 21 07:00
    joan38 edited #897
nsram
@nsram_twitter
Is it feasible to give access to the mill fat assembly file outside github.com domain? Some corps block github.com but have access to maven repos, github.io etc. With sbt, its easily accessible from the sbt org site as a zip. thanks.
tballard
@tballard
Somehow I missed how I put a non-standard directory in the resource path. Can somebody point me the right way?
Andreas Gies
@atooni
@tballard for example
  override def resources = T.sources { super.resources() ++ Seq(
    PathRef(millSourcePath / 'src / 'main / 'binaryResources)
  )}
tballard
@tballard
@atooni Cool, thanks
lilyevsky
@lilyevsky

I have a question about bootstrapping the build with custom module code. I needed to add some extra functionality to the ScalaModule, so I extended it and published in our Nexus, in order to use it in multiple projects. So, let say, I have this MyScalaModule class, and I want to define my build like this:

object MyBuild extends MyScalModule ........

I see that I can override the list of repositories inside the build object (https://www.lihaoyi.com/mill/page/configuring-mill.html) by redefining the zincWorker , but how can I do it before the build object definition? I need to download MyScalModule from Nexus or local maven repository somehow.

Gunnar Lilleaasen
@heksesang
Seems there is an issue with bloop files generated by mill for dotty projects: scalameta/metals#1768
Joan Goyeau
@joan38

@lilyevsky

import coursierapi.{MavenRepository, Repository}
interp.repositories() =
    List(Repository.ivy2Local, MavenRepository.of("https://your/repo"))
@

Mind the last @ is useful to reload the interpreter

Joan Goyeau
@joan38
Ahah I'm trying out the Mill auto import in Indellij via BSP JetBrains/intellij-scala#536
Screen Shot 2020-05-21 at 15.44.25.png
lilyevsky
@lilyevsky
@joan38 Thanks Joan, I made it work.
Michael Genereux
@mgenereu
@joan38 IntelliJ BSP/Mill/Bloop work for me but the build.sc file comes up not knowing anything about mill. Does build.sc come up nice for you?
Joan Goyeau
@joan38
@mgenereu You mean the build.sc is all red in Intellij?
It's now less red with 7.2.0 but we are still missing $file imports and the $ivy are red even tho they are resolved.
That's something we'll have to find a solution somehow
The screenshot I posted above is me trying out the Intellij PR I created to make Intellij automatically load Mill projects with BSP, not sure how it plays with Bloop
jodersky
@jodersky
Is there anything specific I need to watch out for when defining scalaVersion to a locally-published version of scala? I built scala locally (sbt publishLocal) and then set the version in a mill project def scalaVersion = "2.13.2-bin-SNAPSHOT". Zinc is throwing errors now:
mill project.compile java.util.NoSuchElementException: None.get
    scala.None$.get(Option.scala:627)
    scala.None$.get(Option.scala:626)
    mill.scalalib.ZincWorkerModule.$anonfun$worker$5(ZincWorkerModule.scala:72)
    mill.scalalib.worker.ZincWorkerImpl.compileBridgeIfNeeded(ZincWorkerImpl.scala:179)
    mill.scalalib.worker.ZincWorkerImpl.withCompilers(ZincWorkerImpl.scala:327)
    mill.scalalib.worker.ZincWorkerImpl.compileMixed0(ZincWorkerImpl.scala:284)
    mill.scalalib.worker.ZincWorkerImpl.compileMixed(ZincWorkerImpl.scala:254)
    mill.scalalib.ScalaModule.$anonfun$compile$2(ScalaModule.scala:140)
    mill.define.ApplyerGenerated.$anonfun$zipMap$9(ApplicativeGenerated.scala:21)
    mill.define.Task$MappedDest.evaluate(Task.scala:392)
I'll look into it, but wanted to see if anyone has encountered this previously
Joan Goyeau
@joan38
Can someone explain in what circonstances we would want to run mill without -i?
Li Haoyi
@lihaoyi
@joan38 I run without -i most of the time
Joan Goyeau
@joan38
But in what circonstance it's an issue to run with -i?
Li Haoyi
@lihaoyi
-i is always about 1-2 seconds of JVM warmup overhead
it should never not work, but it's definitely slower
also, it doesn't keep the scala compiler hot in the background
which could easily be another 5-10 seconds of slow compilation each command
6-12 seconds of overhead per command is a lot
Joan Goyeau
@joan38
Yes it's a lot
How is the the fact that it doesn't keep the compiler hot related to interactive?
Li Haoyi
@lihaoyi
-i starts the JVM when you run the command, and shuts down the JVM after
without a JVM there's nowhere to keep the compiler hanging around hot
Joan Goyeau
@joan38
I see
Joan Goyeau
@joan38
@lihaoyi How is mill working without starting a JVM?
Li Haoyi
@lihaoyi
mill does start a JVM, it just shuts down after you run a command via mill -i foo
Sakib Hadžiavdić
@sake92
without -i it starts a mill server in background. Then it starts a client for that command. client just sends/recieves data via a named pipe/socket
second time you run it, server is already there, started, you just communicate with it
at least on Linux, there are still some issues on windoze.. 🤣
Joan Goyeau
@joan38
Thanks for the explanation @sake92
I've created lihaoyi/mill#902 to avoid needing -i to install BSP
Kenner Stross
@kennerstross
I have been upgrading from mill 0.6.3 to 0.7.2 in order to take advantage of scala js 1.x. But... something has gotten terribly screwed up in the process. I used (on mac os): brew upgrade mill. It is, indeed, at 0.7.2, but my scala 2.12 project now emits these kinds of errors:
I have no idea where the 2.13 references are coming from. I also, to be honest, have no idea what the error message means, really, or where I should start looking. I have run clean and rebuilt, with the same result. Any ideas?
Joan Goyeau
@joan38
@kennerstross the 2.13 comes from the fact that the 0.7.x series is built on Scala 2.13
Have you tried to rm -rf ~/.mill ?
Just like for SBT I don't upgrade my build tool with brew or system wide but for the project with the mill bootstrap script
Kenner Stross
@kennerstross
Thanks @joan38 - I had sort of overlooked that boostrap script. Good to know about. As for my error messages, it looks like I was just not sufficiently careful about clearing out old stuff - libraries, coursier, out directory, etc.
Li Haoyi
@lihaoyi
Anyone seeing this failure trying to set up VS-Code? I'm getting it trying to import the build of https://github.com/lihaoyi/cask/releases/download/0.6.5/minimalApplication-0.6.5.zip
2020.05.26 10:33:24 INFO  started: Metals version 0.9.0 in workspace '/Users/lihaoyi/test/minimalApplication-0.6.5'
2020.05.26 10:33:25 INFO  time: initialize in 1.09s
2020.05.26 10:33:28 INFO  running '/var/folders/zk/w7xfpj_51t90z7xv5kw2zdm80000gn/T/metals16017933134760580334/millw --mill-version 0.7.3 --predef /var/folders/zk/w7xfpj_51t90z7xv5kw2zdm80000gn/T/metals16017933134760580334/predef.sc mill.contrib.Bloop/install'
2020.05.26 10:33:28 INFO  Cannot resolve external module mill.contrib.Bloop
2020.05.26 10:33:28 INFO  build tool exit: 1
2020.05.26 10:33:28 INFO  time: ran 'mill bloopInstall' in 0.38s
2020.05.26 10:33:28 ERROR Mill command failed: /var/folders/zk/w7xfpj_51t90z7xv5kw2zdm80000gn/T/metals16017933134760580334/millw --mill-version 0.7.3 --predef /var/folders/zk/w7xfpj_51t90z7xv5kw2zdm80000gn/T/metals16017933134760580334/predef.sc mill.contrib.Bloop/install
Li Haoyi
@lihaoyi
seems flaky non-deterministic-y :/
Damian Reeves
@DamianReeves
One observation I’d make about using mill is that it is not clear how source directories for multi-platform builds work. I’ve even looked at examples from various projects from @lihaoyi and they seem to vary and most seem to have custom code involving os.up, offset, and/or source.path.last I’d think this should be manageable via a simple variable/Module trait
Also, even for cross-builds are there any docs (maybe even just tasks) you can run to find what sources are specific to what cross-build versions
Damian Reeves
@DamianReeves
For example, if I need custom code in a build that targets the JVM and scalajs, how do I identify what source folders are for JVM, JS, and specific cross builds of those platforms. Is it jvm-src-2.12 for s scala 2.12 change for the JVM, or is it jvm/src-2.12 or something else. Right now it seems like you need to do it yourself, but the docs don’t address how you do this yourself.
Li Haoyi
@lihaoyi
yeah it’s pretty ad hoc right now
Tobias Roeser
@lefou
@DamianReeves you can run mill show a.b.sources to find out what will be used by default.