Gauche > Archives > 2016/05/05

2016/05/05 11:20:19 UTCkoguro
#
peek-charでportのread/writeポインタの値が進むのは仕様ですか?
#
gosh> (call-with-input-string "ab"
        (lambda (in)
          #?=(port-tell in)
          #?=(peek-char in)
          #?=(port-tell in)))
#?="(standard input)":96:(port-tell in)
#?-    0
#?="(standard input)":97:(peek-char in)
#?-    #\a
#?="(standard input)":98:(port-tell in)
#?-    1
1
#
中でungetcしているのなら、変化するのも分かるのですが、外から見えるAPIがpeekだけだと、ちょっと分かりにくかったので。
2016/05/05 11:26:38 UTCshiro
#
いや、Known issueです。fixあれば歓迎。https://sourceforge.net/p/gauche/bugs/61/
#
sf.netのイシューは備忘録がわりに使ってたんだけど自分でもほとんど見に行かないからgithubに移さないとだな。
2016/05/05 12:25:55 UTCkoguro
#
なるほど、了解です。なんか、portの種類ごとの対応がちょっと面倒そうですね。
2016/05/05 12:31:22 UTCshiro
#
スクラッチバッファもしくはungottenに入っている分をオフセットとして、ポートの種類ごとのtellとは別に管理すればそこの手間は省けるんじゃないかなとぼんやり思ってます。どっちかというとマルチバイト文字とバイナリI/Oが色々混ざった時の場合分けを考えるのが面倒で保留になってます。
2016/05/05 13:12:41 UTCkoguro
#
うーん、テストが中途半端ですけど、こんな感じかなぁと思っていたのですが (https://gist.github.com/nkoguro/8203bb77a240dec0c63b45f4491ff661)、考慮漏れがありそうですね。その場合分けについてちゃんと理解できてないようです。
#
なんかリンクが変になった。
#
https://gist.github.com/nkoguro/8203bb77a240dec0c63b45f4491ff661
2016/05/05 14:00:20 UTCshiro
#
本題とははずれますが、閉じ括弧はURLエンコーディング無しでURLに含められる文字なので、ChatonではURLの一部として扱ってるんですよね。実際に括弧が含まれるURLもしばしばありますし。なので自分で書くときは閉じ括弧の前にスペースを入れる習慣がついてしまいました。ヒューリスティックにやるなら、URLの一部としてマッチする開き括弧があった場合だけ閉じ括弧もURLの一部として扱う、とかかなあ。