Tobias Roeser lefou
This is a Scala script to check for Mill build plugin and scala-cli lib updates. The plugin requires scala-cli.
Run directly from the gist with:
scala-cli https://gist.github.com/carlosedp/c3ea2814ac5392051a562e95c1298239/raw/checkdeps.scOr download the script, make it executable and run as:
Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.
An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.
Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty
What follows is my opinion on how we should tame all of this complexity. Specifically, how can we make it as easy as possible to keep everyone's builds and releases in-sync with the latest Dotty as we approach Scala 3. This is a very complex undertaking with a lot of moving parts. I'm attempting to draw on our experience doing this for prior Scala 2 versions, as well as personal scars from previous upgrade efforts across various Scala versions. In other words, this is a bit of a "lessons learned" phrased as "please everyone do this".
Any projects I have any control over will be following these steps to the best of our ability.
Breaking upgrades are always much easier when you can break them apart into the smallest possible steps. Publishing for the previous Scala 3 release in addition to the latest one is a very easy thing to do (since your library was already building on that version!) and it eases the
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette. See also my blog at www.janvsmachine.net.
Keep it simple, stupid. You ain't gonna need it.
| trait CommonPublishModule extends LocalRepoPublishModule { | |
| def sonatypeUri: String = "http://artifactory.mysite.dev/artifactory/libs-release/" | |
| def publishVersion = "0.9.9" | |
| ... etc ... | |
| } | |
| import mill.define.{ExternalModule, Task} | |
| import mill.api.PathRef | |
| import mill.scalalib.publish.Artifact |
| import java.io._ | |
| import java.util.zip.ZipInputStream | |
| import geny.Generator | |
| import mill._ | |
| import mill.define.Target | |
| import mill.scalajslib._ | |
| object WebpackLib { |
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
example of several maven pom.xml profiles that congiure scala.js library and runtime projects
see http://stackoverflow.com/questions/26512750/how-to-use-scala-js-from-maven