2015-09-29

暗号ライブラリ (別題:実用Scheme)

Schemeは黒板言語だと言われたりするのだが(概ね認める部分もあるが)、プログラミング言語は実用されないことにはコミュニティも広がらないだろうということで、完全R7RSのみで暗号ライブラリを作っていたりする。ちなみにR6RS処理系用はindustriaがあるので、そっちを使った方がよいと思われる。

ライブラリの名前はAeolus(アイオロス)。まぁ、そういうことです。基本的にはSagittariusで実装されてる(crypto)ライブラリに似せた感じのAPIにしてある。使い方は大体こんな感じ。
(import (scheme base)
        (aeolus cipher)
        (aeolus cipher aes)
        (aeolus modes ecb))

;; 128bit key
(define key (string->utf8 "1234567890123456"))
(define cipher (make-cipher AES key mode-ecb))

;; 16 octet block
(cipher-encrypt cipher (string->utf8 "It's top secret!"))
;; -> #vu8(230 1 210 64 10 131 72 18 222 112 210 129 170 236 243 42)
パディングとかはまだ実装してないので、自前でデータをブロック長にする必要があったりする。

以下はここにあるR7RS準拠の処理系での動作チェック。部分準拠のものは試してない。

完動(全テストパス)
  • Sagittarius 0.6.8
  • Gauche 0.9.5 (HEAD)
  • Larceny 0.98 (ただしパラメタのテストはtest-errorの実装がおかしいので動かない)
  • Chibi Scheme (23ac772e3a)
テスト失敗
  • Chibi Scheme 0.7.3 (AESのテストがこける。SRFI-33っぽい、使わないようにしたらテスト通った)
動かん
  • Foment (複数のバグを踏んだ)
  • Picrin (パスの通し方が分からん)
  • Kawa (同上)
未検証
  • Husk (Haskellいれるのだるい)
