«前の日(12-21) 最新 次の日(12-23)» 追記

Matzにっき


2003年12月22日 冬至

_ [Ruby]1.8.1リリーススケジュール

例年のようにクリスマスリリースを検討しているのだが、間に合うだろうか。

えらい手間がかかった[ruby-dev:22307][ruby-dev:21899]は根治したみたいだから、 今日(22日)にpreviewを出して、問題が無ければ24日か遅くとも25日リリースできるかな。

私の気分としてはとっとと1.9を始めたいんだけど。いっそ誰かに1.8は任せたい。

_ [Ruby]直前のバグフィックス

クリスマスにリリースすると宣言した途端にいろいろとバグレポートがやってくる。 一番の難物はやはり-lpthreadとリンクしたライブラリと一緒に使っていると、 ハングするか、落ちる、というものだろう。 test/unitの作者Nathaniel Talbottのところで頻発している。

getcontext(3)を使うと落ちなくなるらしいが、ブロックはなかなか止まらない。 どうもpthread_mutex_lock(3)の最中にシグナルハンドラからコンテキストスイッチが起きると駄目、 のような気がする。手元で再現しないんでテストできないんだけど。

しかし、-lpthreadをリンクするとスタック領域が浅くなるので現在のRubyではつらい。 FreeBSDでは標準のtest suiteでさえスタックが足らずに実行できない。


2004年12月22日

_ 年賀状

ようやっと年賀状に手をつけた。例年、実は業者に依頼して写真年賀状を作っていたのだが、 今年はプリンタを購入したこともあり、 自分で印刷することにしようかと。

が、年賀状を作るなんてやったことがない。どうやったもんだか。

まず、KreetingKardを試す。 なかなか快適な使い心地。郵便番号から住所を埋めてくれるのもラクチン。 しかし、

  • 連名(奥さんの名前とか)に対応していない
  • 住所が長くなるとはみ出し部分を折り返してくれない

ので、宛て名印刷には使えない。しょうがないので裏はKreetingKardを使うものの、 宛て名は断念。その辺の冊子についている年賀状ソフトを使おうか。 なんか負けた気がする*1

なお、私に年賀状を送る人は、今年引っ越しましたから、 従来の住所の番地の部分を「361」に変更して送ってください。 転送願いを出してあるので、旧住所でも届くと思いますが。

*1  もうちょっと時間があれば自分でハックしたかもしれないけど、KDEプログラムは経験がないしなあ

_ [会社]忘年会

会社の忘年会。中華料理。

しかし、あの苦しそうな酒の飲み方はなんとかならないものか。 ぜんぜんおいしそうじゃない。 あれではなんのために飲むのか全然分からない。 何人もツブれてたし。

生涯を通じて一度も酔ったことがない私には理解できないなにかがあるのだろうか。 自分の精神を麻痺させる化学物質を、 自分の体が拒否する分量を越えて積極的に体内に取り込む行為を正当化するなにかが。

自分が宇宙人であるかのように感じた。

新婚の後輩から、夫婦関係を長続きさせるにはどうしたらよいですか、などと わりと根源的な質問をされる。 答えに窮しているうちに、上司(前社長)がとうとうと話し出したので、 私からはたいしたことが伝えられなかった。 「夫婦の関係は後天的だからメンテが必要なんだよ」くらいか。

しかし、帰宅してから風呂に入って考えると、 「誠実であること」がキーワードのような気がしてきた。 また、「自分たちが決めたルールを守ること」が有効かもしれない。 クリスチャンである私たちは戒律があるので、ルールが多いのだが、それでなくても、たとえば

  • 食事はできる限り家族全員で一緒にとる
  • 食事中にはテレビを見ない
  • 月曜の夜は家族全員が集まり活動をする

など家族の決め事を守る誠実さが家族関係を良好なまま維持できるかも。 制約がある方が自由であることのひとつの例かもしれない。


2005年12月22日

_ 病気 (1)

今日は終業式だというのに、息子が嘔吐下痢症にかかってしまった。 症状などから考えるとノロウィルスによるもののようだ。

夕方にはだいぶ具合が良くなったようだ。

_ [Ruby]Even Larry Gets Laid Off

先日、バスにはねられたらというエントリを書いたのだが、 小飼さんが Larryがリストラされたことを引いて、

「もし、まつもとさんが失業したらRubyはどうなるんだ」という質問とどちらが難しいだろう

と懸念して下さった。

ま、死んでしまえば、この世の人たちとの交流は完全に閉ざされてしまうので Rubyに対して手の出しようがなくなるのに対して、 失業してもRubyをあきらめる必要はないので、もうちょっとマシなんじゃないかと。

当面、失業する予定はないし、したくもないんだが、 今後、Rubyをビジネスに活用する人が増えて、 私の利用価値が増えれば、私の立場がより安定するのではないかと思う。 来年のRuby界の動きに注目したい。

