git リポジトリの分岐

サブディレクトリを新しいリポジトリへ分岐させる (シンプルな場合)

git clone --no-hardlinks --branch master originalRepoURL childRepo
cd childRepo
git filter-branch --prune-empty --subdirectory-filter path/to/keep master
git remote remove origin
git prune
git gc --aggressive

originalRepoURL、master、path/to/keep などは適当な値に変える。全てのブランチを処理したい場合は -- --all を使う。

サブディレクトリを新しいリポジトリへ分岐させる (複雑な場合)

複数のパスをフィルターしたい場合は、--index-filter と brew install gnu-sed findutils によってインストールできる GNU xargs と GNU sed を使う必要がある。

git clone --no-hardlinks --branch master originalRepoURL childRepo
cd childRepo
git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- path1/to/keep path2/to/keep' --prune-empty master
git filter-branch --prune-empty --parent-filter 'gsed "s/-p //g" | gxargs git show-branch --independent | gsed "s/\</-p /g"'
git remote remove origin
git prune
git gc --aggressive

    Read More…
  

君達の JDK は全て SDKMAN! がいただいた

これは Travis CI に自分で JDK をインストールする解説の第2弾だ。以前は、jabba を紹介した。

今日は SDKMAN!, という、Marco Vermeulen (@marc0der) さんが作った元気な名前のツールを見ていく。これは、JDK の他にも Groovy、Spark、sbt など JVM 上の様々なツールを対象とする環境マネージャーだ。

AdoptOpenJDK 11 と 8

• 2020-09-23 更新: バージョン番号の正規表現を更新した。
• 2019-11-06 更新: SDKMAN の更新プロンプトが CI をブロックするのを回避するために sdkman_auto_selfupdate を追加した。また、sdk install の行に || true を追加した。
• 2019-07-08 更新: パッチバージョンを自動検知するように変更した。古い版は GitHub に置いてある。

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

dist: xenial

language: scala

scala: 2.12.10

matrix:
  include:
  - env:
      - ADOPTOPENJDK=11
  - env:
      - ADOPTOPENJDK=8

before_install:
  # adding $HOME/.sdkman to cache would create an empty directory, which interferes with the initial installation
  - "[[ -d /home/travis/.sdkman/ ]] && [[ -d /home/travis/.sdkman/bin/ ]] || rm -rf /home/travis/.sdkman/"
  - curl -sL https://get.sdkman.io | bash
  - echo sdkman_auto_answer=true > /home/travis/.sdkman/etc/config
  - echo sdkman_auto_selfupdate=true >> $HOME/.sdkman/etc/config
  - source "/home/travis/.sdkman/bin/sdkman-init.sh"

install:
  - sdk install java $(sdk list java | grep -o "$ADOPTOPENJDK\.[0-9]*\.[0-9]*\.hs-adpt" | head -1) || true
  - unset _JAVA_OPTIONS
  - unset JAVA_HOME
  - 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/.cache/coursier
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot
    - $HOME/.sdkman

    Read More…
  

Docker での sbt

Docker 内で sbt を走らせたかったので、イメージをいくつか作った。GitHub リポジトリは eed3si9n/docker-sbt。

Pamflet 0.8.0

年末の連休中に Pamflet の left TOC (目次) を実装して、Pamflet 0.8.0 としてリリースした。

Pamflet は短い文書、特にオープンソース・ソフトウェアの ユーザ・ドキュメントを公開するためのアプリだ。

scala.Seq のマスキング

現行の Scala 2.13.0-M5 のままで行くと、scala.Seq は scala.collection.Seq から scala.collection.immutable.Seq に変更される予定だ。Scala 2.13 collections rework に何故今まで不変じゃなかったのかの解説が少し書かれている。行間から推し量ると、scala.Seq がデフォルトで不変になることを喜ぶべきだと言っているんだと思う。

デフォルトで列が不変になることはアプリや新しく書かれるコードには良いことだと思う。ライブラリ作者にとってはもう少しこみいっているかもしれない。

• あなたがクロスビルドされたライブラリを持っていて
• ライブラリのユーザも複数の Scala バージョンを使っていて
• ライブラリのユーザが Array(...) を使っていた場合

