scala

warning: Creating default object from empty value in /opt/bitnami/apps/portal/htdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

git bisecting scala/scala

in

git bisecting is a useful technique to locate the source of a bug. For scala/scala in particular, bisect.sh can save a lot of time by using the pre-build compiler artifacts on the Scala CI Artifactory.

scopt 4

in

scopt 4.0.0 is cross published for the following build matrix:

Scala JVM JS (1.x) JS (0.6.x) Native (0.4.0-M2) Native (0.3.x)
3.0.0-M2 n/a n/a n/a
3.0.0-M1 n/a n/a n/a
2.13.x n/a n/a
2.12.x n/a n/a
2.11.x

Here's how functional DSL looks like in scopt 4:

import scopt.OParser
val builder = OParser.builder[Config]
val parser1 = {
  import builder._
  OParser.sequence(
    programName("scopt"),
    head("scopt", "4.x"),
    // option -f, --foo
    opt[Int]('f', "foo")
      .action((x, c) => c.copy(foo = x))
      .text("foo is an integer property"),
    // more options here...
  )
}
 
// OParser.parse returns Option[Config]
OParser.parse(parser1, args, Config()) match {
  case Some(config) =>
    // do something
  case _ =>
    // arguments are bad, error message will have been displayed
}

Instead of calling methods on OptionParser, the functional DSL first creates a builder based on your specific Config datatype, and calls opt[A](...) functions that returns OParser[A, Config].

These OParser[A, Config] parsers can be composed using OParser.sequence(...).

virtualizing a hackathon at ScalaMatsuri 2020

in

Here's a report of running a virtual hackathon at ScalaMatsuri Day 2 Unconference. Someone proposed it for the Unconference, and I volunteered to be a facilitator on the day, so I went in without preparation. I booked the time originally for 4h (noon - 4pm JST, 11pm - 3am EDT) but it was successful so it got extended after some coffee break.

One thing I emphasize is The Law of Two Feet:

If at any time you find yourself in any situation where you are neither learning nor contributing: use your two feet and go someplace else

Equality in Scala

in

I gave a talk at ScalaMatsuri on 'Equality in Scala'

joining Twitter

in

I'm excited to announce that I'm joining Twitter's Build Team to work on the next generation of efficient build systems supporting thousands of Twitter developers worldwide. Today's my first day.

This is the team that developed monorepo build tool Pants, and is transitioning to migrate the flock to Bazel. This presented a unique opportunity for me to work with a team of people passionate about developer experience and productivity, and I'm looking forward to getting to know the team, and learning the new challenges.

I would also like to thank everyone who reached out to me during this transition period, often on DM, to check up on me, to stick up for me for an opportunity in their organization, and offering me projects to work on. You kept my spirits high. Thank you! Since my mandatory sabbatical started in April, I got to work on some of the projects that I previously didn't have time like build caching and Selective functor, and got to collaborate with wonderful folks at Scala Center, so it worked out in the end.

EE Build team is still hiring for "San Francisco, Remote US" location, so if that sounds interesting to you, I'd happy to talk to you.

Jar Jar Abrams

in

Jar Jar Abrams is an experimental Scala extension of Jar Jar Links, a utility to shade Java libraries.

For library authors, the idea of other library is a double-edged sword. On one hand, using other libraries avoids unnecessary duplication of work, not using other libraries is almost hypocritical. On the other hand, each library you add would add a transitive dependency to your users, increasing the possibility of conflict. This is partly due to the fact that within a single running program you can one have one version of a library.

user-land compiler warnings in Scala, part 2

in

Last week I wrote about #8820, my proposal to add user-land compiler warnings in Scala. The example I had was implementing ApiMayChange annotation. This was ok as a start, but a bit verbose. If we want some API status to be used frequently, it would be cool if library authors could define their own status annotation. We're going to look into doing that today.

user-land compiler warnings in Scala

in

As a library author, I've been wanting to tag methods in Scala that can trigger custom warnings or compiler errors. Why would I want to intentionally cause a compiler error? One potential use case is displaying a migration message for a removed API. A week ago, I sent #8820 to scala/scala proposing the idea of @apiStatus that enables user-land compiler warnings and errors.

equal protection under Eq law

in

The relationship given to Int and Long should be exactly the same as the relationship third-party library like Spire can write UInt or Rational with the first-class numeric types.

  • We should make 1 == 1L an error under strictEquality
  • We should allow custom types to participate in constant expression conversion using FromDigits

liberty, equality, and boxed primitive types

in
  • Scala 2.x uses universal equality which allows comparison of Int and String. Dotty introduces "multiversal" strictEquality that works similar to Eq typeclass.
  • Currently both Scala 2.x and Dotty use Java's == to compare unboxed primitive types. This mixes comparison of Int with Float and Double etc.
  • Float is narrower than Int, and Double is narrower than Long.
  • Because Scala transparently boxes Int into java.lang.Integer as (1: Any), it implements cooperative equality for == and ##, but not for equals and hashCode, which emulates widening for boxed primitive types. Many people are unaware of this behavior, and this could lead to surprising bugs if people believed that equals is same as ==.
  • We might be able to remove cooperative equality if we are willing to make unboxed primitive comparison of different types 1L == 1 an error.
Syndicate content