そういう意味では、引き続き「Rubyにとって欠かせない人物」というポジションを死守する必要があるのだろう。言語設計者の立場は弱いので、油断なく「利用価値」を維持する必要がある。

(次のエントリに続く)

_ [言語] Guido van Rossum to work for Google

GuidoがGoogleに雇われたという話。

まあ、状況はよくわからないが、 とりあえず「おめでとう」と言っておこう。生活が安定することは良いことだ。

_ 雪と出張

朝から大雪。今日は東京出張の予定だったが、 大雪の中、空港まで移動した時点であきらめた。 飛行機は飛びそうだったのだが、キャンセル。 行ったら帰れそうにないし。

後で聞いたところによると、実際行ってたら帰れなかったらしい。 出雲への最終便は機材のやりくりが付かず欠航だった。

行かなくて正解だった。


2006年12月22日

_ [OSS] 「日・中・韓独自のOSSコミュニティを作るべき」--北東アジアOSS推進フォーラムにて

なぜ今ごろ、とも思うのだが。

で、もう一つの「なぜ」は、なぜ「独自のOSSコミュニティを作るべき」なのか。 記事を読んでもその理由はさっぱりわからない。

Kim氏は、「われわれ北東アジアの3カ国は、CE Linuxを除き、今のところOSSの生産国というよりユーザーに過ぎず、国際的なコミュニティに貢献できることも少ない」と話す。その理由のひとつは、「アジアで開発力のあるデベロッパーは1カ所に集まっておらず、力を合わせることなくばらばらに活動していることにあるのではないか」とKim氏は指摘する。そこで、北東アジア独自のコミュニティを作ってはどうかというのだ。

「アジアがOSSユーザに過ぎない」というのは分からないでもないし、 貢献が少ないので改善したいと言う気持ちも分かるが、 だからといって「1カ所に集まって、力を合わせる」ことが必要なのかなあ。

まあ、face to faceのコミュニケーションで話が進むことは多いのは認めるが、 決して必須ではないし、どうせ英語でコミュニケーションするのであれば アジア限定にする理由も見当たらない。

もうちょっとなにがしたいのか見守りたい。

_ [Ruby] ITmedia エンタープライズ:まつもとゆきひろ−第1回:オープンソースという「お仕事」

先日の風穴さんによるインタビューをまとめたもの。

「ちょっと違う視点からのインタビューを行いたい」という申し出の通り、 オープンソースで仕事してる人としてまつもとが表現されている、かも。

あまり仕事をしないのに、対外的な知名度だけが上がっていったので、結果的に会社としては、このような形でしか(まつもとを)使えなかったということだったのではないかと(笑)。

は本音。いやあ、首にならなくて良かった。経営者の忍耐のおかげである。

_ [教会] クリスマス会準備

明日のクリスマス会のための準備。ハロウィーンの時もそうだったが、 前日の準備も楽しいものだ。


2014年12月22日 そろそろStreemについてひとこと言っとくか

久しぶりの更新

GitHubの <URL:http://github.com/matz/streem> を公開したら驚くべき反響の大きさなので、本人もびっくりしている。

ので、ここでちょっとまとめておく。

  • もともとは日経Linuxの自作言語入門の連載のネタ
  • 時系列的には2015年1月号で言語仕様を決めた(原稿提出は11月中旬)
  • 2015年2月号で実装について解説(原稿提出は12月初旬)
  • 2月号原稿には「github.com/matz/streemを参照のこと」と書いた
  • 提出したその日に1月号発売
  • 原稿提出後、原稿で解説した部分を実装し(300行程度)、githubにアップロード
  • だれかが見つける
  • hackernews, redditなどでバズる
  • github issues, pull requestなどいっぱいくる
  • 私が実装する前に Go で実装しちゃう人が出る (mattn/streeem)

自分でもなにを言っているのかと思うけど、雑誌という出版物と比較して、超スピードとかでは説明のつかないネットとOSSコミュニティのバズり方を見た思いがする。

一方、雑誌連載のサンプルであるStreemだが、言語仕様についてはパッとした思いつき、 というわけでもなくて、数カ月間、このような言語はあまりないし、実用的価値もありそうと思って作っている。

特徴

  • Streamモデルにより、高い抽象度でコンカレント処理が記述できる
  • マルチコアを活用できる(ように実装できたらいいなあ)
  • 関数型、オブジェクト指向、ストリームモデルの融合
  • 「Rubyとは違う言語設計アプローチ」の実践

雑誌の連載のネタだとはいえ、今後も開発をやめるつもりもないので、ほそぼそと進歩し続ける予定。

っていうか、現在 C でタスクスケジューリングを実装することの困難さに絶望しつつあるので、 マジで streeem を参考に Go で実装するかも。


«前の日(12-21) 最新 次の日(12-23)» 追記