この不変 Seq への変更は、breaking change つまり非互換な API 変更となりうる。

失敗例としては scopt/scopt#218 がある。僕が scopt のクロスビルドを行ったが、args を渡せなくなったらしい。Scala 2.13.0-M5 においても args は Array[String] のままだ。

シンプルな修正は全てのソースにおいて scala.collection.Seq を import することだ。僕が欲しいのは Seq を使うとコンパイルが通らなくなることだ。

scala.Seq を unimport する

まず最初にやってみたのは scala.Seq を unimport して、scala.collection.Seq か scala.collection.immutable.Seq のどちらかを import することを強制することだ。

カンファレンスを女性にとってよりセーフなスペースにするための方法

技術カンファレンスにおける女性の参加率 (やその他のバックグラウンドを持つ人の参加率) を改善するには、周辺のカルチャーを変えていく必要がある。そのためには以下の 2点に関してハッキリとしたシグナル化とコミュニケーションを必要とする

1. カンファレンスで女性参加者をナンパするのはダメ
2. 技術的な能力を前提として、女性参加者とプロフェッショナルかつ対等に接する これらは全てのカンファレンスにおいて基調講演の前と、社交タイムの前に繰り返し連絡されるべき事項だ。

sbt のための super shell

週末中に sbt のための super shell の実装がまとまってきたのでここに報告する。大まかな概要としては、ターミナル画面の下 n行を乗っ取って今走っているタスクを表示させる。

ログを現状報告に使うことの限界

ログは多くの場面で有用で、時としては何が起こっているかを知るための唯一の現実解であったりする。だけども、sbt のようなコンソールアプリにおいては、ログを使ってビルド・ユーザに現在なにが起こっているかを報告するのはうまくいかないことがある。

仮に sbt が一切ログを表示しなかったとすると、sbt が長時間走るタスクを実行して一見固まってしまったときに何が起きているか分からなくなる。そのため、update のようなタスクは “Updating blabla subproject” と “Done updating” といった開始、終了ログを表示する。update タスクはユーザやビルドによって非常に長い時間がかかってしまうことで有名だが、少ないライブラリ依存性を持つその他の多くのビルドは 1s 以内で完了する。そのような場合、ビルドの開始時に “Done updating” がズラーッと壁のように並ぶことになる。

つまり、ログ表示を現状報告に使うのはログが出すぎてうるさい状態と、情報が足りなくて不便な両極端の間を揺れることになる。

show your work (途中式を書くこと)

人生における多くの事と同様に、やったことの提示方法やユーザー・インターフェイスはその作業とかプロダクトそのものの必要不可欠な側面であり、特にその作業やプロダクトが自明で無いものほどそれが顕著になる。

僕は、sbt が単一のコマンド実行内においてタスクを並列処理することを当たり前のように考えてきた。しかし、最近になってその事を知らない人がいる場面に出くわすことが増えてきた。これは、実はもっともなことだ。なぜなら、ビルドの DSL もユーザインターフェイスも sbt がタスクの並列処理を行っていることを明らかにしていないからだ。

さらに、古参のユーザが sbt がタスクを並列実行していることを信じていたとしても、現在はどのタスクがパフォーマンスのボトルネックになっているのかを知るのが難しい。何らかのプラグインが不必要に update を呼び出したり、ソースが一切変わっていないのにプロセス外の Typescript コンパイラを呼び出したりしているかもしれない。

super shell

現在実行中のタスクを表示する “super shell” はこれらの問題を解決する。1s 以内に実行するタスクは画面には表示されず、長時間走っているタスクはカウントアップする時計が表示される。

初めて僕がこのような機能に気付いたのは Gradle の “rich console” だ。Buck もこれを実装していて、“super console” と呼ばれているらしいので、僕もその名前を借りることにした。

-Xlint, -Xfatal-warnings, そして Scalafix を用いた Scala の厳格化

コンパイルする、さもなければコンパイルしない。警告などいらない。最近気に入っている Scala コンパイラのフラグは "-Xlint" と "-Xfatal-warnings" の 2つだ。

以下は、サブプロジェクトと共に使えるセッティングの例だ:

ThisBuild / scalaVersion := "2.12.6"

lazy val commonSettings = List(
  scalacOptions ++= Seq(
    "-encoding", "utf8",
    "-deprecation",
    "-unchecked",
    "-Xlint",
    "-feature",
    "-language:existentials",
    "-language:experimental.macros",
    "-language:higherKinds",
    "-language:implicitConversions"
  ),
  scalacOptions ++= (scalaVersion.value match {
    case VersionNumber(Seq(2, 12, _*), _, _) =>
      List("-Xfatal-warnings")
    case _ => Nil
  }),
  Compile / console / scalacOptions --= Seq("-deprecation", "-Xfatal-warnings", "-Xlint")
)

lazy val foo = (project in file("foo"))
  .settings(
    commonSettings,
    name := "foo",  
  )

    Read More…
  

git gone: stale なローカルブランチのクリーンアップ

GitHub の pull request を中心に作業していると、やたらといらないブランチがローカルに溜まってくる。本稿では、このいらないローカルブランチを掃除する方法をみてみる。

基本的に 2つの戦略があると思う:

• “master” ブランチを選んで、そこにマージ済みのものを削除する
• GitHub 上で既にブランチは削除されている前提で、リモートの “origin” にはもう無いローカルのブランチを削除する

Erik Aybar さんの Git Tip: Deleting Old Local Branches というブログ記事は第2の方法をとっている。

This just helped clean up 150+ old local branches for me this morning, so I thought I should share! #githttps://t.co/VLKLtl5inp

— Erik Aybar (@erikaybar_) January 31, 2017

git gone

git gone は、Erik Aybar さんのテクニックをベースに僕が書いたカスタム git コマンドだ。Bash でスクリプト書くのは不慣れなので Google とか Stackoverflow を見ながら書いたが、一応動いてくれていると思う。eed3si9n/git-gone にソースを貼ったのでそれを ~/bin など適当な場所に git-gone として保存する。

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

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)

    Read More…
  

君達の 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

    Read More…
  

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

    Read More…
  

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"
  )

    Read More…
  

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

    Read More…
  

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

    Read More…
  

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

2016年8月

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

Aug 10 2016 20:46:

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

Seq(
  a
  b
  c
)

    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月現在での実装:

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 スクリプトだ。

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 表記も引き続き動作するのでご心配無く)

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 マイグレーション状況報告と 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 を用いた 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 リブートも参照)。多くの場合、ビルドユーザが価値を見出すのはタスクの戻り値ではなく、コンパイラの警告やテストの出力といったコンテンツだ。

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 に上がってから始めてもいい。)

   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):

    Read More…
  

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 における利点をまとめると:

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

    Read More…
  

猫番: 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] = ???
}

    Read More…
  

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):

Gigahorse 0.2.0

Gigahorse 0.2.0 をリリースした。新機能は 2つのバックエンドを選べるようになったことだ。 @alexdupre さんが AHC 1.9 から Netty 4 ベースの AHC 2.0 への移行をコントリビュートしてくれた。#12

さらに、#15 で僕が実験的な Akka HTTP サポートを追加した。

詳しくは Gigahorse ドキュメントを参照してほしい。

Scala 2.12.0 リリースノート

昨日リリースされたばかりの Scala 2.12.0 のリリースノートを翻訳しました。 Lightbend 社 Scala チームのコンパイラ魂を感じ取れる、マニアな内容になっています。

Scala 2.12.0 がリリースされました!

Scala 2.12 コンパイラは Java 8 から使えるようになった新しい VM 機能を利用するために、完全なオーバーホールが行われた。

• トレイトは、デフォルトメソッド付きのインターフェイスに直にコンパイルされる。これはバイナリ互換性と Java との相互運用性を向上させる。
• Scala と Java 8 の相互運用 (interop) という点では、関数を受け取るメソッドが両方向からもラムダ構文で呼び出せるようになったので関数型なコードにおいても改善した。Scala 標準ライブラリの FunctionN クラス群は、Single Abstract Method (SAM) 型となり、全ての SAM型は、型検査からコード生成におけるまで統一的に取り扱われる (クラスファイルは生成されず、代わりに invokedynamic が用いられる)。

