Scala で書くコンソール・ゲーム

最近リッチなコンソールアプリのことを考えることがある。ただ行を追加していくんじゃなくて、グラッフィック的な事をやっているアプリだ。多分テトリスを書けるぐらいの情報は集めたのでここにまとめておく。

ANSI X3.64 control sequences

ターミナル画面の任意の位置にテキストを表示するためには、まずターミナル (terminal) とは何かを理解する必要がある。1960年代中盤に各社は PDP-8 などいったミニコンピューターを発売し、これらは PDP-11、VAX-11 と続く。これらは冷蔵庫ぐらいの大きさのコンピューターで、「計算機センター」が購入し、RT-11 や元祖 UNIX system といったオペレーティング・システムを走らせ、同時に多くのユーザ (12 ~ 数百人?) をサポートすることができた。ミニコンピュータへ接続するために、ユーザはモノクロ画面とキーボードを合わせた物理端末を使った。端末の中でも最も有名なのは 1978年に DEC社が発売した VT100 だ。

VT100 は 80x24文字をサポートし、カーソル制御に ANSI X3.64 標準を採用した初期のターミナルの一つだ。言い換えると、プログラムは文字の列を出力することで任意の位置にテキストを表示することができた。現在の「ターミナル」アプリケーションは、「ターミナル・エミュレータ」と呼ばれることがあるが、それは VT100 といった物理端末をエミュレートしていることに由来する。

VT100 制御シーケンスのレファレンスは以下が参考になる:

• Console Virtual Terminal Sequences - Windows Console
• 11.1 Control Sequences - Screen User Manual

CUP (Cursor Position)