PicrinとKawaはなんとか試してみたいのだが、いかんせんライブラリパスの通し方が分からんので手が出せない。誰かテストしてくれないかな(チラ その他リストには載ってないけど動いたとかの報告があると嬉しいなぁ(チラ

とりあえずDES、Triple DESとAESをサポート(というか、当面はこれだけの予定。Blowfishとか欲しい人いる?) 以下は当面のTODO
  • パディング(パラメタにするか明示的にユーザにやらせるか悩み中)
  • ハッシュ(MD5、SHA-1、SHA-256、SHA-512等)
  • MAC(HMAC、CMAC辺り)
  • RSA
  • PKI(X.509証明書とか。ここまでやるとほぼSagittariusの焼き増しに・・・)
 これくらいあるとTLSとかSSHとか実装できそう。

なんでこんなの作ったのか?


上の方に書いたのと被るけど、○○がないからSchemeは使わない(使えない)と言われるのが嫌だったから。仕様内だとソケットやスレッドがないのでいろいろ厳しいんだけど、そこに依存しないピュアSchemeなライブラリを書いていけばそのうち人が増えるのではないかと。黒板言語と呼ばれる理由の一つに実用的なライブラリが圧倒的に足りないというのがあると思うので、そこを何とかしていけばいつかきっととか。以前書いたPostgreSQLバインディングもそんな気持ちからというのはある。(Scheme使ってPostgreSQL使ってるっていう人の方は少ない気がするので、ちとニッチ過ぎたというのはあるが・・・)

まぁ、後は仕事で暗号関係を使わなくなってきたので、忘れないようにというのもある。誰にも聞かれないと思うけど、一応動機。

2015年9月30日追記
Chibiのバグが直されたので完動に追加。仕事が速い。

2015-09-24

process-wait with timeout argument

Recently, I'm writing own CI task on my local machine. (it doesn't mean I quit others when it's completed but just for fun.) Then, I've noticed that it might be convenient to have timeout argument on process-wait instead of using timer to poll every 500 ms (or whatever). So I've implemented it, now you can use like this:
(import (rnrs) (sagittarius process))

(let ((p (call "sh" "sleep_forever.sh")))
  ;; wait for 5 seconds. can also be time object.
  (unless (process-wait p :timeout 5))
    ;; it returns #f if timed out. so kill it
    (process-kill p)))
Now, I don't have to make timer to check. Very convenient :)

TL;DR


From here is the description of underlying implementation. This is not something you may be interested in but simply for my memo (and hope that somebody would indicate better solusion).

Sagittarius supports both Windows and POSIX environment. On Windows, the story was very simple, I just needed to call WaitForSingleObject with process handle and timeout millisecond. Hurray done!. I like this abstraction that API can handle almost any kind of handle. (Most of the time it's a headache to support Windows but sometimes it's easier than POSIX.)

On POSIX, on the other hand, it doesn't have timedwaitpid or something like that. I've asked the teacher, Google, what would be the solution. The first hit was this: Waitpid equivalent with timeout?. Its best answer doesn't seem the best answer since entire process would be affected. Plus, it would always wait for specified timeout amount of time which is not something I want. The most useful pointed one looks nice if POSIX has a portable way to get standard output file descriptor from pid. Though, there seems a way to do it using ptrace(2). (See reptyr(1) and  its source). I haven't looked into its detail but, in my understanding, it opens given pid process with ptrace(2) and calls dup(2) on that process (ptrace_remote_syscall does this black magic I think). It'd be nice to have it if I can do this all platforms Sagittarius supports. However not an easy task to do it without having real environments (e.g. OS X is only on Travis CI).

Go easy


What I wanted to do is waitpid with timeout. So I just need to have a watch dog which alerts either timeout is happened or the target process is finished. Well, the easiest one I could think of was thread with pthread_cond_timedwait(2).

The idea is pretty much simple. It goes the following steps:
  1. Create a thread with the thread entry which calls waitpid
  2. Call pthread_cond_timedwait.
    1. If this return ETIMEDOUT, then send signal to the thread and return #f
    2. Otherwise return the return code.
Done! What an easy solution! (There was a stupid mistake. I didn't know pthread_join can't be called with detached thread. Though, interestingly, it worked on FreeBSD, why?)


Issue


Well, if I can say this is a perfect solution, I'd be super happy but of cource this has an issue (for now only one I'm facing!). Because of the limitation of waitpid (2), the pid can be waited must be created by the parent process means Sagittarius script. Thus processes created by pid->process can't be passed (well this is not only for timeout argument but entire procedure issue, though). If this happens, then ECHILD is raised (see waitpid(2)).

I haven't got any problem with it but if would, then I need a better solution (maybe set PPID to running process? but how?). But for now, I'm happy enough and I believe there's very few situation which users want to wait non child processes.

Again, this isn't an issue on Windows. I don't care good or not but I like it.

2015-09-22

SMTPクライアント

何かが失敗したときにメールを飛ばせると便利かなぁと思い書いた。こんな感じでメールが飛ばせる(サンプルはドキュメントから)。

(import (rnrs) (rfc client))

;; creates SMTP mail object
(define mail 
  (smtp:mail
   (smtp:from "Your name" "your-address@example.com")
   (smtp:subject "Subject")
   "Message"
   (smtp:to "recipient@example.com")))

;; creates an SMTP connection
(define smtp-conn (make-smtp-connection "your.smtp.server.com" "587"))

;; connect to the server
(smtp-connect! smtp-conn) ;; returns SMTP connection

