Scala CLI

412 Members
Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!) scala-cli.virtuslab.org2 Servers

Load older messages

24 Jan 2023
$ hyperfine "scala-cli run --native test.scala"
Benchmark 1: scala-cli run --native test.scala
  Time (mean ± σ):     347.6 ms ±   9.3 ms    [User: 29.6 ms, System: 20.7 ms]
  Range (min … max):   332.3 ms … 363.4 ms    10 runs

$ hyperfine "scala-cli compile --native test.scala"
Benchmark 1: scala-cli compile --native test.scala
  Time (mean ± σ):     296.8 ms ±   3.7 ms    [User: 131.5 ms, System: 94.8 ms]
  Range (min … max):   290.7 ms … 303.9 ms    10 runs

same story
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 ged would you expect this? 10:02:11
@_discord_231350810565410817:t2bot.ioragnar#4252 Which is why my initial comment said that its useless to try and have scala-cli compile in the shebang line, because it still does all of the scala-cli initialization and checking and stuff, which is the expensive part. 10:02:22
@_discord_231350810565410817:t2bot.ioragnar#4252 Also, while we are at it running --server=false is slower than starting bloop. 10:04:07
@_discord_231350810565410817:t2bot.ioragnar#4252 * Also, while we are at it running --server=false is can be slower than starting bloop. 10:04:31
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 it seems to do _a lot_for each run - if you do -v -v on compile it

1. Checks the dependency jar caches
2. re-invokes Bloop compile
3. moves semanticdb files around?
@_discord_231350810565410817:t2bot.ioragnar#4252 Which is to say, scala-cli is wonderful for what it does, but it is not meant for use cases where you have a rarely changing script that you want to execute often :-) 10:06:31
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 IMO I think all of those things can be addressed with more caching, they don't seem to be strictly necessary 10:06:55
Download image.png
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 It does a lot 10:08:33
@_discord_231350810565410817:t2bot.ioragnar#4252 Question is, if optimizing “rarely changing files” is an important usecase of scala-cli 🤷 10:08:45
@_discord_231350810565410817:t2bot.ioragnar#4252 package --native has become quite the viable option … except for some JDK methods I am missing 😄 10:09:30
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 FWIW I also

1. Develop with scli run -w . using JVM
2. Package with -native before running it hundreds of times
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 And when I'm missing a JDK method.. well, C libraries make an appearance and then nothing works 10:11:48
@_discord_231350810565410817:t2bot.ioragnar#4252 My opinion is, that scala-cli should keep focusing on making the hard parts “easy enough”. It is orders of magnitude more useful to me that I can just do scala-cli setup-ide . and do script development in my IDE. 10:12:54
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 IMO half a second to run hello world after it's been compiled is a noble thing to tackle 10:13:08
@_discord_231350810565410817:t2bot.ioragnar#4252 For what its worth, I just wrote a different shebang runner when I needed the performance (or more specifically I did that about 1 month before I learned about scala-cli 😂 around the time when cs was enough of a thing that doing so was easy).
You basically gain most of what you want for that use case by just:
def scala3Runner(pathname: String, args: String*): Unit =
  val path = Paths.get(pathname).toAbsolutePath
  val hash = process"sha1sum $path".run().takeWhile(_ != ' ')

  val target = cachedir.resolve(hash)
  if Files.isDirectory(target) then new ProcessBuilder(s"$target/run" +: args).toIndexedSeq: _*).run()
  else compile (which should actually be super easy now that we have scala-cli)
@_discord_231350810565410817:t2bot.ioragnar#4252 With which I just want to say, that shebang execution is pretty different from the rest of scala-cli usage, so it may be worth to just do the easy thing there 🤔 10:25:46
@_discord_777499506895093780:t2bot.iombesida thanks, it is the same bug 19:13:26
@_discord_387435475142705152:t2bot.iozebos#7602 changed their profile picture.19:57:24
25 Jan 2023
@_discord_448877036098813952:t2bot.iololgab#6138 Not sure about this. I'm trying comparing bloop cli vs mill cli and they are almost the same, mill prints some instant earlier (assuming you can compare the Instant.now from two different processes reliably) 16:33:25
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 But Mill is also daemonised, no? 16:38:20
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 or is this with -i? 16:38:30
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 My point was that connecting to an already running JVM with Zinc in it (Bloop or Mill server) is faster than shelling out to a whole new java command with Zinc 16:39:13
@_discord_448877036098813952:t2bot.iololgab#6138 Yeah, Then I didn't read the comment correctly, I thought that bloop had extra things that other build tools don't have. Yes it's exactly that, having an already warmed up zinc makes the difference 16:56:25
@_discord_231350810565410817:t2bot.ioragnar#4252 I think the discussion was bloop vs scalac. 18:03:47
@_discord_231350810565410817:t2bot.ioragnar#4252 Or more specifically, scala-cli using bloop vs scala-cli using whatever it does with --server=false which very well may still be bloop, just without the daemon. 18:04:33
@_discord_448877036098813952:t2bot.iololgab#6138 Yeah, I understood now, what I was understanding was that bloop had something that made it faster than vanilla zinc, which is not the case in my experience. 18:07:01
26 Jan 2023
@_discord_845013677816021083:t2bot.ioarmanbilge#6192 I remember someone reporting a similar issue recently in #scala-native 08:26:33
@_discord_734849617820254331:t2bot.iovelvetbaldmime#6377 https://github.com/scala-native/scala-native/issues/3098 08:27:12

There are no newer messages yet.

Back to Room List