gigahorse-github 0.1.0

gigahorse-github 0.1.0 をリリースした。これは、Github API v3 のための Gigahorse プラグインだ。

Gigahorse 0.1.0

更新: Gigahorse 0.1.1　を使ってください。

Gigahorse 0.1.0 をリリースした。これは Scala のための HTTP クライアントで、内部にAsync Http Client を使っている。詳しくは Gigahorse ドキュメントを書いたので、それを参照してほしい。ライブラリがどういう感じなのかを例でみるとこんな感じだ。

scala> import gigahorse._
scala> import scala.concurrent._, duration._
scala> Gigahorse.withHttp(Gigahorse.config) { http =>
         val r = Gigahorse.url("http://api.duckduckgo.com").get.
           addQueryString(
             "q" -> "1 + 1",
             "format" -> "json"
           )
         val f = http.run(r, Gigahorse.asString andThen {_.take(60)})
         Await.result(f, 120.seconds)
       }

registry and reference パターン

ここ最近考えている「パターン」があって、オブジェクトを永続化/シリアライゼーションするみたいな状況で出てくる。

問題提起として、以下のような case class を考えてみてほしい:

scala> case class User(name: String, parents: List[User])
defined class User

scala> val alice = User("Alice", Nil)
alice: User = User(Alice,List())

scala> val bob = User("Bob", alice :: Nil)
bob: User = User(Bob,List(User(Alice,List())))

scala> val charles = User("Charles", bob :: Nil)
charles: User = User(Charles,List(User(Bob,List(User(Alice,List())))))

scala> val users = List(alice, bob, charles)
users: List[User] = List(User(Alice,List()), User(Bob,List(User(Alice,List()))),
  User(Charles,List(User(Bob,List(User(Alice,List()))))))

    Read More…
  

sjson-new とアズカバンの囚人

本稿は sjson-new に関する第3部だ。パート1、パート2も是非読んでみてほしい。

sbt のコード内にはデータ永続化が数百メガバイトのオーダーに達している部分がいくつかあって、特にマシンに SSD が積まれていない場合は性能ボトルネックになる疑いがあるんじゃないかと思っている。 当然、最初に飛びついたのは Google Protocol Buffers のエンコーディングを参考に独自のバイナリフォーマットを実装することだった。

sbt-jmh を用いたマイクロベンチマーク

僕がまずやるべきだったのは、ベンチマークを取ることだ。@ktosopl (Konrad Malawski)君の sbt-jmh を使うとマイクロベンチマークは簡単に作ることができる。ビルドにプラグインを入れて、JmhPlugin を有効化したサブプロジェクトを定義するだけだ。

lazy val benchmark = (project in file("benchmark")).
  dependsOn(supportSpray). // add other subprojects you want to test
  enablePlugins(JmhPlugin).
  settings(
    libraryDependencies ++= Seq(jawnSpray, lm),
    // sbt-jmh forks the run, so you would need these
    javaOptions in (Jmh, run) ++= Seq("-Xmx1G", "-Dfile.encoding=UTF8"),
    publish := {},
    publishLocal := {},
    PgpKeys.publishSigned := {}
  )

    Read More…
  

sjson-new と LList を用いたカスタムコーデック

2ヶ月ぐらい前に sjson-new について書いた。週末にまたちょっといじってみたので、ここに報告する。 前回は Scala エコシステムにおける JSON ライブラリの家系をたどって、複数バックエンドに対応し、かつ型クラスベースの JSON コーデックライブラリという概念を導入した。課題は、カスタムコーデックを簡単に定義できるようにする必要があるということだった。

私家版 shapeless

4月に書いたのと先週までの間に flatMap(Oslo) 2016 と Scala Days New York 2016 という 2つのカンファレンスがあった。残念ながら、僕は flatMap の方には行けなかったけども、Daniel Spiewak さんの “Roll Your Own Shapeless” (「私家版 Shapeless のすゝめ」) というトークを New York で聞けた。flatMap 版の方が完全版でそれは vimeo にも出てるので、是非チェックしてみてほしい。

sbt の内部では、sbinary を用いたキャッシングに HList が用いられてたりする:

implicit def mavenCacheToHL = (m: MavenCache) => m.name :*: m.rootFile.getAbsolutePath :*: HNil
implicit def mavenRToHL = (m: MavenRepository) => m.name :*: m.root :*: HNil
...

    Read More…
  

foundweekends

週末に趣味プログラミングをする人のための Github organization として foundweekends を作った。参加したい人は twitter か Gitter で声をかけてください。

当面の活動は @n8han から conscript、giter8、pamflet を引き継ぐことだ。

sjson-new

背景

ソフトウェアプロジェクトを考える面白い方法の一つとして、文学的な解析があると思う。つまり、実際のコードの字面を追うだけじゃなくて、誰が、いつ、何故 (どういった問題を解決するために) どのようにして (何の影響を受けて) 書いたのかを考察することだ。そういった意味では、Scala エコシステムにおいては JSON ライブラリほど豊かなジャンルは他に無いのではないだろうか。

2008年12月に Programming in Scala の初版が出て、JSON はパーサ・コンビネータの一例として出てきて、JSON パーサが 10行ぐらいのコードで書けることを示した:

import scala.util.parsing.combinator._
class JSON extends JavaTokenParsers {
  def value : Parser[Any] = obj | arr |
                            stringLiteral |
                            floatingPointNumber |
                            "null" | "true" | "false"
  def obj   : Parser[Any] = "{"~repsep(member, ",")~"}"
  def arr   : Parser[Any] = "["~repsep(value, ",")~"]"
  def member: Parser[Any] = stringLiteral~":"~value
}

    Read More…
  

sbt server リブート

これは先日書いた sbt 1.0 ロードマップの続編だ。この記事では sbt server の新しい実装を紹介する。感想やコメントがあれば sbt-dev mailing list にお願いします。

sbt server の動機は IDE との統合の改善だ。

ビルドは、巨大で、可変で、共有された、状態のデバイスだ。ディスクのことだよ! ビルドはディスク上で動作するのもであって、ディスクから逃れることはできない。

– Josh Suereth、The road to sbt 1.0 is paved with server より

マシンに積んであるディスクは根本的にステートフルなものであり、sbt がタスクを並行実行できるのもそれが作用に関する完全なコントロールを持っていることが大前提になっている。同じビルドに対して sbt と IDE を同時に実行していたり、複数の sbt インスタンスを実行している場合は、sbt はビルドの状態に関して一切保証することができない。

sbt 1.0 ロードマップ

sbt 1.0 にに関して TL上とかで議論があったので、叩き台としてこれを書くことにした。何かをちゃんとリリースできるように仕切り直しするための中期的なミッション・ステートメントだと思ってほしい。sbt-dev mailing list にて今後も議論を続けていきたい。

タイミング

いつ sbt 1.0 をリリースできるかという予定はまだ見当が付いていない。 sbt 1.0 の最大の機能はコードの再組織で、それは既に進んでいる: http://www.scala-sbt.org/0.13/docs/Modularization.html

sbt/io、 sbt/util、 sbt/librarymanagement、 sbt/incrementalcompiler といったモジュールがある。実装という観点からするとインクリメンタルコンパイラが sbt の中で一番複雑な部分だと思うので、まずはそれをモジュール化することを目標としてきた。全部のモジュールの API が安定したときが、sbt 本体にも 1.0 を付けれる時になる。

モジュール化の動機

sbt/sbt の現在のコードは、ビルドユーザやプラグイン作者に内部を晒しすぎている。これによってとっつきづらいコードになっている。さらに、バイナリ互換性を保つのも難しくなっている。 モジュール化の目標はどこまでが public な API でどこからが private な実装なのかの境界をハッキリさせることだ。

あと、これらのモジュールは今まで使ってたような Ivy リポジトリじゃなくて Maven Central に乗せる。

sbt/zinc

新しいインクリメンタルコンパイラは完全に name hashing に移行する。name hashing はしばらく前 (sbt 0.13.6) からデフォルトでオンになっている。それだけじゃなくて、クラスベースの name hashing を使う予定で、これは性能改善が期待されている。

Java バージョン

sbt 0.13 は JDK 6 の上に書かれている。sbt 1.0 は JDK 8 ベースだ。