時の羅針盤＠blog

CLOSの動作チェック

2012-01-26T13:39:00.000+01:00

0.3.0に備えてCLOSの動作チェック。組込みでCLOSをサポートするため。でもCL並みに高性能にするべきか悩み中。とりあえず、Tiny CLOSをベースにしようと考えていたので、サポートしてるmoshで検証。ただ、moshのCLOSってうっかり変なことするとすぐにハングアップするので注意が必要。せめて構文エラーとかそんなメソッドないとか言ってくれればいいのに。今回はaround、before、after、primaryについてちょっと調べてみた。結論を言うと、完全Aspect指向って感じ。検証コードは以下。 (import (rnrs) (clos core) (clos user)) (define (print . args) (for-each display args) (newline)) (define-class <person> () name age)

Cygwinのdlsym

2012-01-19T23:04:00.000+01:00

Google先生に聞いても今わからないなぁ。とりあえず何が起きたかメモ。 SagittariusにCLOSを入れようと組み込みクラスを実装して、拡張ライブラリの方も書き換えたら動的呼び出しが失敗するようになった。理由は分からない。確認できていることとして、Windows(MSVC)とLinux(Ubuntu、GCC)ではOK。ただ、Windowsでもそうなんだけど、Cygwinではリンカーが死んでるのか腐ってるのか知らないが、普通にコンパイルするとinitializer is not constantとか変なメッセージがでて怒られたのでC++でコンパイルしてる。VCではOKでg++では駄目だということなんだろうか？それとも、CでコンパイルされたDLLからC++でコンパイルされたDLLを呼び出せないとか？nmコマンドで調べるとシンボルはあるから、extern "C"とかそんなレベル

Version 0.2.4リリース

2012-01-17T14:04:00.000+01:00

