shibuya.d #2 開催しました

12/15(木)に開催しました。参加いただいた皆様、ありがとうございました。

connpass.com

当日の様子はTogetterでまとめています。ツイートの利用問題ありましたら誰でも編集可能にしているので削除お願いします。

ツイートを使わせていただきました。誰でも編集可にしてるので問題あれば消してください。 https://t.co/tSwgLrcFA2 #shibuyad

— 黄前久美子さんと高坂麗奈さんの距離感 (@shitsyndrome) 2016年12月15日

だいたいツイートをみれば雰囲気がわかると思うので、当日話さなかった話を書きます。

shibuya.dの立ち位置

shibuya.dという勉強会は土地名を冠していますが、そういうD言語コミニュティがあるわけではなく特定の個人の思いつきで不定期にやってる集まりです。ときどき「Ustとかで配信してほしい」という要望を地方在住の方からいただくことがあります。こんな小さな勉強会で「観たい！」と思ってもらえることはとても嬉しく感じるのですが、個人が思いつきやっている活動なので限界があります。

勉強会を主催・準備するのはけっこう大変な作業です。会場の予定をおさえること/写真撮影許可をえること/飲食許可の確認/無線LANを使えるようにする手続き/プロジェクターのチェック/事前の社内通知/etc...さらに今回は発表も兼ねることになったのでそちらの作業・検証も行いました。こちらもそれなりに負担になります。当日の対応が一番大変です。開始時間までにプロジェクタやスクリーンの準備を終わらせなければいけませんし、受付・遅刻対応(twitter監視)・機材のトラブルや忘れ物にも気を配っています。けっこう神経を使う作業です。

このへんはまあだれかに言われて勉強会やってるわけじゃなくてやりたくてやってるので別にいいんですが、配信に限らず要望・要請を受けて対応する体勢を一人でとることは難しいです。（「たかがUstくらい…」と思われるかもしれませんが、配信用のPCと機材調達・回線の確保(Guest用の低品質なネットではだめ)・配信トラブルに対応するといった作業が必要になります。shibuya.dは配信トラブル対応のリスクを負いたくないので配信をやっていないという形です。）

要望・要請を受けて即座に対応できる体勢を構築するには、複数人が連携をとって入念に準備を重ねる必要があります。そのためにはshibuya.dが個人主催からコミュニティベースへと変わっていく必要があると思っています。

P.S.

いや勉強会主催ってほんと大変なんですよ、疲れるしお金になるわけでもないし。。それでもやるのは他のD言語erに会ってみたいとか、そういう場を提供することで言語コミュニティを盛り上げたいとかそういう気持ちです。

D言語でシュッとスクリプトっぽく試す

qiita.com

これがとてもいいと思い、D言語で同じようなものを作ってみた。とりあえず3rd party製のものを意識しない版。

import std.stdio;
import std.regex;
import std.format;
import std.process;
import std.path;
import std.file;
import core.stdc.stdlib;
import std.uuid;

string makeConfig()
{
    return
`{
    "name": "temp",
    "targetName": "temp",
    "targetType": "executable"
}`;
}

string makeSourceCode(string input)
{
    return format(
`
void main()
{
    %s
}`, input);
}

void main()
{
    string input;
    foreach (line; stdin.byLine)
        input ~= line;

    // create dub root dir
    auto evalDir = buildPath(tempDir(), "evald-%s/".format(randomUUID()));
    mkdirRecurse(evalDir);

    // create dub.json
    {
        scope dubJsonFile = File(buildPath(evalDir, "dub.json"), "w");
        dubJsonFile.write(makeConfig());
    }

    // create source/app.d
    {
        scope sourceDir = buildPath(evalDir, "source");
        mkdir(sourceDir);
        scope sourceFile = File(buildPath(sourceDir, "app.d"), "w");
        sourceFile.write(makeSourceCode(input));
    }

    // chdir and execute
    chdir(evalDir);
    auto dub = execute(["dub", "run"]);
    dub.output.write;

    exit(dub.status);
}

• 実行結果

悪くないのでは

$ rdmd evald.d 
import std.stdio;
writeln("hello");
// Ctrl-d でstdinを閉じる
Performing "debug" build using dmd for x86_64.
temp ~master: building configuration "application"...
Linking...
Running ./temp 
hello

D言語とOS開発と自作OS

この記事は 自作OS Advent Calendar 2016 の3日目です。

D言語とOS開発

D言語はシステムプログラミング言語であり、OSを開発することのできる言語のひとつです。D言語でのOSプロジェクトはすでにいくつかあります。

Vild/PowerNex

今D言語でもっとも勢いがあるOS開発プロジェクトです。 公式のD Blogでも 記事 でとりあげられてました。

Rikarin/Trinix

最近は少し勢いが落ちているようですが、PowerNex以前からあるプロジェクトで、PowerNexもこちらのプロジェクトを参考にしていました。