ESC [ <y> ; <x> H CUP Cursor Position

*Cursor moves to <x>; <y> coordinate within the viewport, where <x> is the column of the <y> line

Read More…

sbt 1.2.0

@eed3si9n 著

皆さんこんにちは。Lightbend Tooling team にかわって sbt 1.2.0 をアナウンスします。これは sbt 1 のフィーチャーリリース第二弾で、バイナリ互換性は維持しつつ新機能にフォーカスを当てたリリースとなっている。sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。

• 2018年7月31日に 1.2.0 final 版がリリースされた。
• 2018年7月6日までに大きな問題が見つからなければ、1.2.0-RC1 は 1.2.0 final 版となる予定だ。

sbt 1.2 の主な新機能はクロスJDK forking、composite project、そして実験的な thin client だ。sbt 1.1 から 6ヶ月の間他にも色々なバグ修正や改善点がたまっていた。

プラグイン開発のための SbtPlugin

SbtPlugin は、プロジェクトが sbt plugin であることを宣言するためのプラグインだ。これは自動的に scripted test を導入して、sbtPlugin := true を設定する。

lazy val root = (project in file("."))
  .enablePlugins(SbtPlugin)

互換性に関する注意: ScritpedPlugin は triggered plugin ではなくなった。

#3875 by @eed3si9n

クロス JDK forking

run や test を fork した場合、java++ を使って Java Home を切り替えれるようになった。

君達の JDK は全て jabba がいただいた

OpenJDK 11-ea, GraalVM, Eclipse OpenJ9 を試してみたり、未だに OpenJDK 6 でビルドしなければいけなかったりしたとしても jabba なら万全だ。jabba は Stanley Shyiko (@shyiko) さんが作ったクロスプラットフォームな Java のバージョンマネージャーだ。

AdoptOpenJDK 8 and 11

以下は jabba を使って Travis CI 上で AdoptOpenJDK 8 と 11 を用いてクロスビルドする方法だ:

sudo: false
dist: trusty
group: stable

language: scala

scala:
  - 2.12.7

env:
  global:
    - JABBA_HOME=/home/travis/.jabba

matrix:
  include:
  - env:
      - TRAVIS_JDK=adopt@1.8.192-12
  - env:
      - TRAVIS_JDK=adopt@1.11.0-1

before_install:
  - curl -sL https://raw.githubusercontent.com/shyiko/jabba/0.11.0/install.sh | bash && . ~/.jabba/jabba.sh

install:
  - $JABBA_HOME/bin/jabba install $TRAVIS_JDK
  - unset _JAVA_OPTIONS
  - export JAVA_HOME="$JABBA_HOME/jdk/$TRAVIS_JDK" && export PATH="$JAVA_HOME/bin:$PATH" && java -Xmx32m -version

script: sbt -Dfile.encoding=UTF8 -J-XX:ReservedCodeCacheSize=256M ++$TRAVIS_SCALA_VERSION! test

before_cache:
  - find $HOME/.ivy2 -name "ivydata-*.properties" -delete
  - find $HOME/.sbt  -name "*.lock"               -delete

cache:
  directories:
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot
    - $HOME/.jabba/jdk

ジョブが走ると、以下のように表示されるはずだ:

Expecty を用いた power assert を復活させる

先週は sbt-sriracha を用いたソース依存をテストに使う方法を紹介した。今週は Expecty を使って power assert をする方法を見ていく。

power assert (もしくは power assertion) は assert(...) 関数の変種で、自動的に詳細なエラーメッセージを表示してくれる。これは、Peter Niederwieser (@pniederw) さんがまず Spock のために実装して、2009 年に Groovy 1.7 に取り込まれた。power assert は Ruby、JavaScript、Rust など他の言語にも広まっている。

従来の assert 文

例えとして a * b を考える。従来の assert を使った場合以下のように書く:

scala> assert(a * b == 7, s"a = $a; b = $b; a * b = ${a * b}")
java.lang.AssertionError: assertion failed: a = 1; b = 3; a * b = 3

ごちゃごちゃと全部の変数への検査をログやエラーメッセージに書くといったことが往々にして行われる。

Expecty

Scala には、なんと Peter Niederwieser さん本人が 2012年ごろに書いた Expecty というミニライブラリがあって、power assert を実装する。これは、良い知らせであり、悪い知らせでもある。それがあるということそのものは良いことだ。部分的に悪いのは、オリジナルの Expecty は 2014年以降更新されておらず、多分 Gradle をビルドに使っているためクロスパブリッシュの慣例を採用していない。また、GitHub をリポジトリとして使うという昔たまにやってる人がいたねっていうあれをやっている。つまり、放置された状態にあるみたいだ。

sbt-sriracha を用いたホットなソース依存

ソース依存性はかなり前から sbt に存在するが、あまりドキュメント化されていない機能の一つだ。

immutable なソース依存

以下のようにして scopt コマンドラインパーシングライブラリの最新のコミットへのソース依存を宣言できる。

lazy val scoptJVMRef = ProjectRef(uri("git://github.com/scopt/scopt.git#c744bc48393e21092795059aa925fe50729fe62b"), "scoptJVM")

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.2"

lazy val root = (project in file("."))
  .dependsOn(scoptJVMRef)
  .settings(
    name := "Hello world"
  )

sbt を起動して compile を走らせると、sbt は自動的に scopt/scopt をステージング・ディレクトリにクローンして、ビルドをつなぎ合わせる。

そのため sbt バージョンが互換である必要があり、また、要らないトリガープラグインが混入する可能性があることにも注意してほしい。

もう一つの制約は、最初のクローンの後はステージング・ディレクトリが更新されないことだ。

ハイブリッド依存性

僕が代わりにほしいのはハイブリッド依存性で複数のリポジトリをつなぎ合わせて、コードを書いてテストを走らせることができるが、公開時には Maven のバイナリ依存性となるものだ。

これを実現するために sbt-sriracha という実験的なプラグインを書いた。project/plugins.sbt に以下を追加する:

addSbtPlugin("com.eed3si9n" % "sbt-sriracha" % "0.1.0")

すると以下のように書けるようになる:

lazy val scoptJVMRef = ProjectRef(workspaceDirectory / "scopt", "scoptJVM")
lazy val scoptJVMLib = "com.github.scopt" %% "scopt" % "3.7.0"

lazy val root = (project in file("."))
  .sourceDependency(scoptJVMRef, scoptJVMLib)
  .settings(
    name := "Hello world"
  )

デフォルトでは、これは普通のバイナリ依存性を用いる。libraryDependency セッティングを使ってそれを確認できる:

$ sbt
sbt:helloworld> libraryDependencies
[info] * org.scala-lang:scala-library:2.12.6
[info] * com.github.scopt:scopt:3.7.0

ソースモードに切り替えるには sbt を -Dsbt.sourcemode=true と共に実行する:

Bash からの Java バージョンの検知

昨日 Travis CI を用いてクロス JVM テスト する方法を書いた。

Travis CI を用いた macOS 上での Scala アプリのテスト

Travis CI を用いて macOS 上で Scala アプリのテストを行うことも可能だ。これは Lars さんと Muuki さんの方法 Testing Scala programs with Travis CI on OS X をアレンジしたものだ。

dist: trusty

language: scala

matrix:
  include:
    ## build using JDK 8, test using JDK 8
    - script:
        - sbt universal:packageBin
        - cd citest && ./test.sh
      jdk: oraclejdk8

    ## build using JDK 8, test using JDK 8, on macOS
    - script:
        - sbt universal:packageBin
        - cd citest && ./test.sh
      ## https://github.com/travis-ci/travis-ci/issues/2316
      language: java
      os: osx
      osx_image: xcode9.2

    ## build using JDK 8, test using JDK 9
    - script:
        - sbt universal:packageBin
        - jdk_switcher use oraclejdk9
        - cd citest && ./test.sh
      jdk: oraclejdk8

    ## build using JDK 8, test using JDK 10
    - script:
        - sbt universal:packageBin
        - citest/install-jdk10.sh
        - cd citest && ./test.sh
      jdk: oraclejdk8

scala:
  - 2.10.7

before_install:
  # https://github.com/travis-ci/travis-ci/issues/8408
  - unset _JAVA_OPTIONS
  - if [[ "$TRAVIS_OS_NAME" = "osx" ]]; then
      brew update;
      brew install sbt;
    fi

cache:
  directories:
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot

before_cache:
  - find $HOME/.ivy2 -name "ivydata-*.properties" -delete
  - find $HOME/.sbt  -name "*.lock"               -delete

普通はトップレベルで jdk: oraclejdk8 と書くが、macOS のイメージに jdk_switcher スクリプトが入っていないとう問題 travis/travis#2317　があるため、matrix 内の osx 以外のエントリーに jdk を書く必要がある。

Travis CI を用いたクロス JVM テスト

Oracle は non-LTS JDK を 6ヶ月おき、LTS JDK を 3年おきにリリースする計画だ。また、今後は OpenJDK に集約されていくらしい。計画どおりにいけば、JDK 9 は 2018年3月に EOL、JDK 10 は 2018年3月にリリースされ、2018年9月に EOL、そして 2018年9月に JDK8 をリプレースする LTS JDK 11 は 2021年まで続くということになる。

今後立て続けにリリースされる JDK に備えて、Travis CI を使ってアプリを JDK 8, JDK 9, そして JDK 10 Early Access でテストする方法を紹介する。

dist: trusty

language: scala

matrix:
  include:
    ## build using JDK 8, test using JDK 8
    - script:
        - sbt universal:packageBin
        - cd citest && ./test.sh

    ## build using JDK 8, test using JDK 9
    - script:
        - sbt universal:packageBin
        - jdk_switcher use oraclejdk9
        - cd citest && ./test.sh

    ## build using JDK 8, test using JDK 10
    - script:
        - sbt universal:packageBin
        - citest/install-jdk10.sh
        - cd citest && ./test.sh

scala:
  - 2.10.7

jdk:
  - oraclejdk8

# Undo _JAVA_OPTIONS environment variable
before_script:
  - _JAVA_OPTIONS=

cache:
  directories:
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot

before_cache:
  - find $HOME/.ivy2 -name "ivydata-*.properties" -delete
  - find $HOME/.sbt  -name "*.lock"               -delete

この例では、sbt と sbt-native-packager を使っているが、どのビルドツールでも動くはずだ。

sbt-nocomma を用いたカンマの消去

2016年8月

SIP-27 末尾のカンマ (trailing commas) に関するディスカッションのときに思いついたのは一部のカンマの用法をセミコロンと統一できれば、セミコロン推論を流用することができるんじゃないかということだ。

Aug 10 2016 20:46:

特に可変長引数 (vararg) の区切り文字としてセミコロンを許せば便利そうだ。しかし、実際にはそれはうまくいかない。@Ichoran さんが具体例を用いて指摘してくれた:

Seq(
  a
  b
  c
)

これは現状の Scala では Seq(a.b(c)) と解釈される。

2018年1月

最近 @swachter さんが Comma inference というスレッドを立てたので、再びこの話題のことを思い出した。

Scala には「セミコロン推論」というよく知られた機構があるが、パラメータや引数のリストに同様の機構を「コンマ推論」として導入できれば便利ではないだろうか。

僕のこれに対する返答は:

Scala (言語仕様としても我々ユーザとしても) は 1つ以上の句読点推論を取り扱うのは難しいと思うが、試す価値のあるトリックはあるかもしれない。

パーサーを通過する必要があるので、Scala として合法な「形」(shape) がまず必要になる。例えば、

scala> List({
       1
       2
       3
       })
res1: List[Int] = List(3)

以上は合法な Scala だ。中括弧はコンパイラの中では Block データ型としてパースされる。可変長 Int* の引数を受け取って、もし Block が渡された場合には各ステートメントを展開するマクロを定義することは可能かもしれない。

Read More…

sbt-sticker

以前ツイートしたとおり、sbt ステッカーを自作した。

猫番: 17日目

猫番: 17日目を書いた。始対象と終対象、積、双対性、余積など抽象構造を見ていきつつ、Either を coproduct として使う方法を紹介します。

Neovim と sbt server

ファイルパスの URI 参照へのエンコード方法

本稿では古くて新しい問題であるファイルパスの Uniform Resource Identifier (URI) へのエンコード方法について議論する。

2017年現在、権威ある情報の元は Matthew Kerwin 氏によって書かれた RFC 8089 - The “file” URI Scheme だ。

RFC 8089 The "file" URI Scheme https://tools.ietf.org/html/rfc8089 Wow, it actually happened.

— Matthew Kerwin (@phluid61) February 18, 2017

未来の読者の人は “file URI scheme RFC” で検索して最新版を探してほしい。プログラマの人は RFC を読んで下さい。この覚え書きは URI エンコーディングに関連した問題の認識を高めるためのものだが、RFC の代替とはならない。

最近 file:/foo/bar がパースできないというプラットフォーム間の相互乗り入れ問題に出くわした。ファイルパスを URI として表現するのに関連した問題に悩まされるのはこれが最初でもない。ファイルシステムという概念は 1960年代に遡り、1990年代から URL があることを考えると、このコンセンサスが取れていないというのは意外なことだ。しかし、十進法小数のように、深く掘り下げたり、データを交換しはじめると、Matrix　のほころびが見えてくるのかもしれない。

tl;dr

2020年11月現在での実装:

import java.io.File
import java.net.{ URI, URISyntaxException }
import java.util.Locale

private val isWindows: Boolean =
  sys.props("os.name").toLowerCase(Locale.ENGLISH).contains("windows")
private final val FileScheme = "file"

/** Converts the given File to a URI.  If the File is relative, the URI is relative, unlike File.toURI*/
def toURI(input: File): URI = {
  def ensureHeadSlash(name: String) =
    if (name.nonEmpty && name.head != File.separatorChar) File.separatorChar.toString + name
    else name
  def normalizeToSlash(name: String) =
    if (File.separatorChar == '/') name
    else name.replace(File.separatorChar, '/')

  val p = input.getPath
  if (isWindows && p.nonEmpty && p.head == File.separatorChar)
    if (p.startsWith("""\\""")) new URI(FileScheme, normalizeToSlash(p), null)
    else new URI(FileScheme, "", normalizeToSlash(p), null)
  else if (input.isAbsolute)
    new URI(FileScheme, "", normalizeToSlash(ensureHeadSlash(input.getAbsolutePath)), null)
  else new URI(null, normalizeToSlash(p), null)
}

/** Converts the given URI to a File. */
def toFile(uri: URI): File =
  try {
    val part = uri.getSchemeSpecificPart
    if (uri.getScheme == null || uri.getScheme == FileScheme) ()
    else sys.error(s"Expected protocol to be '$FileScheme' or empty in URI $uri")
    Option(uri.getAuthority) match {
      case None if part startsWith "/" => new File(uri)
      case _                           =>
        if (!(part startsWith "/") && (part contains ":")) new File("//" + part)
        else new File(part)
    }
  } catch { case _: URISyntaxException => new File(uri.getPath) }

ファイルパスとは何か?

以下は、網羅的なリストではないが、よく使われる OS である macOS、Linux、Windows の大部分をカバーする:

Sublime Text 3 と sbt server

Tech Hub blog にて sbt server を VS Code と併用して実行中の sbt セッションからコンパイラエラーを表示できることをデモした。本稿では Sublime Text 3 でそれをやってみる。

sbt server のための Sublime Text 3 のセットアップ方法

まずは Sublime Text 3 に tomv564/LSP プラグインを追加する。

1. cd ~/Library/Application\ Support/Sublime\ Text\ 3/Packages
2. git clone https://github.com/tomv564/LSP.git
3. ‘Preferences > Package Control > Satisfy Dependencies’ を実行する

次に sbt-server-stdio.js をダウンロードして ~/bin/ もしくは普段スクリプトを保存している場所に保存する。sbt server は、POSIX システムではデフォルトで Unix ドメインソケット、Windows では名前付きパイプを用いるが、エディタは基本的に標準出入力を期待しているみたいだ。これは VS Code エクステンション用に僕が書いた実行中のソケットを発見して、標準出入力でフロントを作る Node スクリプトだ。

これで Language Server クライアントの設定ができるようになった。 ‘Preferences > Package Settings > LSP > Settings’ を開く。

Ergodox

sbt 1.1.0-RC1 の sbt server と統一スラッシュ構文

Lightbend の技術系ブログ Tech Hub blog に sbt 1.1.0-RC1 with sbt server and slash syntax という記事を書いたので、訳しました。

@eed3si9n 著

皆さんこんにちは。Lightbend Tooling team にかわって sbt 1.1.0-RC1 をアナウンスします。これは、sbt 1 初のフィーチャーリリースで、バイナリ互換性は維持しつつ新機能にフォーカスを当てたリリースとなっている。 sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。2017年12月14日までに大きな問題が見つからなければ、1.1.0-RC1 は 1.0.0 final 版となる予定だ。

sbt 1.1 の主な新機能は統一スラッシュ構文 (unified slash syntax) と sbt server だ。これらは両方とも僕が個人的にしばらく関わってきた機能だが、sbt 1.0 には入れずに延期させたものだ。そのため、やっとこれらを世に出せるのがひとしお嬉しい。

セッティングキーの統一スラッシュ構文

sbt の 1ユーザとして、sbt シェルと build.sbt でセッティングとタスクキーに 2つの表記方法があるのが、sbt の学習を難しくしている理由だと長いこと思ってきた。コミュニティーの皆さんと議論を重ね、いくつかのプロトタイプを作った後、sbt 1.1.0-RC1 より統一スラッシュ構文がサポートされることになった。 (sbt 0.13 表記も引き続き動作するのでご心配無く)

build.sbt と sbt shell の両方において、セッティングはスコープ軸をスラッシュで分けて以下のように書くことができる:

ref / Config / intask / key

上の ref は典型的にはサブプロジェクト名もしくは ThisBuild が入り、Config は Compile や Test などコンフィギュレーションの Scala 識別子が入る。それぞれの軸は省略するか、特殊な Zero という値で置き換えることが可能なので、実際は以下のようになっている:

sbt 1.0.4 hotfix とパフォーマンスまわりの修正

Lightbend の技術系ブログ Tech Hub blog に sbt 1.0.4 hotfix and the performance fixes という記事を書いたので、訳しました。

@eed3si9n) 著