もう少しいろいろテストしてからでもよかったかもと思いつつ。 Project page (in English) Sagittariusバージョン0.2.4がリリースされました。このリリースからCommon Lisp風のリーダマクロが使えます。またR7RS(draft 5)をサポートしました。同ドラフトが要求している構文およびライブラリ（1部除く）をサポートしています。一部リーダが読み込むシンボルに違いがありますが、これはSagittariusがGauche風のキーワードをサポートしているためです。修正された不具合 GC周りの不具合が修正されました。これはBoehm GCのライブラリを静的リンクしていたため起きた不具合です。現在ではGCライブラリを動的リンクしています。 define-with-keyがGauche風に動くよう改善されました。正規表現リーダが[[:

続R7RSモジュール

2012-01-13T22:59:00.001+01:00

今回は舞い上がらずに自分の中だけで。 ChatonのGauche部屋に以下の書き込みがあった。(Twitterで見てるので分かった。便利な世の中だ) okuoku http://compassoftime.blogspot.com/2012/01/r7rs.html R7RSライブラリ構文が来るのか nmoshはcond-expandのfeatureとキャッシュの関連が微妙なので保留中。。実はキャッシュの問題はまだ残っている、というか諦めていて、Sagittariusではそもそもマクロ展開後にマクロが変更されてもキャッシュは更新されない。これぐらいなら何とかなるかもしれないが面倒でやってない。しかし、include系はまず無理で、includeされたファイルの変更を検知する方法がない。なのでinclude先が変更されてもinclude元が更新されない限りキャッシュは作り変

R7RSモジュール

2012-01-12T09:56:00.001+01:00

次のリリースではドラフト５（たぶん確定だと信じる）のR7RSモジュールシステムが入る。まだ、include-ciがダミーな実装だがそれ以外はだいぶよさげ。以前exportやincludeが（scheme base)からエクスポートされていないと書いたが、まじめに実装して「されていなくてもいいのか」とちょっと納得した。（includeに関しては他で使えてもいいかなぁと思ったのでexportされていてもいいんじゃとは思うが。これってR5RSで書かれたものの再利用が簡単にできるための措置なんだろうか？） R7RSで定義されているライブラリの内、(scheme repl)は次のリリースでははずすことにした。というかinteractive-environmentが必要になる場面が想像できないのと、(scheme base)等のライブラリがimportされた環境をREPLに用意するのが大変なため

人間失格

2012-01-08T17:38:00.001+01:00

太宰治ではない。(読んだことないなぁ、そういえば) 個人的な人格の欠陥の話である。よくも悪くも僕は淡白だと思う。というよりは人に対して一定以上の興味がわかないというべきか。正直いろいろなことを生活習慣にしていかないと傍から見た際にまったく興味がないと思われるらしい。というか既に思われた。よくよく考えてみると自分のネコ好きというのも、その昔に自分で作った習慣のような気がする。昔から家にはネコがいるのが当たり前だったのでそれが簡単だったのだろう。別段自分が無味乾燥な人間ではないと思うのだが、どちらかと言えば引きこもり系な性格ではあると思う。嫌なこと、楽しいこと、すべて自分の中だけで完結して表に出さない。内側で驚いていても、表面には出さないので、僕は滅多なことでは驚かない人間、と思われている。(まぁ、お化け屋敷程度では驚かないが) 3つ子の魂100までなんて言われるように、これを今

結局

2012-01-07T12:59:00.000+01:00

Gaucheがあの方式を取れるのはMakefileを自前で書いてる(automakeではない)からであって、CMake使ってると不可能な気がしてきた。しょうがないのでREADMEに注意書き書いてdllでリンクするようにビルドした方がいい気がする。VCでコンパイルした際にどうしようかなぁというのと(gcmt-dllとリンクできなかった。何でだろう？)、オートダウンロード機能をつかってCygwinでコンパイルした際に問題になるけど。(GCのオートダウンロードはVCだけにすればいいだろうか？でも微妙だよなぁ・・・) そもそもGCを静的リンクにしようとした理由ってなんだっけ？

足元固め(バグつぶし)

2012-01-06T14:55:00.001+01:00

ようやく不可解なメモリ関連の原因が特定できそうな気がしてきた。現状、同じCygwinで起きる場合と起きない場合があった。今までどちらも同じ環境でビルドしていると思っていたが実は違った。片方はGCのDLLを使っていて、もう片方は静的リンクしてた。DLLの方はメモリを壊さないけど、静的リンクは壊していた。今までメインのDLLにGCが入っていればモジュールとして呼ばれるDLLはリンクしなくてもいいと思っていたがそうでもないのだろうか？ちょっと調査しよう。なんでロードされたDLLがGC対象外領域になるんだろう？さっぱり分からん。とりあえず、Windows以外の環境でBoehmGCが入ってなかったら動的ライブラリでインストールするようにメッセージ出せばいいだろうか？静的リンクだから、それぞれのdllとexeにGCがくっつくイメージなんだろうか？中身はよく分かっていないのだが。

sxpathメモ

2012-01-06T10:23:00.000+01:00

SXPathで名前空間付のSXMLにクエリーを発行するのがいまいち分からなかったのでメモ。正直これが正しいのか良く分かっていない。 (import (text sxml ssax) (text sxml sxpath) (pp)) (define *xml* "<?xml version=\"1.0\" ?><root xmlns:h=\"http://localhost/\"><h:p>hello</h:p></root>") (define *namespace* '((h . "http://localhost/"))) (let ((sxml (ssax:xml->sxml (open-string-input-port *xml*) *namespace*)) (sxml2 (ssax:xml->sxml (open-string-input-port *xml*

マクロ戦争再び

2012-01-04T20:39:00.000+01:00

分かってはいたことだがsyntax-caseがバギーである。笑ってしまったのは、明らかに意図していない動作をするコードであることでR6RSテストスイートがパスできること。バグの上に成り立つコードなんてイヤだ。ということで何が問題かを洗い出し、対策を考えることにする。問題とするコードはとりあえず以下のものだけに絞る。 (define-syntax loop (lambda (x) (syntax-case x () ((k e ...) (with-syntax ((break (datum->syntax #'k 'break)) #'(call-with-current-continuation (lambda (break) (let f () e ... (f)

(続)R7RSドラフト5

2012-01-04T13:13:00.001+01:00

ここから大きく変更はないだろうと仮定してdefine-libraryの実装に踏み切ろうかと思う。定義を見ると、export、import、begin、include、include-ci、cond-expandがlibrary declarationとして定義されていて、それらが中に何度出てきてもよさそうな感じである(一回だけとか書いてないからそう読む)。問題になりそうなのはexport、import、とcond-expandあたりだろう。 exportが2回以上出てきた際の扱いが書いてない。両方をexportするのか、エラーではじくのか、処理系依存になるのだろうか？ importが複数回でた場合も特に記載がない。例えば以下のケース。 (define-library (import test) (import (scheme)) (begin (define

R7RSドラフト5

2012-01-02T17:18:00.000+01:00

ちょっとまじめに眺めている。その際に見つけた気になる部分のメモ。 2.1 Identifiersより All implementations of Scheme must support the following extended identifier characters: ! $ % & * + - . / : < = > ? @ ^ _ ~ 「:」は識別しじゃないとだめらしい。キーワードはだめってこと？ (拡張という扱いにしよう、そうしよう) 4.2.1 Conditionalsより caseはcond同様=>をサポートしないといけないらしい。 4.2.5 Delayed evaluationより eagerって何だ？ The eager procedure returns a promise which when forced will return obj .

謹賀新年

2012-01-02T09:09:00.000+01:00

Happy new year!! Beste wensen, gelukkige nieuwjaar!! 本年もよろしくお願いいたします。元旦はわりと忙しくてかけなかった。今年の抱負(というか目標) 週2くらいでジムに行くオランダ語を話せるようになるギターを毎日少しでもいいので練習する書いておいて年末にできたかどうか確認しよう。去年は個人プロジェクトを発足するということを書いたみたいだ、目標達成ではあるか？個人的な近況報告できるほど変化があったわけではないのが寂しい。以下はSagittariusな話題。去年までの概観ソースを公開してまだ1年たっていないというのには自分でも驚きだ。まだまだ不安定な部分があるが、個人的に必要な部分はそろってきて感がある。ドキュメントの整備とドキュメント化されていない(意図的なものも含む)ライブラリ

括弧ゴルフ

2011-12-29T21:38:00.002+01:00

折角リーダーマクロを作ったし括弧ゴルフでもしてみるかとやってみた。以下のサイトのルールで。本当にLispはカッコが多い？最後にあるLispのリーダーマクロを参考にGaucheのfoldを使ったケースを実装してみた。 #! /usr/local/bin/sash (set-macro-character #\! (lambda (p c) (read-delimited-list #\$ p))) ! import ! srfi :1 $ $ ! fold ! lambda ! x y $ ! print ! - x 1 $ "!= " y $ ! * x y $ $ 1 ! iota ! string->number ! cadr ! command-line $ $ $ 2 $ $ まぁ、ある意味当たり前だが、括弧8個でいける。 set-macro-characterは本来は

リーダーマクロが動いた

2011-12-29T15:49:00.003+01:00

まだ、あまりテストしていないが、簡単なリーダーマクロが動いた。とりあえず当初の目的の通り正規表現を#/regex/と書ける様にしてみた。こんな感じ。 #<(sagittarius regex) (import (sagittarius regex)) (define rx #/\w+/) (print (regex-replace-all rx "abcdef@abcdef" "**$0**")) もちろん#/regex/ixumsのようにも書ける。汚いなぁと思うのは#<(ライブラリ)のように書かないとリーダーマクロがインポートされない部分。上記のようなプログラムなら(import)がやっても一緒なのだが、ライブラリが問題になってくるので、こんな風にした。また、loadしたファイルの影響を受けると意味が分からなくなるので影響範囲はファイル単位になっている。括弧ゴルフに勝つる

Linuxでコンパイルさせるためのメモ

2011-12-23T17:52:00.000+01:00

tarボールでコンパイルさせるテストの一環。そのうちソースに反映させるが、忘れないようにメモしておこう。 xubuntu 10.xx(細かいバージョン忘れた)ではapt-getでインストールできるcmakeのバージョンが2.8.3だったので、CMakeLists.txtの先頭行にあるバージョンを2.8.3にしてテスト。手直しが必要だったファイル： library.c core.c transcoder.c system.c load.c test-lib.c src/CMakeLists.txt ext/ffi/CMakeLists.txt library.cとsystem.cはミューテックスの初期化問題。まじめにInit関数でやりましょう。特にlibrary.cはInit関数がないので作成して、core.cで呼ぶ必要がある。 system.cは<io.h>

バージョン0.2.3リリース

2011-12-23T13:10:00.001+01:00

今までextディレクトリをtarボールに入れ忘れていたということに気づいて、今回からはそれらが入ってきます。(ということは今までのtarボールってコンパイルすらできなかったということだろうか・・・試してないからなぁ。今後は試すようにしよう。) 今回のリリースは後の拡張に備えたメンテナンスリリースです。修正された不具合：ライブラリインラインでマーキングミスがあったのが修正されました bitwise-first-set-bitにbignumを与えた際、不正な値を返すことがあった不具合が修正されました renameエクスポートが正しく動作していない不具合が修正されました改善された動作文字セットが組み込みになりました gcdにbignumを与えた際のパフォーマンスが改善されました。メモリの使用量が大幅に減っているはずです正規表現ライブラリが新たに書き直されました。単純な

根本的な解決ではないが

2011-12-23T11:52:00.002+01:00

RSA鍵の作成時に素数チェックにgcdを使用していて、Bignumのgcdが非常にナイーブな実装だったため大量のメモリを使用していた。そこで、binary GCDを実装して、メモリの割り当てが最大で4回になるように実装しなおした。そしたら、前述の不具合はとりあえずなりを潜めたのであった。 (あんまり高速化にはなっていないっぽい。512ビットの鍵ペアを作るのに2秒かかる[Core2Duo 3GHz]。Javaでは109ミリセコンドという、20分の1の時間で生成された。う～む) Windows版のSagittariusでもそれなりにいけるようになってきたような気はするが、テストを走らせると失敗するケースが1つ増えた。正規表現ライブラリを置き換えたからかもしれない。かなりテストを書いたがまだカバーしきれてないらしい。でもテスト外で同じ正規表現、同じ文字列でマッチさせるときっちりマッチ

バグの原因究明

2011-12-22T09:28:00.002+01:00

Sagittariusにはドキュメント化されていないライブラリが結構ある。理由はさまざまで、APIが固定されていないとか、近い将来変更になるのでその後とか、バグが取れてないとか、まぁいろいろだ。その中の「バグが取れていない」の代表格暗号化ライブラリでどこに不具合があるのかがようやく分かった。結論を言えば、メモリ割り当ての際にオーバーラップして割り当てているせいで、メモリ破壊を起こしているというものだ。原因はおそらく2つに分けられるだろうが、１つはBoehmGCがマークミスを起こしている。これは回避しようがないので、あきらめるしかない。もう一つは何らかの理由により、割り当てたメモリが使われていないという状態になり、GCによって回収されている(一緒くさいな・・・)。とりあえず前者っぽい挙動をしている。なぜだ？今回はどうやって直すかというのではなく、どうやって探したかをメモしておく。

ベンチマークとって見た

2011-12-20T16:02:00.000+01:00

新正規表現ライブラリのテストを書いているのだが、どの程度速く(もしくは遅く)なったのか知りたかったので、比較してみた。コードは以下 (add-dynamic-load-path "./build") (add-load-path "./sitelib") (load-dynamic-library "sagittarius--regex2") (load-dynamic-library "sagittarius--regex") (import (rnrs) (time) (srfi :13) (srfi :1)) (define bench '(begin (define-syntax bench-regex (syntax-rules () ((_) (begin (define rx (

ハイブリッドVM(正規表現)

2011-12-19T21:49:00.001+01:00

正規表現を書き書き直している最中、RE1とRE2を参考にしたPikeVMでは肯定先読み系はおろかpossessiveマッチさえも実装が困難だということに気づいた。そこでとりあえず普通に再帰を使って書いてみたら恐ろしく遅かった。どうしたらいいかなぁと電車の中で考えていたら、「ハイブリッドにしちまえよ」という悪魔のささやきが聞こえたのでやってみた。どうしたか？拡張正規表現(ここでは上記の2つ＋バックリファレンスを指します)を除いた単純な正規表現のみで記述されたパターンはPikeVMで動かし、えらいごてごてした正規表現は再帰を使ったVMで動かしてみた。これやるとおそらくpossessiveマッチで書いた方が遅いという不思議現象が起きるがそれは置いておいて、後読み(と後方参照もかな？)を除いた210個の単体テストが通った。遅いVMだと異常に実装が楽だったが、涙が出るほど遅く、

ふと、テレビを見ていて思ったこと

2011-12-16T23:13:00.001+01:00

標題に似合わず英語関連です。文自体は忘れたが、その中にあった単語「labour」を見てふと思ったこと。そういえば、上記の単語は自然な感じだが、「labor」と書かれると不自然な感じがする。いや、単に英語と米語の違い名だけで意味は一緒なのだが。っでなんとなく自然に感じるつづりと不自然感じがするつづりを並べてみた。ちょっとしたつづりの比較英語米語自然だと感じる方 colourcolorcolor labourlaborlabour behaviourbehavior両方OK favourfavor両方OK favouritefavoritefavourite centrecentercenter theatretheater両方OK とりあえず思いついたのがこんな感じだった。不思議と「ou」になるのが自然と感じるみたいだが、さすがに「color」はこっちのが自然だ。「

正規表現実装中

2011-12-15T20:54:00.000+01:00

ぶっちゃけ行き詰ったのでちょっと問題点の洗い出し。出来てそうなこと greedyマッチ non-greedyマッチスタートとエンドアンカー単語境界グループ(キャプチャリングとそうじゃないの含む) 文字クラス出来がやばそうなの肯定、否定先読み及び後読み possessiveマッチやばそうなのもある程度は動いてるんだけど、パターンによっては簡単に無限ループに入る。例えばこんなパターン \D(?!123) っで、"ABC123"を与えた場合、文字「C」にマッチしなければいけないが、マッチしない。また、パターンが \D*(?!123) になると無限ループする。(ほとんど出来て無いじゃん！) 原因は幅0を実装しているところにあって、2つ目のパターンだと、文字「A」は「\D」と否定先読みの両方を見る。っで、否定先読み(肯定でも)の条件にマッチすると、次の文字に行

ジョークプログラム(sleep sort)

2011-12-12T21:25:00.000+01:00

sleep sortなるものを実装してみた。元ネタはここGenius sorting algorithm: Sleep sort 消えてると寂しいので一応引用。 Genius sorting algorithm: Sleep sort 1 Name: Anonymous : 2011-01-20 12:22 Man, am I a genius. Check out this sorting algorithm I just invented #!/bin/bash function f() { sleep "$1" echo "$1" } while [ -n "$1" ] do f "$1" & shift done wait

英語に対する感覚

2011-12-12T20:22:00.000+01:00

前に英語で書いた記事にコメントが付いていた(スパム扱いされていたので気づくのに遅れた)。これはそのコメントを読んでちょっと気になったことについて。前置きとして、批判的な意味合いはまったく無く、コメントやご指摘がいただけるのは非常にうれしいことだと考えています。もしここから以下を読んで不快に思われたらごめんなさい。ということで一応分けてみる。やたら長くなったし。いただいたコメントは僕の拙い英語に対してのご指摘だったのだけど、ふと思ったのは「何故英語の記事にだけそんなコメントが着いたのだろうか？」ということ。もう少し端的に言えば、「僕の拙い日本語も指摘してほしいなぁ」ということ。まぁ、それだけではツイッターレベルなのでもう少しそれについての考察。何故それが気になるのか？もちろん個人の感性にもよるのだろうが、例えばそれが日本語で生地を感想させないように霧吹き等で湿