Scala 3かつplayframework 3かつpekkoで動かすサンプル - xuwei-k's blog
数ヶ月前に、playframeworkのScala 3対応版リリース記念にplay 2.9のマイルストーンでNetty backendで同じものを書いたのですが、 昨日書いたように予定通りplayframework 3.0のpekko対応の準備としてマイルストーン( 3.0.0-M1 )がリリースされたので、同じようなものを貼っておきます。 これで akkaの依存はゼロ (playframework関係なく現状必ずついてくる)Scala 2のscala-library以外はScala 2.13のjarの依存もゼロ という状態のはずです。 playframeworkは3からmavenのgroupIdが com.typesafe.play から org.playframework に変わっているので注意しましょう。 以前のplay 2.9のNetty版 https://gist.github.
Scala 3で独自にunion typeのleast upper boundを計算する仕組みを作った - xuwei-k's blog
Scala 3では、以下のように | というunion type？or type？という新しい仕様が追加されました。 (仕様というか、少なくとも以下の公式ドキュメントではunionと呼んでるが、Scala 3のquoteのAPI内部ではOrTypeでややこしい) https://docs.scala-lang.org/scala3/book/types-union.html Welcome to Scala 3.3.0-RC3 (11.0.18, Java OpenJDK 64-Bit Server VM). Type in expressions for evaluation. Or try :help. scala> List(2, "a") val res0: List[Int | String] = List(2, a) しかし、これをScala 2でおこなったら、当然以下のように
sbtの独自Configurationを使ったbuild速度の改善 - xuwei-k's blog
突然ですが、皆さんsbtのchrome trace吐き出す機能使ってますか？大抵の人は使ってないというか、存在すら知らないと思います。 https://github.com/sbt/sbt/pull/4576 以前以下のあたりでも多少話を出しました https://xuwei-k.hatenablog.com/entry/2022/03/30/142529 さて、それを使ってsbtのbuildのsub project毎のcompile速度を眺めて、頭の中でDAGを描いてみたときに、稀に、 「testのためのユーティリティを参照させるために test->test を追加しているが、そのせいで遅い」 というパターンがあると思います。 ここに共感してもらわないと話が始まらないのですが、そこを詳しく説明すると長くなるので、多少、大雑把な説明で済ませますが、 https://github.com/x
Scala 3のmatch typeでcompile timeにString literalをparseして評価する - xuwei-k's blog
Scala 3のmatch typeで何かのparserでも書くか?と思ったけど、コンパイル時にリテラルのStringを、型情報というか分解した場合の値情報？を、保ったままの分解が単純には出来そうにはないというか… あるいは一旦CharのHListにしたいんだけど、何か方法あるのかな— Kenji Yoshida (@xuwei_k) February 28, 2021 https://t.co/sNupBRy3rV type Substringが増えてるからいける…？— Kenji Yoshida (@xuwei_k) 2022年2月28日 できました。 parserなどに慣れてないので、とりあえず以下のクソ雑仕様？だけど、tokenにするのとparseとevalをなんとなくちゃんと分けたぞ！ みんなScala 3のmatch typeで、任意の言語などのparserや評価機を書こう！！
Scala 3のmacroによる型安全かつ実行時にリフレクションにならないClose型クラス(ローンパターン)の実装 - xuwei-k's blog
というのがおそらく作成できたけれど、もっと書き方改善可能なところあったら教えて下さい。 このくらいすでに、Scala 3でも前例が存在する気もするけど、とりあえず(あまり前例は調査はせずに)自作しました。 テスト書いてあるとおり、指定されたcloseメソッドがなかったらコンパイル時にエラーです コンパイル時にはstructural typeのような感じですが、本物のメソッド呼び出しに、コンパイル時に置き換えてるはずなので、実行時に余計なコストはかからないはずです*1 ところでScala 3側のbugなのかsbt側のbugなのか、仕様なのかわからないけど、これ全部いっしょにコンパイルすると(typeCheckErrorsなど使うと？) 変なエラーが出るので、いい感じに分けてコンパイルするかなにか工夫をしないといけなかった、面倒・・・。 gist.github.com *1:もちろん型クラスの
sbt 1.4からのpipeline機能を試したら3割compile時間短縮された - xuwei-k's blog
3割というのは、もちろんprojectの構成だったり、計測方法やその他色々によるわけですが、とにかく自分が計測した場合には3割短縮されました。114秒が80秒になりました。 pipeline機能自体の説明は最後に書きます。先に、測定方法や具体的な結果。 測定方法 travis-ci上で、他の条件を同じにして clean update test:compile を(50分制約でtimeoutするまで)ひたすら繰り返して test:compile にかかった時間(sbtが [success] 表示する)を計測、集計する JVMの暖まりを考慮して 上記のサイクルを繰り返すにあたって、sbtは起動させたまま 最初は遅くなるので、ある程度遅かった最初の8つは除いて、それ以外で平均や中央値を計算 測定に使ったのは、このblog書いてる時点でのscalazの最新master branch(7.4.x用)
DottyのMatch Typeを使ってコンパイル時にFibonacciを計算する - xuwei-k's blog
見た目通りで、あまり難しくないので、特に説明することがない。 macroさえ使わずに書けますね。 shapelessにあったような色々な機能が標準で装備されています。 みなさん、Match Type使ってもっと複雑な色々な計算書いてみましょう。 ちなみに、この単純な実装だと、大きい数渡すと(コンパイル時に)大変なことになるのでご注意ください。 plugins.sbt addSbtPlugin("ch.epfl.lamp" % "sbt-dotty" % "0.4.1") build.sbt scalaVersion := "0.26.0-RC1" Main.scala package example import scala.compiletime.ops.int.{-, +} import scala.compiletime.testing.{typeChecks, typeCheckE
Scala 2.13で-Xsource:3を指定すると変更される挙動一覧 - xuwei-k's blog
Scalaコンパイラには、ある程度最近のversionから -Xsource:バージョン という、少し将来のversionの挙動に近づけるオプションがあります。 Scala 2.13.3時点で -Xsource:3 を指定できるわけですが、その場合の挙動の変更一覧を、scala/scalaをgit grepしてコンパイラのコードを読んで調べたので書いておきます。 ちなみに、当初2.14が出る予定だったので、Scala 2.13の最初の方は -Xsource:2.14 という指定方法だったのですが、2.14無くなったので、dottyに向けて -Xsource:3 となりました。 Symbolリテラルが警告ではなくエラー https://github.com/scala/scala/blob/v2.13.3/src/compiler/scala/tools/nsc/ast/parser/Par
JDK11でGraalを有効にするとScalaのコンパイルが13%くらい速くなった - xuwei-k's blog
Graalについて全然詳しくないので、Graal自体の説明はしません、というかできませんが、JDK10以降で -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler というオプションを付与すると有効にできるらしいですね。 というわけで、以下のような条件で計測した結果、結果からいうと13%くらい速く(コンパイル時間が短く)なりました。 scalazの現状の最新masterで計測 https://github.com/scalaz/scalaz/tree/9369d23137d29c1490ccb72a83c8f76dc873285a 他の条件を基本的に同じにして、travis-ci上で適当に10回くらいclean update compileをsbtを起動したまま繰り返し実行して、sbtが表示したcompileの部分の時間計測 他の条件が
sbtにおけるテストの並列実行の設定詳細解説 - xuwei-k's blog
いきなり本題というか、一番言いたいことを書くと、まず テストの fork の設定によってぜんぜん違う。 という点があまり知られていない気がします。 *1 というか、自分も今回調べるまで、微妙に古い知識のままで完璧に知らなかったので、今一度理解した現時点での詳細を今書いています。 sbtにおいて、テストがどう並列化されるか？に関して、関係するというか、今回話すのは、以下の点です Test / parallelExecutionというkey Test / fork が true か falseか concurrentRestrictionsというkey testForkedParallelというkey また、今から話すのはsbt 1.3.8時点の情報です。 さらに前提として、マシンのCPUのコア数によって挙動が異なる可能性がありますが、ひとまずそれなりに十分にコア数がある、として話を進めます。
ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 - xuwei-k's blog
組み合わせるとはつまりアレのことを書くのですが、一応それほど前提知識無くても理解できるように書いてみます。さて、なぜいきなりEitherとFutureか？というと play2とか使ってると、Futureがよく出てくる Futureをそこら中でAwaitしたらFuture使う意味がないので、Future[A]をmapやflatMapなどでどんどん連鎖させて、メソッドの型にFutureが大量に出現！ Futureは非同期に行われる処理であり、そこで例外発生したら、その中に例外を含むしかない(単純に例外投げるわけにはいかないというか不可能) Scala標準ライブラリのFutureは、Throwable型で例外を保持できるようになってる 逆にいうと、Throwableでしか保持できない 例外の種類が多くなってきて、プログラムが複雑になった場合、Throwableではなくもっと限定された独自のエラー
時代はリテラルレベルプログラミングだ！ - xuwei-k's blog
リテラルレベルプログラミングという用語が存在するのかは知りませんが、べつに厳密に定義せずなんとなく使います。まぁこれ https://github.com/okomok/lity の説明が "Exploring literal-level metaprogramming" なので、そこから拝借という感じですかね。 さて、scalaでは、StringやIntのリテラルでfinal valで定義すると、型自体が特別扱いされる(?)という、知られざる仕様があります。まずは以下のgist御覧ください finalを付けずに val a = "a" だと型は a: String = a なのに対して、final valにすると b: String("b") = b というよくわからない型になってますね。そして def foo(c: b.type) と定義すると、foo("bar")と渡すとコンパイルエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