皆さんこんにちは。アメリカに住んでいる人たちは、良い感謝祭 (Thanksgiving) の連休すごせたでしょうか。 遠くからの親戚や友達が集まって食事を作ったり、小咄を交わす年中行事という意味では、日本の正月休みに近いものがあると思う。

あと、sbt 1.0.4 をリリースしたこともアナウンスします。これは sbt 1.0.x シリーズの hotfix で、バグ修正にフォーカスを当てたバイナリ互換リリースだ。 sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。

パフォーマンスデグレの修正

感謝祭ということで、お世話になっている人たちの事を考えるわけだけど、僕は Scala のツーリングエコシステムにコントリビュートしてくれている皆さんに感謝している。これは、sbt へのコードのコントリビュートだけじゃなく、考えさせられるブログ (Haoyi さんの So, what’s wrong with SBT? など)、トーク (Jeff さんの Beyond the Build Tool など)、ドキュメンテーション、IDE/エディタ統合、や代替ビルドツール (Chris さんの cbt など) も含めている。冷笑的に「sbt はダメ」って言って終わりにするんじゃなく、この人たちは腕をまくって、sbt そのものを直したり、代替案を考え出しているからだ。

sbt 1 に関連してパフォーマンスのデグレが報告されているが、何人もの人が飛び込んで取り組んでくれている。