;; Authenticate if required.
(when (smtp-authentication-required? smtp-conn)
  ;; NOTE: only AUTH PLAIN is supported for now
  (cond ((memq 'PLAIN (smtp-connection-authentication-methods smtp-conn))
         (smtp-authenticate! smtp-conn (smtp-plain-authentication
                                        "username"
                                        "password")))
        (else (smtp-disconnect! smtp-conn)
              (error #f "authentication method not supported" 
                     (smtp-connection-authentication-methods smtp-conn)))))

;; Send it
(smtp-send! smtp-conn mail) ;; returns SMTP connection

;; Clean up
(smtp-disconnect! smtp-conn)
メールを作る部分は利便性を高めるためにマクロを用意してて、これの嬉しい点としては、記述力が高いこともあるけど、以下のようにメールをテンプレートとして外部ファイルに書き出しておいて、readevalで手軽に作成することができることもある。
(define mail
  (eval (call-with-input-file "mail.scm" read)
        (environment '(rnrs) '(rfc smtp))))
今のところは考えてないけど、メールのソース(MIMEテキスト)からメールをパース・生成するというのがあってもいいかもしれない。(その前に認証をもう少しなんとかしないとという感じではあるのだが。PLAINだけとかいくらなんでもねぇ・・・)

 一応RFC5321に書いてあるコマンドは全部実装してあるが、拡張とかは全然だし、エラー処理とかもまだ大分甘いので使って直していくという感じ。

2015-09-11

call/ccで嵌った話

call/ccというよりはguardなんだけど。

エラー処理をしたいとか、エラーが起きても処理を継続したいという場合はままある。そういったときに使えるのはguardであることもまぁ周知の事実だと思う。これから提示する例も常識的に理解されているものかもしれない。

まずは以下の例を見てもらいたい。
(import (rnrs))
;; (import (scheme base) (scheme write))
;; (define mod modulo)

(define count 100000)

(define (run)
  (let loop ((i 0))
    (if (= i count)
        i
        (guard (e (else (loop (+ i 1))))
          (when (zero? (mod i 5))
            (error 'who "dummy"))
          (loop (+ i 1))))))

(display (run)) (newline)
(flush-output-port (current-output-port))
これをみて、「あぁ、これはまずいわ」と一目で分かったら以下を読む必要はないです。

これがまずいプログラムだということは既に書いているのでいいとして、何がまずいか。問題になるのはguard内で外側のloopを呼んでいること。一見すると問題ないように見えるのだが、多くの処理系でguardの実装にcall/ccを使用しているのが問題になる。実装例:SRFI-34
参照実装を展開して簡潔に書くと以下のようになる。
(define (run)
  (let loop ((i 0))
    (if (= i count)
        i
        ((call/cc (lambda (k)
                    (let-values ((args (loop (+ i 1))))
                      (k (lambda () (apply values args))))))))))
はい、末尾再帰じゃないですね。なのでスタックがあふれます・・・orz

実際のところとして、R6RS的には末尾再帰になることを要求しているので上記はスタックがあふれるとまずいのだが、(嘘ついた。<cond>を<body>と空目した。)これが問題なく動いたのは確認した中ではChezとRacketだけ。(GuileとVicareは試してない。) もちろん、この2つはスタックを拡張して動かしてるだけかもしれないけど・・・ちなみにR7RSは末尾再帰であることを要求していないので、上記は動かなくても問題ない。

この挙動で嵌ったの実は2回目で、3度目があると嫌だなぁと思ったので適当に書き記しておく。 しかし、どうやったら末尾再帰なguardが実装できるんだろう?参照実装では無理だよなぁ?

追記:
直した。https://bitbucket.org/ktakashi/sagittarius-scheme/commits/7bab13c1e83820eda28fc7878b14209fe1b87df3?at=default

追記の追記:
Shiroさんとのやり取りで上記の修正が正しいのか不安になってきた。っが、問題になるケースが思い浮ばない+スタック消費しないのでこのままで行くことにする。

Problem of hop on hop off projects

Hop on hop off projects is the term I made. This means you join a project in short term, then join other project in short term, like hop on hop off tour buses. (I just don't know any word describes such a style of driving project, drifting?)

I'm currently working with kind of scrum environment. Why kinda? It's because sprint period is rather longer than usual (4-5 weeks) and no standup meeting. The same part is that each sprint I get new task(s). By now, the tasks I've got assigned were not really related so each time I need to look into something I don't know (of course product specific thing). Thus hop on hop off projects.

It might be only me but if I don't have long term commitment of a project, then I lose interest and start writing crappy code. This is because I start thinking that "I would move to next something I don't know anyway why should I write maintanable code?". Probably, I don't feel any responsibility to the code I'll never see in future. (Plus, the current code base is really pile of shit, I don't want to swin into that. Too risky...)

What happen if I'm such a state? For example:
  • Start using copy&paste instead of extracting common use-case somewhere usable place.
  • Using magic number/string as everybody is doing.
  • No tests (well, I don't think there's a culture writing a test in this company...)
These are happening right now. Of cource I know I'm not doing right but risk is too high if I touch/refactor something without tests. I do what I suppose to do but I'm not those highly motivated people so I don't much care as long as I don't see it anymore.

The funny thing about this is that my company is actually developing one product however they don't assign to the same project (so far) or don't have long term assignment. Each task must be done at most a month. I understand that's the basic idea of scrum. But by now, I can only see the greate failure, such as:
  • Wrongly abstracted classes
  • No tests
  • Copy&pasted code
  • Only few people know the structure of code/architecture
  • No refactoring (of cource, there's no efficient tests!)
  • etc.
I'm such a lazy person so I'd write as maintanable as possible if I need to maintain the code. But if I don't have to, this laziness seems to take into horribly.
Or maybe I'm considered as one of useless developers so they don't want me to do anything but piling crap. That's fine by me, as long as they pay my salary.

2015-09-09

ハッシュテーブルSRFIs

ハッシュテーブルに関するSRFIが2つ提出された。一つはJohn Cowanの「SRFI-124: Intermediate hash tables」でこれは既存のSRFI-69の互換性を保ちつつ拡張するというもの。もう一つはTaylan Ulrich Bayırlı/Kammerの「SRFI-126: R6RS-based hashtables」でこれは名前からも分かるようにR6RSで標準化されたハッシュテーブルを拡張するもの。SRFI-126はweakハッシュテーブルを要求しているのでこちらを実装すればもう片方は実装可能という感じである。(bimapをどうするかとかはあるが、Schemeで実装してしまえばいいわけだし、気にしないことにする。所詮別の型だし。)

これだけなら特にネタにもならないのだが、現状SRFI-126はweakハッシュテーブルと通常のハッシュテーブルの操作を同一の手続きで行えることを要求している。インターフェースの統一という感じだし、実用を考えればわざわざ「weak-hashtable-ref」とか書かずに「hashtable-ref」でアクセスできた方が楽というのはあるだろう。問題はどうこれを実現するかということだ。普通に全ての手続きでハッシュテーブルのタイプを場合分けしてもいいんだけど、泥臭い上に拡張性が低い。別のハッシュテーブルが追加されるという可能性は低いといえば低いが、ないわけでもないだろう(concurrentハッシュテーブルとか)。とすると、もう少しマシな方法を考える必要がある。

現状Sagittariusはハッシュテーブルとweakハッシュテーブルは完全に別の型としているのだが、これを以下のようにするとなんとなく拡張性が高くなりそうな雰囲気がある(あくまで雰囲気)。
          +-----------+
          | hashtable |
          +-----+-----+
                |
      +----------+-----------+
      |                      |   
+-----+------------+ +-------+--------+
| normal hashtable | | weak hashtable |
+------------------+ +----------------+
まぁ、普通というか、ひねりも何にもなくインターフェースと実装を分けるだけという。実際にはこれにmutableとimmutableのクラスを追加してやろうかなぁとも考えている。こうしておけば後で意味不明なハッシュテーブルが現れてもそれなりに問題なく動くことが期待できそうだ。

このSRFIは出てきてまだ数日なので上記の変更を入れるかを決めるのは時期尚早な気がする。ただ、この変更自体はやってもいいかなぁとも思えるのでどうしようかなぁというところ。