自作への道

既存ですでにあるとはいえ、やはりOSを一から作ってみるというのは抗いがたい魅力があります。勉強していく中で既存プロジェクトに貢献できる箇所があるかもしれませんしね。

そういうわけで作り始めたいところですが、OS開発にかんしては右も左もわからない状態です。

Writing an OS in Rust を D言語に移植 してみたり、OSDev Wiki の D Barebones をGDCコンパイラから参照実装である DMDに移植し、さらにmultiboot化 してみたりということはしたのですが、なかなかここから先には手を出せていない状態です。

D言語ならではの注意点

ちょこっとしか触っていない中でもいくつかTipsみたいなものはみつかりました。

• @nogc / nothrow を関数呼び出しにつける

@nogc をつけておくとGCを呼び出さないことを保証できます(実は抜け道はあるのですが...) 同様に nothrow をつけると関数内から例外を呼び出さないことが保証できます。

• 静的配列のゼロ初期化に memset(3) 呼び出しを避けるために = void を使う (？)

D言語は静的配列のゼロ初期化に memset(3) 呼び出しを呼んでおりそれを避けるために = void で初期化を防ぐ...と記憶していたんですが、今objdumpしてみるとそういう処理がみられませんでした。そもそもkubOSのほうはUbuntu 16.10にあげた影響でGCC hardenedの影響で動かなくなっていてすぐには確認できず。。近い内に続報を書こうと思います。

おわりに

これからちょっとずつペースをあげて勉強していきたいなと思っています。なんとなくマイクロカーネルのほうがかっこいいと思ってるのでそっちのほうに舵をきりたいなーというかんじです。

なんだかまとまりのない記事になってしまってすいません。。

週末

土曜日にボドゲ会をやりました。

https://t.co/TP1GfYrJEe
この中だと魔王、あやつり人形、海底探検、お邪魔虫をやった。あやつり人形とお邪魔虫がおもしろかった。今回はやらなかったけど街こんとかもおもしろい。

— 黄前久美子さんと高坂麗奈さんの距離感 (@shitsyndrome) 2016年11月27日

D言語

diet-ngの記法を調べるだけでもたいへんめんどうくさい。

アニメ

覚えているものだけ。それはそれとしてフリフラはいいぞ。

オカルティック・ナインをみました。話すすんでるようなすすんでないような。

イゼッタをみました。エロい、しかしこれはアカン展開ですよじっさい、精神に悪い。つらい。つらいです。

百合セックス〜〜〜〜〜〜！！！！！！！！！！！！

D言語

vibe.d大変すぎませんか。エラーメッセージが不親切すぎる。。あとnull参照掴むコード多すぎますね、SEGV出す前提なところ契約プログラミングしてほしい。。

アニメ

響け！をみました。久美子回にみせかけた麗奈回では、と思うなどしました。

■

労

会議が多くつらかった。たいへんつかれた。

アニメ (報告)

まといちゃんをみました。

ステラのまほうをみました。

Rust LT会で発表しました

Rust

Rust LT会で発表しました。最初スクリーン映らなくて焦った…進行の方にご迷惑おかけしたことをここでお詫びします。

qiita.com

まあここに書いてることをまた書いてもあまり意味ないのでこぼれ話を。

取り上げてるmiocoは最近はあまり活発じゃないですね、作者のdpc氏はtokio-fiberというtokio-rs+libfringeな感じのものを作り始めていて、こちらへの置き換えを考えている節があります。といってもこちらはまだまだprototypeってかんじですが。miocoはI/Oデザインも気になりますね。スレッドごとにacceptor & イベントループもつのはどうなんだろう、単体のacceptorが軽量スレッドにclient fdを投げるデザインとどっちがパフォーマンス出るのかな。ここばかりはbenchmarkとってみないとなんとも言えないですね。他実装としてあげたcoio-rsのほうも https://github.com/zonyitoo/coio-rs/issues/56 という問題があるようで、まだまだこのへん使うのは大変そう、という感じもします。じっさいそこそこでいいならGoとかScalaのほうが楽な気がしますね。Rustだとマルチスレッドかつイベントドリブンなサーバプログラムをより安全にかけるのでは？という期待はとても大きいので、いいかんじになってほしいと思います。

懇親会ではなんだかテンション高かったのでnetmapとかIntel DPDKとかの話を口走った気がするがあまり文脈を覚えていない。。D言語ユーザぽつぽついたらしいけどコンタクトとれず残念でした。知り合いともけっこう喋れてよかった、OSなかんじな人がきてて、あーやっぱこういう言語はいいなと思うなどしました。

労

API Gateway/Lambdaに苦しめられました(主にiamのroleですが)。。ほんとにAWSで楽になるの…

アニメ

まほいくをみました。死の描写があっさりしすぎなんですがこっちも「あー死んだか」みたいになって毒されてきているのでは？？？