• Scala Center の Jorge さん (@jvican) は性能向上関係を色々やっていて、sbt 1.0.4 で使われている Zinc 1.0.5 ではクラスパス上の JAR のハッシュ計算のパフォーマンスが落ちた対策として、JAR ごとにキャッシュする修正を提供してくれた。
• Sam Halliday さん (@fommil)‏ もクラスパスハッシュ問題に取り組んで、再現プロジェクトを提供したり、pull request を送ってくれた。
• OlegYch さん (@OlegYch) は testQuick のパフォーマンスがデグレを修正してくれた。 #3680/#3720
• Leonard Ehrenfried さん (@leonardehrenfried) もパフォーマンスのベンチマークに取り組んで、Sam さんの再現プロジェクトをもとに自動で実行して性能を比較するハーネスを作ってくれた。また、Ivy-log4j のパフォーマンスデグレを修正してくれた。 #3711/util#132
• Lightbend Tooling team からは Dale (@dwijnand) がパフォーマンス関連の issue に取り組んだり、社内のエキスパートから知見を得たりしている。

以下は、Leonard / Sam の 25個のサブプロジェクトを使ったテストプロジェクトで no-op compile を行った sbt 1.0.4 のパフォーマンスだ:

sbt 1 マイグレーション状況報告と 1.0.2 hotfix

Lightbend の技術系ブログ Tech Hub blog に sbt 1 migration status and 1.0.2 hotfix という記事書いたので、訳しました。

@eed3si9n 著

こんにちは。sbt 1.0.0 リリース後に何があったかのレポートだ。

僕たちの sbt 1 へのマイグレーションのプランは以下のようになっている:

• sbt 1.0.0 をリリースする。
• コミュニティーの皆さんと一緒にプラグインを全部移行させる。
• バグを修正する。
• ライブラリのビルドを移行させる。

