とにかく以下のコード御覧ください。 Scala2.11や2.12だと通るけど、2.10だと通らないっぽい。Javaは通ります。 ただそれだけです。 これに関するScala本体のコミットとかissue番号は調べられてないです。誰か知ってたら教えて下さい。 いや、べつにデグレったわけではなく改善されてる系なので、必ずしも知らなくていいんですが、興味本位で 追記: 思いの外twitter上で反応あったので、貼っておきます .@nagise @matarillo ちなみに発覚元(?)の実コードですURLURL 2015-12-08 20:42:30 via Twitter Web Client to @nagise https://github.com/grpc/grpc-java/blob/v0.9.0/core/src/main/java/io/grpc/ServerBuilder.java#

まずsbt-unidoc https://github.com/sbt/sbt-unidoc というsbt pluginの簡単な説明。(以下の説明は、現時点で最新の0.3.0という前提です) sbtでサブモジュールを分けた場合、標準ではそれぞれ個別のScaladocしか作れない sbt-unidocは、すべてのモジュールをまとめたScaladocを作るためのplugin で、sbt-unidocの最低限の使い方としては、READMEの通りに 1. plugin.sbtにaddSbtPluginで依存加える 2. rootのプロジェクトの設定に unidocSettings を追加*1 して、"unidoc" と打つだけで、全部がまとまったScaladocが生成されます。その他色々機能があるので、あとはREADME読んでください。 さて、unidoc生成しても、それをどこかに置かないと意味が

発端は一応自分の発言だと勝手に思ってますが(?)、実際ことを進めてくれたのはeed3si9nさん。 そして全部の権限もらったぞ、これでまたgithubのorganizationの所属数や「〇〇のメンテナーです(๑•̀ㅂ•́)و✧」 と言えるリストが増えましたね！ (そういう問題ではない) ひとまずtarvis設定したり、通らないテスト通るようにしたり、依存上げたり、mergeできそうなpull req mergeしたり、などをやり始めました。 なんでも頑張り過ぎると続かないので、メンテコストが極力下がるようにしつつ頑張れる範囲で頑張っていきたい。 (個人的に、細々とでもいいから、利用者がいるなら長く続けることを重要視していきたいとこれに限らず常々思っている) n8hanさん明らかに最近OSS活動してないので、必要なもの引き取るなりコミッターになるなりforkするなりする必要は感じている。i

showのほうは2.11.0から(?)あって、printは2.11.8から Neat trick I just discovered: add `// show` in the Scala REPL to see the actual code that gets compiled. 2016-03-30 23:19:15 via Twitter for Mac @jaguarul starting 2.11.8, add `// print` and hit tab, it will show the de-sugared version of your code (without the REPL's wrappers) 2016-03-31 00:38:16 via Twitter Web Client to @jaguarul scala -Xprint:typer などとすれば、

個人的な感覚として大きい転職事案がいくつかあったので書く Travis Brownさんがtwitterやめた https://github.com/travisbrown https://meta.plasm.us/posts/2015/10/13/goodbye-twitter/ 2015-10-13 twitterでfinagleとかfinchとかのOSSやってた人 猫のコミッター shapelessにも原作者並にかなり詳しい Scalaのマクロにもコミッター並にかなり詳しい stackoverflowで誰よりもscalazのとかの質門に答えてる人 最近argonautをforkして色々改善したイケイケな(?)Jsonライブラリ作り始めてる https://github.com/travisbrown/circe twitterのレイオフのタイミングと完全に一致してたので、たぶんそうい

どーも。Scala祭実行委員なのか、実行委員ではないのか、よくわからない立場な人です。 個人的な事情を書いておくと、去年手伝った関係上、今年も一応実行委員のチャットなどには入ってるけど、あまり手伝えてないので、心苦しいのと実行委員の仕事やらないといけない責任から逃れるため(?)と、もう結局あとから多少手伝うことになったとしても個人スポンサー的な意味合いを込めて、普通にチケット買いました。 というわけで、実行委員の立場というよりは、これは一個人として勝手に書いてます。 さてそれはどうでもいいとして、皆さんご存じの通り？今年のScala祭は、招待枠は全くなしでCFPで投票する感じになりました。詳細は以下 「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立 - ScalaMatsuri運営ブログ] というわけで、これ書いてる時点では、CFP締め切られ、投票開始にむけて絶賛準備

よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー

Scalaの勉強会で半分くらいHaskellの話してすいませんでした。 http://xuwei-k.github.io/slides/scalaprops/ http://connpass.com/event/16052/ http://togetter.com/li/852254 資料はりきって頑張り過ぎたらとても長くなりました(150ページ超えた) 今までで一番頑張ったかもしれません。ここ半年くらいの成果を全部詰め込んだ感じです。 あとで資料として読んで理解してもらうこと前提で色々詰め込んだので、1年後でも2年後でも、興味のある人が見て有用な資料になればいいですね・・・。 ところで、スライド作るのに、今回から remark というやつ使いました https://github.com/gnab/remark markdownで書けて コードのシンタックスハイライト効いて ページ数表示と

"新しい" とは、今まで全部無名classにコンパイルしてたラムダを、invoke dynamic使って動的に生成するようになるとかそういうやつ。 ラムダ以外の最適化もやってるようですが？詳しくは知りません。 Scala 2.12から正式に入るらしいですが、(これ書いてる時点から見て)つい昨日くらい(2015/06/25)に出たScala2.11.7でも、明示的にオプションを指定すれば、実験的オプションとしてですが、使えるそうです。 内部の仕組みは、以下のScaladays2015のスライド見るとか、あとは各自ググってください http://downloads.typesafe.com/website/presentations/ScalaDaysSF2015/T2_Rytz_Backend_Optimizer.pdf 公式に書いてありますが、2.11.7においてJava8のバックエンドを

http://scastie.org/ https://github.com/OlegYch/scastie ずっと前からあるし、知っていたけど、なぜかblogに紹介書いたことなかった気がするので書いておく。 任意のsbtの設定書ける(ライブラリの依存追加や、scalaのversionも自由に変えられる)という意味では、ほかのやつよりも、(少なくともこれ書いてる時点で)一番便利なはず

わざと両方のタイトルをblogのタイトルに入れてみました(ながい・・・) レビューに少しだけ関わりました。自分が翻訳したわけではありません。あくまでもレビューです 原著 Functional Programming in Scala Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイド (impress top gear) 作者: Paul Chiusano,Rúnar Bjarnason,株式会社クイープ出版社/メーカー: インプレス発売日: 2015/03/20メディア: 単行本（ソフトカバー）この商品を含むブログ (7件) を見る http://book.impress.co.jp/books/1114101091 作者達はおそらく訳されて今の時期にでることをあまり知らない？だろうから、知らせるのと感謝の意を伝えるtweet↓(そしてサンプ

Scalaのversionは2.10.4です。 とあるprivateなフィールドをobject内に定義 ライブラリをリリース それをpublicにしようとする mimaに怒られる（´・ω・｀） 実は内部的にはコンパニオン同士でアクセスするためのメソッドが自動生成されてるから、そのメソッドを消すことになりバイナリ互換が崩れる！！！ バイナリ互換のためには、privateではなくprivate[this]を使ったほうがいいのか？ という知見を得た。(またscalikejdbcやってる最中に) まぁ崩れるけど、その自動生成メソッドを(javaから？)無理やり呼び出したりしない限り大丈夫？なので、もう少しmimaが賢くなるか、設定方法が柔軟になっていて欲しい気もする。 つらい・・・。

