Bazel でも GHC 9.2.1 でビルドがしたい
本記事は 「Haskell Advent Calendar 2021」の4日目の記事です。 空いてたので埋めました。 Bazelというビルドツールがあります。Bazelでは、いわゆるライブラリのようなものを使うことで、簡単にさまざまなプログラムのビルドやテストの実行を同じインターフェースで行うことができます。例えば： bazelbuild/rules_go : Goプログラムのビルドやテストなど bazelbuild/rules_docker : Dockerイメージのビルドやプッシュなど bazelbuild/rules_nodejs : Nodeプログラムのビルドやテストなど そして、tweag/rules_haskell を使うことで、Bazel を利用して Haskell プログラムのビルドが行えます。今回は今年でた新しいバージョンの Haskell 処理系、GHC 9.2.1 を
Bazel で生成したファイルを Haskell から参照する
前に Elm のコードを Bazel でビルドするためのルールを作りました． この生成物を Bazel でビルドしてる Haskell アプリケーションから参照する方法のメモ書きです． Bazel生成物を参照する方法 思い付いた方法は2つ： Bazel で Docker イメージを作るときに含めて動的に参照する Bazel で Haskell をビルドするときに埋め込む（Template Haskell） 前者は Docker で固めるだけなので，Haskell 側で特別なことをする必要がなく簡単． 後者は rules_haskell と Haskell 側で試行錯誤する必要があるが，Haskell アプリケーション単体で完結するので便利だ． Docker イメージに含める Bazel を利用して Docker イメージを作る場合は次のように書く： pkg_tar( name = "bin
外部ツールのバージョンアップを GitHub Actions で検知する
GitHub Actions のアクションや Bazel ルールを書いたりすると，外部のアプリケーションのアップデートを検知したいときがしばしばあります． いろいろ試行錯誤した結果，GitHub Actions を使って実現することにしたので，本記事はそのメモ書きです． ちなみに，本記事は「GitHub Actions Advent Calendar 2020」の14日目の記事です． GitHub Actions を設定する 実際に導入した PR がこちら： Add GitHub Action to check new yq version by matsubara0507 · Pull Request #1 · matsubara0507/rules_yq yq と言うツールのリリースを検知しようとしている． ちなみに，最新のバージョンは中の処理のデフォルト値として利用している． デフォ
Haskell Stack プロジェクトを Bazel でビルドしてみる
仕事では Bazel を使ってビルドすることが多くなり，自分でも Bazel ルールを自作するようになったので，実験も兼ねて趣味の Haskell Stack プロジェクトを Bazel を使ってビルドしてみることにしました． 本記事はそのメモ書きです． あとこれは Haskell Advent Calendar 2020 の2日目の記事です． Bazel Bazel は Google のエンジニアが中心になって開発している OSS のビルドツールだ． 以下のような特徴がある： 必要なコマンドのインストール・バイナリのビルド・コマンドの実行などを記述できる それらは全て専用のサンドボックス内で実行されるため再現性が高い Starlark という Python 風な独自言語で記述する キャッシュなどが工夫されており二度目以降のビルドが高速になりやすい 依存関係を明確に記述する必要がある また
Hamler の Docker イメージを作る（その２）
なんと「Hamler の Docker イメージを作る」の第2段です． 現在，Hamler は活発に開発が進んでるのですが，そのたびに前回の方法でビルドしていると時間がかかりすぎるので新しい方法を考えたという話です． ちなみに，Hamler 側で公式の Docker イメージが提供されるようになりました． しかし，あまりタグがうたれません． 今回の方法は任意のリビジョンで簡単に自前ビルドできるので，最新のリビジョンやフォークを試すのに非常に便利です． Docker イメージを作る 今回やりたいのは最新のリビジョン（masterブランチ）で素早くイメージを作り直すこと． しかし，Docker 内で master を Haskell Stack でフルビルドし直すのはヒジョーに時間がかかる． そこで Haskell Stack の Docker 機能を使って，ローカルのキャッシュをうまく利用で
Featherweight Go を読んでみた
Go言語にジェネリクスを導入するために，その形式的な議論を研究した論文「Featherweight Go」が6月頭に発表されました． せっかくなので（久々に）全訳をしながら丁寧に読んでみたので，それを簡単にまとめることにします． 可能な限りGo言語に馴染みのない人や，プログラミング言語の形式的な議論に馴染みのない人でも理解できるようにしてみます． 注意 僕は英語がとても苦手です（DeepLを駆使しても3週間かかりました） 僕はGoでアプリケーションを少し書いていますがコアについては全く詳しくありません 僕は言語の形式的な議論を院生時代にやってましたが卒業して数年経ちます なので間違ってる可能性も十分に考慮してください． TL;DR Goにジェネリクスを導入する新しいデザインを提案： インターフェースと型アサーションを駆使する方法 新デザインを形式的に議論するために FG と FGG を定義
Hamler の Docker イメージを作る
Hamler という ErlangVM 上で動作する Haskell に似た構文のプログラミング言語が公開された． 手元で遊ぶためにまず，Docker イメージを作ってみることにした（brew したくなかった）． 作成したイメージはココでリポジトリはココ． ちなみに，今回利用するバージョンは 0.1 です． Docker イメージを作る 公式の Erlang の Docker イメージは Debian なので，Debian の Docker イメージを作る． 現状は Mac 用のバイナリしか提供されていないので自前でビルドする必要がある． 自前でビルドする方法は公式ドキュメントによると次の通り： Erlang インストール Haskell Stack をインストール hamler-lang/hamler リポジトリをクローン リポジトリで make && make install 幸いにも
Elm で作る TaPL のラムダ計算（その１）
本記事は「Elm Advent Calendar 2019」の6日目の記事です． 表題の通り，TaPL という書籍で紹介されているプログラミング言語の実装例を Elm でやってみたという話です（その１）． TaPL とプログラミング言語の実装 「Type and Programming Language」(翻訳本は「型システム入門 -プログラミング言語と型の理論-」というもの，以下 TaPL)という書籍を知ってますか？ この書籍はプログラミング言語の型システムの理論体系に関するとても有名な書籍だ（学術的なその分野における入門書）． TaPL の多くは数理論理学的な議論や証明で構成されているのだが，いくつかの章では簡易的なプログラミング言語の実装がある: 第4章 算術式のML実装 (本記事はココ) 自然数と真偽値と if-then-else 変数などもない 第7章 ラムダ計算のML実装 型
Haskell で GitHub Actions する
本記事は「Haskell Advent Calendar 2019」の2日目の記事です． 2019/11/13 に GA された GitHub Actions を使って，Haskell プロジェクト，とりわけ Haskell Stack を使ったプロジェクトを CI/CD します． ちなみに，試すために導入した PR はこれです: 自動ビルドを追加 by matsubara0507 · Pull Request #1 · matsubara0507/octbook これは適当な設定ファイルから GitHub の Organization や Organization の Team 機能にユーザーを招待したりキックしたりするための CLI ツールです． Cabal の場合 はわりかし簡単． Haskell のセットアップは公式がすでに用意してくれてるのでこれを使えば良い: actions/s
rio + extensible なフレームワーク: mix
最近はよく rio + extensible で Haskell アプリケーションを書きます(趣味の)． 前々から何となくパターン化できそうだなぁと思っていたのが，それをついにパターン化し mix パッケージとして形にしましたというお話です． ちなみに，それぞれのパッケージを軽く説明すると: rio : Haskell のビルドツール Stack を開発しているチームが作っている Reader パターンをベースにした Alt. Prelude extensible : 拡張可能レコードを始めとして様々な拡張可能なデータ構造を同一の形式で利用できるようになるパッケージ mix パッケージ リポジトリはこれ: mix パッケージの目的は rio パッケージの RIO env a モナドの env の部分を extensible パッケージを用いて簡単に構築することであり，env をプラグインと
GitHub Card を生成する SPA を Elm で作った
Qiita や自分のブログに GitHub のリポジトリのリンク貼ってもなんか寂しいからいい感じのカードっぽいやつ生成するやつを作ったって話です． iframe で埋め込むことができます。 だがしかし！Qiita などに任意の iframe が埋め込めるわけないジャーーーン！ ということに，だいたい完成してから気づいた orz GitHub Card 特別定義はないけど，こんな感じのを iframe で作りたかった． 作る マイフェィバリット JS 系プログラミング言語 Elm を使った． だいたい半日ぐらいかかった．GWの最終日．GW最高． リポジトリはこれ: GitHub Pages に置いたので誰でも試せる． ただし，裏では GitHub API v3 をトークンなしで叩いてる... こんな感じになる: 上がユーザーのカードで下がリポジトリのカード． Embed: の下に書いてある
Re: Marp のすゝめ
(どうでも良いですが，モノリポにした方良かったと思う... Marpit で更新があると全てのリポジトリで PR を出して更新する必要があるので...) ちなみに，旧 Marp のリポジトリの Issue ラベルに Marp Next や Supports in Marp Next というのができている． 旧 Marp の Issue には，かなり要望っぽい Issue がたくさんあり，その中でも Marp Next では対応する予定のものには Support in Marp Next を付けたようだ． 旧 Marp との非互換な機能 これらは旧 Marp ユーザーしか意味ないが，適当に書き連ねていおく: ==AAA== というハイライト機能がない（辛い） 打ち消し線記法 ~~AAA~~ もない 画像の拡縮ルール (Marpit) より細かいルールができて書きやすくなった しかし前のは記法
GHC 8.x 勉強会に行ってきた
本記事は Haskell (その2) Advent Calendar 2018 の18日目の記事です． 空いていたのでついでに埋めました． 12/7 の10-17時半ぐらいに IIJ-II で GHC8 系のバージョンアップを追う会的なイベントが企画されました． このイベントは IIJ-II の Haskell チームで発案・企画し，Haskell-jp の Slack で募集をかけていました． 定員12人かつ，平日昼間でしたが，面白そうなので有給とって行ってきた(僕は IIJ-II では無いので)． 多少クローズドな会ということもあり，せっかくなので色々と議論したことを記事に起こしておきます． 正確な情報は GHC のドキュメントを呼んでください． 進め方 GHCにはこんな感じのリリースノートがある． 当日は8系のリリースノートのハイライトを追っていくという感じだった． 事前に一人一つぐ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Haskell Morpheus GraphQL で GitHub API を試す
hpack の設定から Bazel の設定を自動生成するツール Hazell を作った
Haskell Servant で Slack からの署名付きリクエストを受ける
Haskell Servant に GitHub Apps による認証を追加する
Haskell で SSH Public Key の FingerPrint を計算する
CI で Haskell Stack の Docker Integration するために
stack image コマンドなしに Haskell アプリの Docker イメージを作る