プラグインの移行

プラグインの移植の進捗を追跡するために、知られているプラグインの一覧を作って GitHub star 順にソートした。これは、ドキュメンテーションをスクリーンスクレイピングしたのを元に、手動でも色々追加してある。ここに書かれた 258個のプラグインは新しいのや古いのも混ざっていて、sbt プラグインエコシステムの裾野の広さがよく分かる。

本日付では、一覧のうち 70個のプラグインが「リリース済み」となっていて、他にもプラグイン作者やアクティブなユーザによって移行途上の様々なステージにあるものが色々ある。中でも吉田さん (xuwei-k) は、複数箇所に同時に存在するかのような勢いで多くのプラグインの移植作業を行っていた。以下は僕が見つけた範囲:

• https://github.com/scalikejdbc/scalikejdbc/pull/714
• https://github.com/thesamet/sbt-protoc/pull/30
• https://github.com/sbt/sbt-unidoc/pull/42
• https://github.com/ktoso/sbt-jmh/pull/121
• https://github.com/xuwei-k/sbt-class-diagram/
• https://github.com/rtimush/sbt-updates/pull/75
• https://github.com/sbt/sbt-dirty-money/pull/12
• https://github.com/sbt/sbt-site/pull/107
• https://github.com/sbt/sbt-ghpages/releases/tag/v0.6.2
• https://github.com/sbt/sbt-multi-jvm/pull/34
• https://github.com/sbt/sbt-testng/issues/19
• https://github.com/sbt/sbt-onejar/pull/34

ありがとうございます!

sbt hotfix 1.0.2

あと、sbt 1.0.2 をリリースしたこともアナウンスします。これは sbt 1.0.x シリーズの hotfix で、バグ修正にフォーカスを当てたバイナリ互換リリースだ。

• ターミナルの echo 問題の修正。 #3507 by @kczulko
• deliver タスクの修正、および名前的に改善した makeIvyXml というタスクの追加。 #3487 by @cunei
• 廃止勧告が出ていた OkUrlFactory のリプレースとコネクションのリークの修正。 lm#164 by @dpratt
• セッティングキーに対して DSL チェッカーが偽陽性を出していたことの再修正。 #3513 by @dwijnand
• run と bgRun がクラスパスのディレクトリ内の変更を検知していなかったことの修正。 #3517 by @dwijnand
• ++ を修正して crossScalaVersion が変更されないようにした。 #3495/#3526 by @dwijnand
• sbt server がメッセージを逃すのを修正した。 #3523 by @guillaumebort
• consoleProject の再修正。 zinc#386 by @dwijnand
• sbt.gigahorse という JVM フラグを追加して、Gigahorse が内部で使われるか否かを指定できるようにした。これは、repositories オーバーライドと併用したときに発生する JavaNetAuthenticator の NPE のための回避策だ。 lm#167 by @cunei
• sbt.server.autostart という JVM フラグを追加して、sbt shell を起動した時に sbt server が自動スタートするか否かを指定できるようにした。手動でスタートさせるための、startServer コマンドも追加した。 by @eed3si9n
• 未使用の import 警告の修正。 #3533 by @razvan-panda

sbt や Zinc 1 を実際に使ったり、バグ報告、ドキュメンテーションの改善、プラグインを移行したり、pull request を送ってくれた皆さん、ありがとうございました!

sbt を用いた Scala language server

sbt 1.0 がリリースされてからもう一ヶ月になり、やっと少し落ち着いて sbt server のことを考えれるようになった。週末の時間をさいて最近 Scala language server (言語サーバー) を sbt server 上にハックしている。

language server って何?

language server とは、Visual Studio Code、 Eclipse Che、 Sublime Text 3 といったエディタに対して Language Server Protocol を通じて何らかの言語サービスを提供するプログラムのことだ。演算の一例を挙げると textDocument/didOpen はエディタ内でソースファイルが開かれたことをサーバーに伝える。

これは賢いアイディアで、エディタ作者を (従来の IDE のように) 単一の言語にべったりになることから解放し、また同時に言語プロバイダーは「演算」に専念すればいいようになる。JSON ベースのプロトコルなので、web アプリのバックエンドを書いている感覚に近い。もう一つ嬉しいのは、一度に全ての機能を提供しなくてもいいことだ。

Scala language server は、Iulian Dragosさんによる dragos-vscode-scala という実装が既にあって、それは ENSIME をバックエンドとして使う。僕は、だいたい Sublime と sbt だけでコードを書いているので、中抜きして直接 Zinc のイベントを使えばいいんじゃないかと思った。

sbt server

sbt server の考え方としては、ユーザの演算はコマンドとクエリとして表現でき、コンソールに表示される様々な出力はイベントとして表現できるというものだ (sbt server リブートも参照)。多くの場合、ビルドユーザが価値を見出すのはタスクの戻り値ではなく、コンパイラの警告やテストの出力といったコンテンツだ。

この設計は、language server protocol にもよくマッチしていて、彼らはストリームされるイベントに対して「通知」 (notification) という用語を使っている。

InitializeResult

まず手始めに、お互いに挨拶をする作法となっている。VS Code は、initialize というリクエストを送信するので、それに対して InitializeResult で返事をする。Microsoft社の書いた仕様は TypeScript で書かれているので、それを Contraband で使えるように GraphQL に翻訳する:

Persistent Versioning

本稿では、僕が Persistent Versioning と呼んでるバージョン方法を紹介する。本稿中に出てくるアイディアの多くは新しくもなければ僕が考案したものでもない。既に名前があるならば是非教えてほしい。

2015年に Jake Wharton (@JakeWharton) さんが メジャーバージョンアップデートのための Java 相互互換方針 (Java Interoperability Policy for Major Version Updates) というブログ記事を書いた:

A new policy from @jessewilson and I for the libraries we work on to ensure major version updates are interoperable: https://t.co/zKqYRwrXmq

— Jake Wharton (@JakeWharton) December 11, 2015

1. Java パッケージ名にバージョン番号を含むように名前を変える。

   これによって、間接的依存ライブラリが複数のバージョンを持つ場合の API 互換性の問題が即時に解決する。同じクラスパスから各々のクラスを相互干渉することなく読み込むことができる。(中略) (メジャーバージョンが 0 か 1 のライブラリはこの方針を飛ばして、メジャーバージョンが 2 に上がってから始めてもいい。)

2. Maven 座標の group ID の一部としてライブラリ名を含ませること。

   たとえ単一のアーティファクトしか持たないプロジェクトでも、group ID にプロジェクト名を入れておくと将来的に複数のアーティファクトを持ったときにルートの名前空間を散らかさなくてもいい。最初から複数のアーティファクトを持つ場合は、Maven Central などにおいてアーティファクトをまとめる方法となる。 ….

3. Maven 座標中の group ID にバージョン番号を含むように名前を変える。

   Read More…

sbt 1.0.0 はじめました

sbt 1.0.0

Lightbend の技術系ブログ Tech Hub blog に sbt 1.0.0 is now available という記事を書いたので、訳しました。 詳細は sbt 1.0.0 リリースノートを見てください。

Eugene Yokota (@eed3si9n) 2017年8月11日 著

Lightbend社 Tooling チームに代わって sbt 1.0.0 のリリースを発表します!

Mark Harrah さんが 2008 年に最初にリリースした sbt から数えると、sbt 1 は何年もかけて開発された大きな里程標であると言える。直近のメジャーリリースの sbt 0.13.x も、最初のリリースが 2013年8月なので 4年間続いたことになる。

Lightbend社 Tooling チームは 0.13 のメンテと並行して sbt 1 へ向けての進化も継続してきた。この期間中に sbt new、AutoPlugin、cached resolution などが追加された。また、コミュニティによって何百ものプラグインが書かれ、sbt の能力はただのシンプルビルドツールの能力を拡張したものとなっていった。

主な機能

• sbt 1 は Scala 2.12 を採用したため、ビルド内でやっとモダンな Scala が使えるようになった! これによって 2.10 をサポートをするプレッシャーが軽減するので、プラグイン作者やライブラリ作者にとっても朗報だ。
• sbt 1 は Zinc 1 という、クラスベースの name hashing を使う高速なインクリメンタル (差分) コンパイラを導入する。Scala のインクリメンタル・コンパイラを独り占めにするにはあまりにも重要だと思ったので、Zinc 1 は sbt/zinc という別のリポジトリに分けられ、Lightbend 社と Scala Center の共同で管理されている。
• sbt 1 はデフォルトで Gigahorse HTTP クライアント (内部は Square OkHttp) を使ってアーティファクトを並列ダウンロードする。Library Mangement API も追加され、将来の 1.x において脱Ivy が可能となるようにした。

互換性に影響のある変更点、新機能、バグ修正などのを網羅したリストは sbt 1.0.0 リリースノートにあるので参照してほしい。

Travis-CI からの (website の) 自動公開

GitHub Pages は OSS プロジェクトのドキュメントをホスティングするのに便利だ。 ここでは Travis CI を使って pull request の merge 時に自動デプロイする方法を説明する。

1. 新しい RSA キーを適当なディレクトリ内で生成する。

プロジェクト外にまずはディレクトリを作る。 キーの名前は deploy_yourproject_rsa などとつけて、他のキーと区別できるようにする。

$ mkdir keys
$ cd keys
$ ssh-keygen -t rsa -b 4096 -C "yours@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/xxx/.ssh/id_rsa): deploy_website_rsa
Enter passphrase (empty for no passphrase):

パスフレーズは空のままにする。

2. ウェブサイトプロジェクトに移動する。

プロジェクトに移動して、ブランチを立てて、.travis という名前のディレクトリを作る。

$ cd ../website
$ mkdir .travis

3. travis ユーティリティをインストールして、秘密鍵を暗号化する。

travis encrypt-file --repo foo/website ../website_keys/deploy_website_rsa .travis/deploy_rsa.enc を実行する。ここで、--repo は GitHub レポジトリを指定する。

Atreus のためのトレイ

前回 Atreus の組み立てについて書いたときに、キーボードの配置についてちょっと書いた。

さらにたとえレイアウトを克服して様々なシンボルの場所を暗記しても残っている問題が一つあって、それは置き場所だ。ラップトップと自分の間に置くと画面が遠すぎる気がする。

この問題の解決方法として、MacBook Pro のキーボード上に Atreus を配置できるようにトレイを作ってみた。

Great post; thanks. For the positioning, have you tried disabling the internal keyboard and placing the Atreus on top of the laptop?

— technomancy (@technomancy) June 19, 2017

きっかけとなったのは、Atreus の作者の @technomancy さんに Atreus を MacBook Pro のキーボード上に直接乗せてみてはどうかの提言からだ。彼の Thinkpad は丈夫なのかもしれないが、僕の新品のラップトップの上に直乗せなんて冗談じゃない。

材料

• 1 “1/4 in x 6 in x 48 in” Oak hobby board ($8.52)
• 1 3M Garnet Sandpaper Med 100 grit ($3.97)
• 1 Sandpaper 200 grit
• 1 Small Parts General Purpose Rubber, 70A Durometer, Smooth Finish, Adhesive Backed, 0.062" Thickness, 2" Width, 36" Length, Black ($8.84)
• Minwax Clear Aerosol Lacquer, Clear Gloss
• コーヒーの出がらし

道具としては、

Atreus

しばらく前にキットで買った Atreus を昨日の夜作り終えた。詳細はこんな感じ:

• Matias Quiet Click スイッチのオプションを選んだ（スライダーはグレー）。クリックという名前は付いているがクリック感は無いことに注意。
• 修飾キーには Matias Quiet Linear スイッチを使用（スライダーは赤）。
• いわゆる ortholinear 系の格子状の、スプリットレイアウトで、42 のキーがある。
• マホガニー材の合板。

材料

キットには Arteus キーボードを組み立てるのに必要なものはほぼそろっている。自分で用意する必要があるのはラッカー、半田ごて、ハンダ、とニッパーだ。

• Minwax Clear Aerosol Lacquer, Clear Gloss
• Hakko Digital FX888D & CHP170 bundle, includes Soldering Station & CHP170 cutter
• Hakko T18-C2 - T18 Series Soldering Tip for Hakko FX-888/FX-8801
• DMiotech 0.8mm 50G 63/37 Rosin Core Tin Lead Soldering Solder Wire

ここで注意してほしいのは Matias社のスイッチは、80年代とか 90年代に Apple Standard Keyboard などで採用された日本のアルプス電気の Alps SKCM のクローンであることだ。そのため、Cherry MX スイッチ用のおしゃれなキーキャップは一切使うことができない。それがやりたい人は Cherry 互換のパーシャルキットを注文する必要がある。

Gigahorse 0.3.0

Gigahorse 0.3.0 をリリースした。Gigahorse が何かはドキュメンテーションをみてほしい。

OkHttp サポート

0.3.0 は Square OkHttp サポートを追加する。 Gigahorse-OkHttp は Scala 2.10, 2.11, 2.12 向けにクロスビルドされている。

JavaDoc によると、OkHttpClient のインスタンスは close しなくてもいいらしい。

scala> import gigahorse._, support.okhttp.Gigahorse
import gigahorse._
import support.okhttp.Gigahorse

scala> import scala.concurrent._, duration._
import scala.concurrent._
import duration._

scala> val http = Gigahorse.http(Gigahorse.config) // don't have to close
http: gigahorse.HttpClient = gigahorse.support.okhttp.OkhClient@23b48158

sbt 1.0 ロードマップと beta-1

Lightbend の技術系ブログ Tech Hub blog に sbt 1.0 roadmap and beta-1 という記事書いたので、訳しました。

@eed3si9n 著

sbt 1.0 はかれこれ数年間制作中という状態が続いていて、コミュニティーの中には「もう出ないのでは」という懐疑派がいてもおかしくない。そのような懸念は以下の論点によって払拭できると思っている:

• 本来 1.0 に予定していた (AutoPlugin や Dotty サポートのような) 機能はすでにテクノロジー・プレビューとして 0.13 系にてリリースされている。
• 1.0 に予定されていた機能のうち、より意欲的なものは延期または機能を縮小して 1.0 が早期に実現できるようにした。（キャッシュ化されたコンパイルや Ivy の置き換えなど）
• sbt 1.0 はベーパーウェアではない。最新だと 1.0.0-M5 などマイルストーンが出ていて、今すぐ試すことができる。

そのため、2017年夏までに sbt 1.0 プランを実現可能だと思っている。

ハイライト

sbt 1.0 は、向こう数年間続く安定版であることと、sbt 0.13 系からのスムーズな移行が可能であることを目標とする。sbt 0.12 スタイルの演算子や Build トレイトは削除される。本来 1.0 に予定していた機能はすでにテクノロジー・プレビューとして 0.13.x シリーズにてリリースされている。

sbt 1.0 における利点をまとめると:

• ビルド定義やプラグインに Scala 2.12 が使えるようになる
• 大規模コードベースにおいて高速化が見込まれる新インクリメンタルコンパイラ、Zinc 1
• 今後の IDE 統合の改善の下地となる sbt server

タイミング

sbt 1.0.0-M5 は最初のベータ版である。残っている課題のうち重要なものは:

sbt-sidedish を使ったアプリのダウンロードと実行

sbt プラグインから JAR をダウンロードしてそれを実行したいという要望が出てきてる。 最近だと Brooklyn での nescala で Shane Delmore (@shanedelmore) さんに聞かれた。

アンカンファレンスのセッションでデモっぽいものをやっつけで作ったけども、家に帰ってからも色々いじったのでここに報告する。

sbt-sidedish

sbt-sidedish はアプリをサイドメニュー的に落としてきて実行するためのプラグイン作者のためのツールキットだ。それそのものは特にプラグインを定義しない。

rewritedemo、コマンドラインアプリ

サイドで走らせたいアプリを作る。これは Scala 2.11 や 2.12 を使ってもいい。 Scalafix を使って import 文を追加するデモアプリを書いた。Scalafix は Scala コードの書き換えツールとライブラリで scala.meta を使っている。詳細は Scalafix のドキュメンテーションとソースを参照。

sbt-rewritedemo、sbt プラグイン

次に、rewritedemo アプリをあるサブプロジェクト相手に実行して別のサブプロジェクトを導出したいとする。 sbt-sidedish を使って以下のようなプラグインが書ける。

package sbtrewritedemo

import sbt._
import Keys._
import sbtsidedish.Sidedish

object RewriteDemoPlugin extends AutoPlugin {
  override def requires = sbt.plugins.JvmPlugin

  object autoImport extends RewriteDemoKeys
  import autoImport._

  val sidedish = Sidedish("sbtrewritedemo-metatool",
    file("sbtrewritedemo-metatool"),
    // scalaVersion
    "2.12.1",
    // ModuleID of your app
    List("com.eed3si9n" %% "rewritedemo" % "0.1.2"),
    // main class
    "sbtrewritedemo.RewriteApp")

  override def extraProjects: Seq[Project] =
    List(sidedish.project
      // extra settings
      .settings(
        // Resolve the app from sbt community repo.
        resolvers += Resolver.bintrayIvyRepo("sbt", "sbt-plugin-releases")
      ))

