サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
xuwei-k.hatenablog.com
以下の続き。 前回書いてから、かなり増えて、もう少しで100個超えそう。 xuwei-k.hatenablog.com xuwei-k.hatenablog.com 以前書いた時から、これ書いている2024年3月時点のversion 0.4.1までに増えたものを全部簡単に説明書く。 あと、少なくとも今回説明は書かないですが、以前までに作ったruleに関しても細かい改善などもしてます。 https://github.com/xuwei-k/scalafix-rules/tree/98f97c6e01723a671a8b722c7fe5f88cfc9623f2 CompareSameValue a1.b == a1.b というように、見た目明らかに同じTree同士を比較していたら警告する。 a1.b == a2.b みたいに書きたかったのにコピペミス、みたいなことが稀に発生したので。 Disc
IDEAのterminal(sbt pluginではない)、からsbtを起動してcompileなどすると、errorやwarning出た場合にそのpathがclick可能で、そうすると該当のsource codeに飛べて便利だったのだけど、いつの間にか不可能になってるんだけど、これどこかに設定あるのか、version上がって何故か不可能になったのか— Kenji Yoshida (@xuwei_k) 2024年1月31日 記憶違いなのか、IDEAのversionか設定で変わって出来なくなったのか、本当に謎なんですが、大量の警告やエラー直す場合に、これの有無でけっこう生産性が変わるので。 「sbt pluginではない」というのは、IDEA関係ない普通のsbt pluginとしてではないし、IDEA自体のsbtやScala pluginも関係ない、という話です。 「IDEA自体のsbtやSc
qiita.com これは Scala Advent Calendar 2023 の16日目です。 (あとから見たらこの日付が抜けていたので、あとから登録して埋めました) これ書いている2023年12月現在、(RCなどの安定版以外も含めると) 3.4.0-RC1が最新で、3.4.0のfinalは出ていませんが、3.4.0から色々と変更点があるみたいなので、3.4.0-RC1時点の情報をざっくりまとめます。 あくまで自分が遭遇した、あるいはざっくりリリースノート見て書き出しただけなので、他にも大量にありそうですが、ひとまずこの程度にしておきます。 https://github.com/lampepfl/dotty/releases/tag/3.4.0-RC1 各種書き換えは、scalafmtの設定だけで可能な場合もあるし、scalafixでやった方がいいパターンもあり得るかもしれないし、ある
Twitterでは多少Tweetしてたのですが、やっとある程度形になったので、リリースしました。 以下、簡単な説明や、関連する余談など書いておきます https://github.com/sbt-teavm/sbt-teavm TeaVMとは 原理上、Java含めた任意のJVMのbytecodeからWebAssembly, JavaScriptなどに変換してくれるもの ASMで変換する系なので、Javaに限らず、ScalaでもKotlinでも(原理上は)いける 実際公式にもScalaのサンプルがある つまり依存ライブラリがscala-jsやscala-nativeのように専用にpublishされていなくてもbuild可能(build出来ても実際にどの程度動くか?は別問題) ただし、scala-jsやscala-nativeと同様に、Javaの標準のAPIで再実装されていないものは動かない制
GitHubのヘビーユーザーだと一部は当たり前だったり、細かい部分は個性や好みが出たり、GitHubは割と頻繁に細かい新機能が追加されるので意外と知られていないものがあったり、などなどあると思いますが、現状の自分がよく行っている設定を、何かの参考になればと思って雑多に列挙しておきます。 自分がGitHubで活動してるrepoの大半はScala関連なので、Scala特有の色々(scala-stewardなど含む)も、書こうと思えば大量にあるけれど、ひとまずScalaにほぼ関係ない、一般的なGitHubの使い方に関する部分だけ今回は書きました。 (気が向いたらScala特有のアレコレを別途書く・・・?) 列挙の順番には特に意味はないです。 列挙してないものでも場合によっては設定しているものや、書き忘れているものがあるかもしれませんが、とりあえず簡単に思いついたものだけ。 機能としては知っていて
ScalaMatsuri 2023のdiscordの会話を雑に勝手に転載しておくだけのblog。 一番高度というか面白い話でメモしておきたかったので。 We've looked into it! The way this would work, more than likely, is the implementation of Fiber for IO would check to see if VirtualThread is available, and if so, an alternative implementation would be instantiated any time you call .start. However, there are some serious limitations which arise. For starters, Cats Effect
数ヶ月前に、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.
すごく重要な予定が色々と決まりつつあるので、独断で勝手に?雑に?選んで紹介しておきます。 単なる翻訳というよりは、自分の感想や主観みたいなものが入ってます。 詳細な原文を知りたい人は、以下のあたりを読んでください https://github.com/playframework/playframework/blob/80da98b0352e1d3e7e1ba034ec9c5e4c15e1cb3e/documentation/manual/General.md https://github.com/playframework/playframework/blob/80da98b0352e1d3e7e1ba034ec9c5e4c15e1cb3e/documentation/manual/releases/release29/migration29/Migration29.md https://
switch式の結果javapしたらhttps://t.co/xMc0YEYsrg java.lang.runtime.SwitchBootstraps と tableswitch が使われることに気がついたが、これ巨大なswitch式をJDK 21以降で書いた場合、同等の巨大なmatch式をScalaで書くよりも速度が速い可能性があるのでは??? これScalaで活用できるか?というと— Kenji Yoshida (@xuwei_k) September 25, 2023 switch式の結果javapしたら https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/runtime/SwitchBootstraps.html java.lang.runtime.SwitchBootstraps と ta
ScalaでもJavaでも、overrideする際に、sub typeでoverrideすることが可能です。 (すごく古い1.4以前のJavaでは不可能だったはずだが) Javaの仕様書で英語だと covariant return type というはず?の機能です。 https://docs.oracle.com/javase/specs/jls/se11/html/jls-8.html#d5e14373 $ jshell | Welcome to JShell -- Version 17.0.6 | For an introduction type: /help intro jshell> interface A { Object a(); } | created interface A jshell> class B implements A { @Override public St
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でおこなったら、当然以下のように
他人が作ったものを紹介するだけの記事。 以下のtweetで大体は言い尽くしてあるのですが、これはとても良さがあるので、あえて、ほぼtweet貼り付けるだけの記事書いておくことにしました。 github.com warn GitHub Actionsはログを出すときに特定の形式で出すと、errorやwarnを認識して、あとでまとめて表示してくれる機能があります。 しかし、pluginを何も使わない状態の現状のsbt 1.8.2時点のデフォルトでは、そういった機能が一切いかせません。 この sbt-hackers-digest のblog書いた時点の最新の 0.1.0 では、 project/plugins.sbt などに一行追加するだけで、以下に貼ったようにいい感じになるっぽいです。 addSbtPlugin("net.virtual-void" % "sbt-hackers-digest"
https://github.com/xuwei-k/scalameta-ast https://xuwei-k.github.io/scalameta-ast/ 経緯などの説明 scalameta公式サイトから、これ https://scalameta.org/docs/trees/astexplorer.html のリンクがある scalafix書く時にはほぼ毎回使っているが不満がある versionが古い たまに出力されるASTが最新と異なっていてハマる(例: AnonymousFunction) Scala 3未対応? 更新しようにも、npm版を参照しているが https://www.npmjs.com/package/scalameta-parsers それのpublishされ具合が謎(最新がない) 追記: https://twitter.com/tanishiking/stat
突然ですが、皆さん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
以前書いてから増えた分の解説。 xuwei-k.hatenablog.com 以前と同様、特に記述がないものは全部SyntacticRuleなので、100%正しく書き換えや警告出せる保証がないです。 AddLambdaParamParentheses Scala 3からlambdaの引数の括弧が実質必須になるので、括弧を付与する。 以前は警告するものだけ作ったが、書き換えも作った。 { a: Int => a + 2 } を { (a: Int) => a + 2 } CollectHead collect(f).head を collectFirst(f).get に書き換え CollectHeadOption collect(f).headOption を collectFirst(f) に書き換え FlatTraverse seq.traverse(f).map(_.flatten)
少しふざけたタイトルをつけましたが、以下、基本的に超真面目なマニアックな話をします。 Scala 3から、ある程度の定型的なtype classのinstance生成時に低レベルなmacroを書かずに便利に綺麗に書けるMirrorという仕組みが標準で追加されています。 docs.scala-lang.org https://github.com/lampepfl/dotty/blob/3.1.3-RC2/library/src/scala/deriving/Mirror.scala 雑に一言で説明すると、shapeless 2における Generic や LabelledGeneric に近いものが標準に入りました。 今回は、それ自体の紹介ではなく、タイトルに書いた通り、それの内部実装の話です。よってMirrorそのものの詳細な使い方や説明はしません。 また、versionはひとまずSca
speakerdeck.com 発表中にも言ったし、以前色々tweetしていたりもするんですが、本業での方が、コード量多かったり、時期がはやくてcompilerやlibraryが安定してなかったりで、色々辛かったりその分面白い話もあったんですが、とにかく具体的なそれなりな大規模な事例発表?ができたのは良かったですね。 本業と比較したら簡単だった(?)とはいえ、数十万行あるコードをScala 3でコンパイル通すだけで数週間かかったので、もっと慣れていない人が同規模のものを移行したら、まだ普通に数ヶ月以上かかると思った方がいいですかね? 🤔 質問されて答えたりしたけど、とにかくmacroとreflectionに互換がないので、Scala 3移行するつもりがあるならば、今のうちから、それらを使っていてScala 3対応がされなそうなlibraryは、絶対に避けましょう。 今後、個人的に、アルプ
概要や結論を先に書いておくと、適切にプロファイルを取って、適切にボトルネック箇所を見つけて対処しましょう。 という話になるのですが、大まかな概要というか、結果的に使った方法を書くと sbtのTask毎の時間を記録する機能を使う Scala 3 compilerのログを多めに出してphase毎の時間を出す Scala 3のcompiler pluginを書いて特に時間がかかっているファイルを見つけ出す 普通のinlineやsummonFromだけで書いていたものを、あえてQuotes使ったlow level macroに書き換えて、compile time debugする 遅い原因となったinstanceを半手動定義する といった感じです。タイトルに、 Scala 3 inline とありますが、一部はそれ以外のパターンでも使える、Scalaやsbtにおける、compile時間、build時
結論としては以下のissueに大体全部書いてあります。 Incremental compilation inside docker container broken since SBT 1.1.0 · Issue #4168 · sbt/sbt · GitHub 依存ライブラリのjarのキャッシュではなく、あくまでインクリメンタルコンパイラのキャッシュの話です。 簡単に現象をまとめると sbtのインクリメンタルコンパイラのキャッシュというのは、(当然?)ファイルに保存されている sbtはそのファイルの変更日時を見ている 新しめのsbtでは、そのファイルの変更日時はミリ秒の精度で付与される(秒精度だと過去に問題があった?ので、sbtがOSごとに違うコードを頑張って書いてわざわざそれやってる) しかし、CircleCIというか、それに限らずDocker環境などで、キャッシュを一時保存してもう一
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や評価機を書こう!!
アイデアというか初期実装は、1年近く前に遡るのですが、それをしっかり作り直して整理してリリースしました。 https://github.com/xuwei-k/unused-code まだまだ追加したい機能や改善点などありますが、初期versionでも、結構しっかり作ったつもりなので(?)割と既に実用的なはずなので、試してみてのフィードバックお待ちしています。 scalafixのSyntacticRuleで、project内でグローバルな未使用コード検出君(class, trait, object, method)を作っている。 大まかな原理として、すべてのNameを集計、保存しておいて、1箇所しか出現しないものを検出(多少その後特殊処理する)、という力技で、まぁまぁ実用的なものが出来つつある— Kenji Yoshida (@xuwei_k) March 18, 2021 主な使い方 R
本体にドキュメント書いてないので、とりあえず現時点のruleについてひたすら説明書いておきます https://github.com/xuwei-k/scalafix-rules AddExplicitImplicitTypes https://github.com/xuwei-k/scalafix-rules/blob/v0.1.3/rules/src/main/scala/fix/AddExplicitImplicitTypes.scala implicit val foo = new Foo を implicit val foo: Foo = new Foo に書き換え。そもそもscalafix本体にもっと高機能なものがあるが、そちらはSemanticRuleで重たいため、SyntacticRuleで可能なごく単純なものだけ型をつけるもの。 これに限らず、基本的にSemanticRu
というのを作った。 仕事で自分が関わっている特定のリポジトリでは、以前からそういうの作ってbotがpull reqに直接コメントするようにしている。(自分のものだけではなく、そのリポジトリのpull req全てに対して) そうではなく、自分が出したOSS含めた任意のpull reqでconflictしていたら通知欲しいので、作った。 https://github.com/xuwei-k/cron/commit/17c9c731593ce5de9178fabdb26c088631d74e74 通知先はとりあえずslackにしたが、ここはメールでもなんでも、好きものでいいと思う。 自分のJavaScriptの能力はゴミなので、明らかにリファクタ出来そうだけれど、とりあえず動いたので一旦妥協した。 改変して使う際は q のauthor部分は、直接埋め込んであるけれど、自分のgithubのidに変
ここでいう最新技術とは以下です。 JDK8や11よりも、17の方が速い? M1 Macが速い?(2021年最新のM1 Maxではなく、2020のMacbook Pro 13インチのM1です・・・。M1 Max欲しい!!! => 最後に追記したぞ) Scala 2より3の方が速い? 自分の最近の経験上、それらが速いはず?なので。 上記は、全部場合による(projectによる)かもしれないし、あまり変わらないパターンも含まれているかもしれませんが、とりあえず一部(Scala 2自体のcompile)を除いて、上記の条件でコンパイル速度を計測してみたら、 数年前の感覚と比較して結構速い感じがあったので、それの計測結果の共有です。 個々の条件をもっと細かく変えるのは、組合せ爆発して辛いので、誰か気になった人はやってみてください。 何年も前と比べるとsbtでの依存解決もだいぶはやくなったし、ビルド速
まずは以下をご覧ください github.com 以下のようなcase classがあったときにAのコンパニオンのunapplyは、それぞれ存在するが、戻り値型が異なっており case class A(x: Int, y: String) Scala 2: Option[(Int, String)] がかえる Scala 3: A がそのままかえる という違いがあります。 この違いは、case classのapplyやunapplyを(明示的に)渡して型クラスのインスタンスを生成するようなライブラリその他(例えば各種jsonのライブラリ、slickの <> でのマッピングなど)で、面倒なことになります。 ライブラリ側が対応してくれればいいけれど、それもどうなるのかわからない Scala 3では Tuple.fromProductTyped でTupleには変換できるが、それの存在だけではだめ
仕事でsbtのsub projectが100個以上あるので、こういう指定だけでもダルいので sbtでallで複数projectのtask指定する際に少し簡単に指定出来るcommand(tab補完付)を作ったhttps://t.co/lUzkZ47elw taskAll "任意のtask" "project idの正規表現のリスト" 例: taskAll compile core ↓ all coreJVM/compile coreJS/compile taskAll test .*JVM ↓ all fooJVM/test barJVM/test— Kenji Yoshida (@xuwei_k) 2021年7月30日 tab補完付 gist.github.com tab補完なし gist.github.com
というのがおそらく作成できたけれど、もっと書き方改善可能なところあったら教えて下さい。 このくらいすでに、Scala 3でも前例が存在する気もするけど、とりあえず(あまり前例は調査はせずに)自作しました。 テスト書いてあるとおり、指定されたcloseメソッドがなかったらコンパイル時にエラーです コンパイル時にはstructural typeのような感じですが、本物のメソッド呼び出しに、コンパイル時に置き換えてるはずなので、実行時に余計なコストはかからないはずです*1 ところでScala 3側のbugなのかsbt側のbugなのか、仕様なのかわからないけど、これ全部いっしょにコンパイルすると(typeCheckErrorsなど使うと?) 変なエラーが出るので、いい感じに分けてコンパイルするかなにか工夫をしないといけなかった、面倒・・・。 gist.github.com *1:もちろん型クラスの
結論: Scala 3.0.0はScala 2.13.5の半分以下(4割)の時間でコンパイル終わる!!! (scalazでのベンチマーク) 半年前のDotty 0.27の時点でやった方法とだいたい同じ方法で計測し直した結果です。 scalazの最新のjvmのmain側を使用 (ほんの少しversionごとに違うコードはあるが、せいぜい数%程度しかないはず?) https://github.com/scalaz/scalaz/tree/4321237a782155926f9c3e91e7ca44454bba80ef clean update compileをひたすら繰り返したときのcompileの [success] の表示部分を集計 40回繰り返し実行して、JVMの温まりを考慮して、最初の10回を除いた30回を集計 2.13.5 (最初の10回除いた)30回分の平均: 65.9秒 (最初の
https://gist.github.com/xuwei-k/3fd8d9bdc9ecde473244de40da2fecf0 gist.github.com
次のページ
このページを最初にブックマークしてみませんか?
『xuwei-k's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く