これは、ドワンゴ Advent Calendar の 7日目です。 6日目は DartのASTを触ってみる でした。 さて、会社でアドベントカレンダーやる、と言われて、なんとなく参加登録したはいいものの、特に書くこと決めてませんでした。 最近、msgpackのScalaのライブラリ作ってるので、それ完成したらそのこと書こうかな―、と思ってましたが、msgpack-javaのバグや、古いversionと新しいversionの違いと戦ってたりしたら、なかなか完成しないので別のこと書くことにしました。 というわけで、標題の 「代数的データ型とshapelessのマクロによる型クラスのインスタンスの自動導出」 という話をします。ドワンゴアドベントカレンダーだからといて、べつに変わったことはなく、いつものようなScalaネタです。 さてみなさん「代数的データ型」って知ってますか？Scalaよりもっと

github時代にコミッターという言い方は(以下略 新年早々めでたい。 しかし、sbtに比べて、Scalazのときはコミッターになる前でもだいぶ貢献してたから、Scalazのコミッターになったときは確かに驚いたけどある意味納得だったですが、sbtは現時点(2014年1月7日)で7commitで12位 https://github.com/sbt/sbt/graphs/contributors という程度でコミッターになっていいのでしょうか・・・という戸惑い。この前 sbtの密結合な内部アーキテクチャ という記事を書きましたが、あれはほんの一部で、まだまだsbtは奥が深く把握できていないこと大量にあるので、コミッターになって貢献できる部分がどれほどあるのか謎ですが、まぁ出来る限り頑張ります・・・。 Scalazよりsbtのほうがユーザー多いし、まだまだ進化する余地がいくらでもある(?)ので*

SetがFunctorではない理由を延々と説明します。最初これ http://failex.blogspot.jp/2013/06/fake-theorems-for-free.html を訳そうとしましたが、英語力と理解力のなさにより断念し、中途半端な翻訳になるなら、自分なりに書き下そうという結論になりました。内容は上記の記事と半分以上被ると思います。あと、上記の記事書いた人は「Scalazのコミッターであり、おそらくekmettの同僚であり、ermine-languageのコミッター」な人です。よってオススメなので、そっちも読みましょう。*1 以下、Scala以外の言語でも大概は当てはまると思いますが、一応Scala(というか、Scalaz)を念頭において書いていきます。 さて、プログラミングにおいて、Setとは一体何でしょうか？ とりあえず「要素の重複を持たないデータ構造」といえるで

これも、見つからなくてこまってる人を度々見かけるので。ここ↓にあります https://github.com/scala/scala-tool-support *1 version 2.9.2 くらいから(?) Sbazが消えて、このあたりのファイルも添付されなくなったんでしょうか?(詳しい経緯とか知らない)ファイルはここにあるけれど、自分も現在、これらのファイルの推奨のインストール方法(といっても、大概コピーしてきて所定の場所に置くだけでしょうけれども)知らないので、誰か詳しい事情しってたら教えて下さい・・・(´・ω・｀) あと別に、これらのファイルはそれほど頻繁に更新されてるわけでもないし、*2 2.9.1以前に添付されている古いScalaのディレクトリから引っ張ってきても、ほとんど同じものだと思うので、もし古いScalaがあるならばそこから引っ張ってきてもいいと思います *1:以前は

つまりなぜかいきなり高階型の話です。 これ 関数を扱えることはどのようにプログラミング言語の能力をあげるか に対する便乗というかツッコミとして。 つい先日もある人がこんなこと https://twitter.com/koropicot/status/365014333413011457 を言っていて*1、「ですよねー」と勝手に納得していたりしましたが。 つまりScalazでよくみるような高階型 trait Monad[F[_]] extends Applicative[F] { implicit val listMonad = new Monad[List]{ がないと、モナドとして抽象化や共通化ができない、という話です。*2 高階型についてはたとえばこれ (もりそば)Scalaによる高階型変数 - Higher-kind Generics とか読んでください。 関数がオブジェクトとして扱

列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか？」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。本当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の