  override def projectSettings = Seq(
    rewritedemoOrigin := "example",
    sourceGenerators in Compile +=
      Def.sequential(
        Def.taskDyn {
          val example = LocalProject(rewritedemoOrigin.value)
          val workingDir = baseDirectory.value
          val out = (sourceManaged in Compile).value / "rewritedemo"
          Def.taskDyn {
            val srcDirs = (sourceDirectories in (example, Compile)).value
            val srcs = (sources in (example, Compile)).value
            val cp = (fullClasspath in (example, Compile)).value
            val jvmOptions = List("-Dscalameta.sourcepath=" + "\"" + srcDirs.mkString(java.io.File.pathSeparator) + "\"",
              "-Dscalameta.classpath=" + "\"" + cp.mkString(java.io.File.pathSeparator)+ "\"",
              "-Drewrite.out=" + out)
            Def.task {
              sidedish.forkRunTask(workingDir, jvmOptions = jvmOptions, args = Nil).value
            }
          }
        },
        Def.task {
          val out = (sourceManaged in Compile).value / "rewritedemo"
          (out ** "*.scala").get
        }
      ).taskValue
  )
}

trait RewriteDemoKeys {
  val rewritedemoOrigin = settingKey[String]("")
}

object RewriteDemoKeys extends RewriteDemoKeys

sbt 0.13.13 で入ったシンセティック・サブプロジェクトという機能を使っている。

猫番: 16日目

猫番: 16日目書いた。

sbt 0.13.15 リリースノート

互換性に影響のある新機能、変更点、バグ修正

• sbt 0.13.14 は Maven のバージョンレンジをできる限り取り除く。詳細は後ほど。

改善点

• 予備として JDK 9 との互換性を追加した。この機能は 0.13.14 以降のネイティブパッケージを必要とする。 #2951/143 by @retronym
• オフライン・インストール用に “local-preloaded” レポジトリを追加する。詳細は後ほど。
• ウォーミングアップされた JVM に留まるように、バッチモードで sbt を実行すると [ENTER] を押して shell に切り替えるよう通知するようにした。 #2987/#2996 by @dwijnand
• .taskValue を使わずに sourceGenerators += Def.task { ... } と書けるようにするために Append のインスタンスを追加した。 #2943 by @eed3si9n
• JUnitXmlTestsListener が生成する XML が無視、スキップ、保留状態のテストにそれぞれフラグを立てるようにした。 #2198/#2854 by @ashleymercer
• プロジェクトが Dotty を使ってコンパイルしていると検知した場合に、自動的に scalaCompilerBridgeSource を設定して、Dotty プロジェクトのボイラープレートを軽減するようにした。ただし、sbt における Dotty サポートは現在実験的であり、正式にはサポートされていないことに注意。詳細は dotty.epfl.ch 参照。 #2902 by @smarter
• sbt new のレファレンス実装である Giter8 を 0.7.2 にアップデートした。

バグ修正

• .triggeredBy、.storeAs などが　:= と .value マクロと動作しない問題の修正。 #1444/#2908 by @dwijnand
• JLine を更新して、Windows から Ctrl-C が動作しない問題の修正。 #1855 by @eed3si9n
• ビルドレベルのキーの処理を誤っていた 0.13.11 から 0.13.13 のリグレッションの修正。 #2851/#2460 by @eed3si9n
• Compile を継承しないコンフィギュレーションにおいても Scala バージョンの強制を行っていた sbt 0.13.12 におけるリグレッションの修正。 #2827/#2786 by @eed3si9n
• スクリプトモードにおいてクォーテーションが無視されていたことの修正。 #2551 by @ekrich
• Ivy がときおり IllegalStateException になることの修正。 #2827/#2015 by @eed3si9n
• sourceFile が null のときに NPE がでることの修正。 #2766 by @avdv

Maven のバージョンレンジの改善

以前は、依存性解決 (Ivy) が [1.3.0,) といった Maven のバージョンレンジを見つけると Internet に行って最新のバージョンを探しに行っていた。これは、範囲の条件を満たすライブラリがビルド内にあったとしても最終的なバージョンが経年変化するという驚くべき振る舞いをしていた。

Contraband、case class の代替案

しばらく考えている疑問がいくつかある:

• データや API はどう書かれるべきだろうか?
• そのデータは Java や Scala ではどう表現されるべきか?
• そのデータは JSON などのワイヤーフォーマットにどう変換することができるか?
• そのデータをどうやってバイナリ互換性を崩さずに進化させることができるか?

case class の限界

Scala でデータ型を表現する慣用的な方法は sealed trait と case class だが、バイナリ互換性を保ったままフィールドを追加することができない。簡単な Greeting という case class を例に取って、それがどのようなクラスとコンパニオンオブジェクトに展開されるか考察してみよう:

package com.example

class Greeting(name: String) {
  override def equals(o: Any): Boolean = ???
  override def hashCode: Int = ???
  override def toString: String = ???
  def copy(name: String = name): Greeting = ???
}
object Greeting {
  def apply(name: String): Greeting = ???
  def unapply(v: Greeting): Option[String] = ???
}

次に、x という新しいフィールドを追加する:

package com.example

class Greeting(name: String, x: Int) {
  override def equals(o: Any): Boolean = ???
  override def hashCode: Int = ???
  override def toString: String = ???
  def copy(name: String = name, x: Int = x): Greeting = ???
}
object Greeting {
  def apply(name: String): Greeting = ???
  def unapply(v: Greeting): Option[(String, Int)] = ???
}

見て分かる通り、copy メソッドと unapply メソッドはバイナリ互換性を崩す。

sbt 0.13.x、sbt サーバー、sbt 1.0 の動向

同僚の Dale Wijnand (@dwijnand) と一緒に ScalaSphere でトークをしてきた。The state of sbt 0.13, sbt server, and sbt 1.0 (ScalaSphere ver):