コミットログで日本語
Tommy
--
Y.Tokutomi
http://iddy.jp/profile/Tommy/
フジワラ
符号化に詳しい方なら、ひょっとして件の文字列を見ると
「あぁ、あれね」と思い当たるのかも知れませんが、
とりあえず愚直に正面突破で(笑)行って見ます。
以下の点を確認してみてもらえますか？
- コミットメッセージの指定方法
- "-m" でコマンドライン指定
- "-l" でファイル指定
- "hg commit" が起動するエディタで入力
- HGENCODING 環境変数値
- 日本語のコミットメッセージを使用しているリビジョンを
"hg export" でファイルに記録した場合の文字コード
フジワラ
少々補足を。
> 以下の点を確認してみてもらえますか？
>
> - コミットメッセージの指定方法
> - "-m" でコマンドライン指定
> - "-l" でファイル指定
> - "hg commit" が起動するエディタで入力
>
> - HGENCODING 環境変数値
場合、"commit -l" で当該文字コードで保存されたファイルを使った
commit は上手く機能する筈ですが、どうでしょうか？
＃ これが駄目だとすると結構根が深い話になる可能性がありますが…
後は、普段の使用形態との差異を調べていくことになりますね。
例えば、端末設定とか、中間プログラム(Emacs の shell-buffer とか、
hg-mode とか、screen コマンドとか)を経由する場合なら、プロセス間連携での
文字コード設定とかでの不整合が容疑者筆頭でしょうかねぇ。
Tommy
- "-l" でファイル指定 (utf-8)
- "hg commit" が起動するエディタで入力
フジワラ
On 9月15日, 午前12:41, Tommy <tommy.heartb...@gmail.com> wrote:
> HGENCODING を設定してなかったため、試しに
>
> export HGENCODING=utf-8
>
> としてから、hg commit してみましたら、エラーにならずにコミットできました。
> # locale 設定ではダメなんですね…。
別件の「i18n/ja.poへのパッチ」スレッドでチラっと出てきましたが、
Python の locale 設定認識の有無は、バージョン／環境に依存している
模様ですので、一度確認されてみてはいかがでしょうか？
あと一つ気になるのは:
> コミットするにあたって、日本語が使えない訳ではないのですが
という点ですね。ASCII 扱いされているなら、全部ブロックされて
然るべきな気がするのは間違いなんですかね？ ＞ 符号化に詳しい方
INADA Naoki
Mac使いでは無いので詳しくは知らないのですが・・・
import locale
locale.getpreferredencoding()
によって得られるエンコーディングは、環境毎に適した方法で一般的に利用されている
エンコーディング・・・なのですが、Python 2.6 ではこの部分のMac対応部分が
UNIXのlocaleを使ったマナーに対応しておらず、Mac OS 9 から利用できる方法を
使っているようです。
Python 3.1 と 2.7 から、localeを使った方法に対応する予定です。
# コミットログは追いかけていませんが、該当バグのstatusでは2.7/3.1のみが指定されていて、
# Python 2.6.3 でのfixは期待できないかと思います。
Mercurial以外にも locale.getpreferredencoding() を利用しているアプリはあると
思うので、以下のようにしてこの関数を乗っ取ると良いかもしれません。
1) site.py を見つけ同じディレクトリに sitecustomize.py が無ければ作る
2) sitecustomize.py の中に以下の行を追加する
import locale
def _mypreferredencoding(*args):
return 'UTF-8' # がんばって環境変数から取り出すとなお良い。
_orig_getpreferredencoding = locale.getpreferredencoding
locale.getpreferredencoding = _mypreferredencoding
3) python -c "import locale; print locale.getpreferredencoding()" を実行して
UTF-8 と表示されることを確かめる。
それにしても、元のエラーメッセージで "'utf8' codec can't decode bytes in ..." と
utf8が使われているように見えるのに失敗していて、HGENCODING=utf-8すると
成功するのはやはり謎です。
--
Naoki INADA <songof...@gmail.com>
INADA Naoki
>
>> コミットするにあたって、日本語が使えない訳ではないのですが
>
> という点ですね。ASCII 扱いされているなら、全部ブロックされて
> 然るべきな気がするのは間違いなんですかね？ ＞ 符号化に詳しい方
先ほどのメールに書いたように、エラーメッセージに utf8 と書かれているのが気になります。
Macでは同じUTF-8でも正規化方法が違うとか聞いたことがあるのですが、
よろしければ問題が出る環境で以下を試して頂けないでしょうか？
$ echo 機能追加 > foo.txt
$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> foo = open('foo.txt').readline()
>>> foo
'\xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n'
>>> foo.decode('utf8')
u'\u6a5f\u80fd\u8ffd\u52a0\n'
>>> foo.decode('utf-8')
u'\u6a5f\u80fd\u8ffd\u52a0\n'
>>>
#インタラクティブシェルを起動してコマンドを入力しています。
#シェルを抜けるにはCtrl-Dを押してください。
--
Naoki INADA <songof...@gmail.com>
Tommy
--
Y.Tokutomi
http://iddy.jp/profile/Tommy/
Morimoto Tetsuya
符号化に詳しいわけでも何でもないのですが、
私も UnicodeEncodeError/UnicodeDecodeError とよく遭遇します。
この原因に関して、
(私が知っている)最も詳細に書かれている記事が以下になります。
http://lab.hde.co.jp/2008/08/pythonunicodeencodeerror.html
※ 以下、この記事に書かれている内容ですので詳細はこちらをご確認ください
mercurial のソースを読んでいないので的外れでしたら申し訳ないのですが、
OS のコマンド実行やファイル操作などは、
マルチバイト文字も str 型で扱わないと、エラーになるようです。
- UnicodeEncodeError の例
例えば、パイプを扱うような処理は str 型でないとダメだそうです
以下は成功します
>>> str_type = 'find test/さぶ'
>>> str_type
'find test/\xe3\x81\x95\xe3\x81\xb6'
>>> commands.getoutput(str_type)
'test/\xe3\x81\x95\xe3\x81\xb6\ntest/\xe3\x81\x95\xe3\x81\xb6/\xe3\x81\x95\xe3\x81\xb6\xe3\x81\x95\xe3\x81\xb6'
以下はエラーになります
>>> unicode_type = u'find test/さぶ'
>>> unicode_type
u'find test/\u3055\u3076'
>>> commands.getoutput(unicode_type)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/commands.py", line 46, in getoutput
return getstatusoutput(cmd)[1]
File "/usr/lib/python2.6/commands.py", line 55, in getstatusoutput
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
UnicodeEncodeError: 'ascii' codec can't encode characters in position
12-13: ordinal not in range(128)
- UnicodeDecodeError の例
マルチバイト文字を含む str 型をデコードする際に文字コード指定をしないと、
デフォルトエンコーディング(つまり ASCII) でデコードしようとします。
例えば、以下のような文字列の連結で発生します。
>>> s = 'あ'
>>> s
'\xe3\x81\x82'
>>> u = u'abc'
>>> u
u'abc'
>>> s + u
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
0: ordinal not in range(128)
内部的には以下のような動作と等価だと思います。
>>> s.decode('ascii') + u
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
0: ordinal not in range(128)
変数 s はマルチバイト文字なので utf-8 でデコードすれば成功するわけですね。
>>> s.decode('utf-8') + u
u'\u3042abc'
エンコード/デコードをあちこちでやってしまうと、
適切な処理(もしくは型指定)がなされていない箇所が
どこかで発生しているのではないかと推測します。
稲田さんも仰っているように、これを解決する魔法の方法が
sitecustomize.py のデフォルトエンコーディングを
ASCII から UTF-8 に変更してしまうことのようです。
しかし、これは本質的な解決方法ではなくて、
どこか見知らぬ場所で自動変換されているのを UTF-8 にすると、
見た目上、エラーが出なくなる(適切に処理される)だけで、
本来は適切な型を指定するのが在るべき姿(？)だと聞きました。
しかしながら、ワークアラウンドとしてよく使われているようです。
とても悩ましい問題ですよね(- -#
2009年9月15日16:09 INADA Naoki <songof...@gmail.com>:
INADA Naoki
> 稲田さんも仰っているように、これを解決する魔法の方法が
> sitecustomize.py のデフォルトエンコーディングを
> ASCII から UTF-8 に変更してしまうことのようです。
私が書いたのは defaultencoding ではなくてpreferredencoding の方です。
setdefaultencoding() を使うのは、Pythonistaとして負けた気分になるので（笑）、
エラーが出たらその部分を直すことにしています
> しかし、これは本質的な解決方法ではなくて、
> どこか見知らぬ場所で自動変換されているのを UTF-8 にすると、
> 見た目上、エラーが出なくなる(適切に処理される)だけで、
> 本来は適切な型を指定するのが在るべき姿(？)だと聞きました。
Mercurialはきちんとデコード/エンコードしていないからエラーになるのではなくて、
デコード/エンコードする時に指定するエンコーディングを間違っているからエラーに
なるので、デフォルトエンコーディングは関係ないですね。
INADA Naoki
ありがとうございます。
見たところ、utf-8とutf8で違いがあるわけでもないし、echoの結果も普通の
UTF-8になっていますね。
うーん、なんであのエラーメッセージが "utf8" でデコードに失敗していると
言っていたのか、なぜHGENCODINGを設定したら直るのか、まったく判らない・・・
--
Naoki INADA <songof...@gmail.com>
Morimoto Tetsuya
もりもとです。
ご指摘ありがとうございます。
> 私が書いたのは defaultencoding ではなくてpreferredencoding の方です。
ちゃんと確認していませんでした。すみません。
> デコード/エンコードする時に指定するエンコーディングを間違っているからエラーに
> なるので、デフォルトエンコーディングは関係ないですね。
そういうことなのですね。私の勘違いで混乱させてすみませんでしたm(_ _)m
2009年9月15日21:17 INADA Naoki <songof...@gmail.com>:
Shun-ichi GOTO
2009年9月15日21:21 INADA Naoki <songof...@gmail.com>:
> ありがとうございます。
> 見たところ、utf-8とutf8で違いがあるわけでもないし、echoの結果も普通の
> UTF-8になっていますね。
> うーん、なんであのエラーメッセージが "utf8" でデコードに失敗していると
> 言っていたのか、なぜHGENCODINGを設定したら直るのか、まったく判らない・・・
ちなみに "加" で終わる文字列でのトラブルは他でも見かけました。
http://idlysphere.blog66.fc2.com/blog-entry-11.html
藤原さんや稲田さんの言うとおり、ちょっと不可解で気持ちがおさまらない
ので気になっちゃってます。encoding面で思い当たることっていったら、
Macの場合 unicode の正規化処理でNFDくらいなのですが、濁点などの合字の
問題問題の話なので、今回は多分関係ないですよね。
思いつくほかの(薄い)可能性としては。。。
mercurial.encoding をみると HGENCODINGを指定しない場合、
Mac OSのlocale問題を回避するために setlocale()していますが、
これがなにかしらの影響を与える、とか。。。
で、徳冨さん、もう少しご協力願えるならば。。。
試しに HGENCODING をセットしない状態で pythonを起動し、
真っ先に
import mercurial.encoding
print mercurial.encoding.encoding
を行ってから稲田さん提示のことをもう一度行ったとしても
同じ結果でしょうか？
あと、HGENCODING をセットしない状態(エラーの出るはず)で
hg commit を実行する際に --traceback オプションを付けてみた結果を
見せてもらえば、どこでエラーが起きてるのかがわかって、
もしかしたらヒントになる *かも* しれません。
--
Shun-ichi GOTO
Tommy
Shun-ichi GOTO
> 徳冨です。
> 仕事のピークだったため、リプライが遅れました。申し訳ありません。
> 後に続く人が苦労しなくてよくなるように、よろこんで協力させていただく
> つもりですので、どうぞよろしくお願いします。m(__)m
ありがとうございます。
> ■ 1. 前回と同様のオペレーションの記録
> tokutomi$ unset HGENCODING
> tokutomi$ env | grep HG
> tokutomi$ python
> Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
> [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import mercurial.encoding
>>>> print mercurial.encoding.encoding
> UTF8
>>>> foo = open('foo.txt').readline()
>>>> foo
> '\xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n'
>>>> foo.decode('utf8')
> u'\u6a5f\u80fd\u8ffd\u52a0\n'
>>>> foo.decode('utf-8')
> u'\u6a5f\u80fd\u8ffd\u52a0\n'
>>>>
問題ないですねぇ。
ところで foo.txt を作るのに使用したエディタは、失敗したコミットの際の
コミットログを作るのに使用したエディタと同じでしょうか？
> ■ 2. --traceback のログ
> tokutomi$ hg commit --traceback -m '機能追加'
> トランザクションを中断します!
> ロールバックを完了しました
> Traceback (most recent call last):
(中略)
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/mercurial/encoding.py",
> line 64, in fromlocal
> raise error.Abort("decoding near '%s': %s!" % (sub, inst))
> Abort: decoding near '機能追?': 'utf8' codec can't decode bytes in position
> 9-10: unexpected end of data!
> 中止: decoding near '機能追?': 'utf8' codec can't decode bytes in position 9-10:
> unexpected end of data!
> tokutomi$
tracebackでの呼び出し履歴自体も問題なさそうなのですが、
最後のエラーが期待と違ってものすごく気になります。
Abort: decoding near '機能追?': 'utf8' codec can't decode bytes in
position 9-10: unexpected end of data!
上のエラーは最後の "加"(0xe5 0x8a 0xa0) の部分がUTF-8シーケンスとして3
バイト構成であるはずなのに2バイトしか得られないため起きています。ターミ
ナルへの漢字入力から内部のcommit()に至るまでのどこかで1バイト欠けてしまっ
てるということになります。理由は不明ですが、ターミナル周りで何かあるの
かも？(憶測)
で、さらにリクエストです。
できる範囲で構いませんので以下のことをしていただけますか。
1. ターミナル上で python を起動し import sys および
sys.stdin.readline() を実行し、"機能追加"の漢字4文字を(コピペではな
く)いつものように入力し、改行を入力すると正しく
'\xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n' が得られますか？
2. hg に --debugger でデバッガ内で引数を表示するとどうかみてみて欲しい
です。Windows でやるとこんな感じになり、『機能追加』文字列のバイト並
びが見えますが、そちらの環境だと期待する12バイトのutf-8文字列になっ
てますかね。
$ hg commit --traceback -m '機能追加' --debugger
(Pdb) import sys
(Pdb) sys.argv
['c:\\mercurial\\hg.exe', 'ci', '-m', '\x91\xc5\x82\xc2', '--debugger']
(Pdb) len(sys.argv[3])
4
(Pdb) quit
この段階で正しいかどうかで python 内部か外部かを切り分けできると思う。
3. 最初のメールでのエラーの際に使用したコミットログのテキストのバイト列
が知りたいです。というのもエラーには '?機能追? のように "?" が3個ほ
ど見えていています。これはターミナル表示の際に utf-8 としてencode で
きないバイトを置き換えたものかと思いますので、奇妙なバイトが紛れ込ん
でる可能性があります。
できれば、hg ci の際に開いたテキストエディタで文面を入力した後そのま
ま保存して終るのではなくて、いつものようにファイルに保存後直ちに終了
せず、その内容を別ファイルにも保存してみてくれませんか？ そしてその
コミットが失敗したならば、その別ファイルの内容(バイト列)が参考になり
ますので、そういうファイルが得られたならばzip してバイナリファイル添
付するか、od -x コマンドなどでHEXダンプしたテキストを見せて欲しい。
4. hg の extension の類を設定しているならば一旦全てなしにしてコミットを
試してみて欲しい。現在有効なextension は hg showconfig extensions
で得られます。
> そういえば、Snow Leopard (Mac OS X 10.6.1) を使用しており、
> Mercurial のインストールは MacPorts (パッケージマネジャー) を使いました。
> 上のログを見ると Python も MacPorts で入ったみたいですが、Python 自体
> は /usr/bin のモノ (Apple 版) が使われています。影響してるかどうかは分か
> りませんが…。
> ---
> $ which python
> /usr/bin/python
> $ python --version
> Python 2.6.1
> $ /opt/local/bin/python2.6 --version
> Python 2.6.2
5. まさかとはおもうけど python のバージョンの違いによる影響があるかも
知れないので hg ci と実行する変わりに
/opt/local/bin/python2.6 `which hg` ci として
コミットしてみると成功したり、ということはありませんかね。
--
Shun-ichi Goto
INADA Naoki
機能追加の前後にある???の意味がわかりました。
mercurial.encoding.fromlocal の中で、エラーメッセージをこのように出力しています。
try:
return s.decode(encoding, encodingmode).encode("utf-8")
except UnicodeDecodeError, inst:
sub = s[max(0, inst.start-10):inst.start+10]
raise error.Abort("decoding near '%s': %s!" % (sub, inst))
デコード時にエラーが起こった前後10バイトずつ切ってるんですね。
utf-8の境界を無視してぶった切ったバイト列がコンソールに表示されているので、
???と表示されても仕方ありません。
??のなぞが解けたんですが、エラーの意味がまだわかっていないので、
encoding.py に添付のパッチをあててバグを再現してもらえませんか？
fromlocal() の引数に渡る時点で欠けているもしくはゴミがついているのであれば、
このパッチで判断できると思います。
--
Naoki INADA <songof...@gmail.com>
Shun-ichi GOTO
> 稲田です。
>
> 機能追加の前後にある???の意味がわかりました。
> mercurial.encoding.fromlocal の中で、エラーメッセージをこのように出力しています。
>
> try:
> return s.decode(encoding, encodingmode).encode("utf-8")
> except UnicodeDecodeError, inst:
> sub = s[max(0, inst.start-10):inst.start+10]
> raise error.Abort("decoding near '%s': %s!" % (sub, inst))
>
> デコード時にエラーが起こった前後10バイトずつ切ってるんですね。
> utf-8の境界を無視してぶった切ったバイト列がコンソールに表示されているので、
> ???と表示されても仕方ありません。
ですね。ただ最初のメールのエラーでは、この "?" は前後のほかに
"加" の字ののころにもあります。これが hg ci -m "機能追加"での
1文字欠如と同じことが起きてるのだろうと思ってます。
'?機能追?
- CSS ?'
コミットログで"機能追加"の行と"- CSS..."の行の間に空行が
あったかどうかは分かりませんですが、あったとして、
"加" の3バイト目が欠けてLFが喰いこんで変換エラー(invalid data)と
なって、上のような表示に至ったのではないか、というシナリオを
思い浮かべてます。
そして hg ci -m "機能追加" のほうは喰いこむ後続バイトがないため
別のエラー(unexpected end of data)になる、と。
おそらくはfromlocal()の時点ではすでに欠けているので、
どこで欠けたがわからないと根治できませんねぇ。
--
Shun-ichi GOTO
INADA Naoki
> あったかどうかは分かりませんですが、あったとして、
> "加" の3バイト目が欠けてLFが喰いこんで変換エラー(invalid data)と
> なって、上のような表示に至ったのではないか、というシナリオを
> 思い浮かべてます。
なるほど
ただし、やはりHGENCODINGで直るというのがまだ意味がわからないので、
足場固めの意味で先ほどのパッチは当ててもらえればと。
後藤さんの意見を踏まえて、もう一つ仕込んでほしいのが、changelog.py の
changelog.add メソッドで、
user, desc = encoding.fromlocal(user), encoding.fromlocal(desc)
という行を見つけて、
+
+ import sys
+ print >>sys.stderr, "desc(A):", repr(desc)
+
+ # strip trailing whitespace and leading and trailing empty lines
+ desc = '\n'.join([l.rstrip() for l in desc.splitlines()]).strip('\n')
+
+ print >>sys.stderr, "desc(B):", repr(desc)
+
user, desc = encoding.fromlocal(user), encoding.fromlocal(desc)
のようにしていただけますか？
# バックアップ取らずに修正してしまってdiff取れない(汗
--
Naoki INADA <songof...@gmail.com>
Tommy
> コミットログを作るのに使用したエディタと同じでしょうか？
> sys.stdin.readline() を実行し、"機能追加"の漢字4文字を(コピペではな
> く)いつものように入力し、改行を入力すると正しく
> '\xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n' が得られますか？
> です。Windows でやるとこんな感じになり、『機能追加』文字列のバイト並
> びが見えますが、そちらの環境だと期待する12バイトのutf-8文字列になっ
> てますかね。
> ま保存して終るのではなくて、いつものようにファイルに保存後直ちに終了
> せず、その内容を別ファイルにも保存してみてくれませんか？ そしてその
> コミットが失敗したならば、その別ファイルの内容(バイト列)が参考になり
> ますので、そういうファイルが得られたならばzip してバイナリファイル添
> 付するか、od -x コマンドなどでHEXダンプしたテキストを見せて欲しい。
> 試してみて欲しい。現在有効なextension は hg showconfig extensions
> で得られます。
> 知れないので hg ci と実行する変わりに
> /opt/local/bin/python2.6 `which hg` ci として
> コミットしてみると成功したり、ということはありませんかね。
Tommy
INADA Naoki
あれ・・・出力が変わってないですね・・・
locate コマンド（ってMacにあるのかな？）等を使って、 mercurial/encoding.py という
ファイルがパッチを当てていただいたもの以外に存在しないか、もし存在しているので
あれば hg コマンドがそちらを実行していないか確認していただけますか？
--
Naoki INADA <songof...@gmail.com>
フジワラ
On 9月18日, 午前2:34, Tommy <tommy.heartb...@gmail.com> wrote:
> > できれば、hg ci の際に開いたテキストエディタで文面を入力した後そのま
> > ま保存して終るのではなくて、いつものようにファイルに保存後直ちに終了
> > せず、その内容を別ファイルにも保存してみてくれませんか？ そしてその
> > コミットが失敗したならば、その別ファイルの内容(バイト列)が参考になり
> > ますので、そういうファイルが得られたならばzip してバイナリファイル添
> > 付するか、od -x コマンドなどでHEXダンプしたテキストを見せて欲しい。
>
> すみません。これは、操作が分かりかねます…。単に '機能追加' とファイルに
> 書いて保存して、od -x すれば良いのでしょうか? それとも、commit タイミン
> グで特殊操作が必要でしょうか?
1. "hg commit"
2. 一時ファイル名を指定してエディタ起動
3. ファイルに保存してエディタ終了
4. 一時ファイルを "-l" 指定相当とみなして commit 処理続行
5. 一時ファイルを削除
というフローを想定していて、(5) で消される内容を (3) の前に
別名で保存しておいて、それを16進ダンプして欲しい、という依頼
だと思います。
徳富さんの作業フローがこれと異なる場合は:
a. コミットログをファイルに保存
b. "hg commit" に -l でファイル名を指定して実行
c. (期待通り)失敗することを確認
d. ファイルの内容を16進ダンプ
という手順でも大丈夫でしょう。
ちなみに "od -x" は 2byte 単位なので、環境によっては LSBF 表示
だったりしますから、"od -t x1" の方が良いと思います。
Shun-ichi GOTO
>> すみません。これは、操作が分かりかねます…。単に '機能追加' とファイルに
>> 書いて保存して、od -x すれば良いのでしょうか? それとも、commit タイミン
>> グで特殊操作が必要でしょうか?
>
> Shun-ichi GOTO さんはおそらく
ないすふぉろーです
そのとおりです。うまく伝えられなかった。
とはいえ 引数 -m で python には正しく伝わっていることが確認できた
(外部からpythonへの引き渡し時点では化けて/欠けてない)以上、
それほど重要ではないですので、気が向いたらで結構です。
--
Shun-ichi GOTO
Tommy
--
Y.Tokutomi
http://iddy.jp/profile/Tommy/
Tommy
--
Y.Tokutomi
http://iddy.jp/profile/Tommy/
INADA Naoki
内部で文字列を弄っている部分を疑ったのですが、それに入る前にすでに最後の
1バイトが欠けていますね・・・
もっと手前の部分を調べるパッチを作りました。先のパッチに追加で添付のパッチを当てて、
HGENCODINGを設定するパターン、設定しないパターンで試してみて下さい。
お手数をおかけしますが、よろしくお願いします。
--
Naoki INADA <songof...@gmail.com>
Tommy
INADA Naoki
うーん、コード追いかけても壊れてるらしき部分が見当たらなくなってしまいました。
私がchangelog.pyのパッチをちゃんと作れていなかったので、改行文字を取り除いたり
している部分の確認がうまく出来ていない可能性があるので、念のため changelog.py を添付の
ファイルに上書きしてもらえますか？
もうひとつ、 MacPorts のとそうじゃないの（？）で、
python -c "import string; print repr(string.whitespace)"
した結果を教えていただけますか？
2009/9/25 Tommy <tommy.h...@gmail.com>:
Naoki INADA <songof...@gmail.com>
INADA Naoki
http://mercurial.selenic.com/bts/issue1460
FreeBSDやMacOSXのlibcのバグで、ロケールをUTF-8に設定してしまった場合に
isspace('\xa0') が true になってしまうようです。
それで、changelog.py の中の
なんか、mercurialのバグトラッキングでは終了したことになってるけど、
import string
して
l.rstrip(string.whitespace)
すればこんな地雷なくなるのに・・・
2009/9/25 Tommy <tommy.h...@gmail.com>:
Naoki INADA <songof...@gmail.com>
フジワラ
やっと原因が解明されましたね！皆様お疲れ様でした。
On 9月25日, 午後5:17, INADA Naoki <songofaca...@gmail.com> wrote:
> なんか、mercurialのバグトラッキングでは終了したことになってるけど、
mercurial のバグトラックの msg8375 を見るに、以下の理由から
対応を諦めているような気が…
- purportedly fixed in newer versions of FreeBSD
⇒ FreeBSD の新版では直ったという「噂」が有る
- recent versions of Python supposedly have a workaround
⇒ 最新の Python には対応が入っていると「思われる」
なんて噂ベースな決定なんだ… orz
> import string
> して
> l.rstrip(string.whitespace)
> すればこんな地雷なくなるのに・・・
「面倒くさい」という判断が働いたのでしょう。
ちなみに、対応が入っていると思われる「最新の Python」って、
どの版を指すんですかね？ > パイソニスタの皆様
Tommy
> import string
> して
> l.rstrip(string.whitespace)
は
import string
desc = '\n'.join([l.rstrip(string.whitespace) for l in
desc.splitlines()]).strip('\n')
でいいんでしょうか…。
実行してみたところ、エラーが出ずに完了しました。
---
$ unset HGENCODING
$ hg status
logmessage: ' \xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n'
localrepo.commit: text= ' \xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n'
localrepo.commit: desc= ' \xe6\xa9\x9f\xe8\x83\xbd\xe8\xbf\xbd\xe5\x8a\xa0\n'
$
---
2009/9/25 INADA Naoki <songof...@gmail.com>
Y.Tokutomi
http://iddy.jp/profile/Tommy/
INADA Naoki
> ちなみに、対応が入っていると思われる「最新の Python」って、
> どの版を指すんですかね？ > パイソニスタの皆様
http://svn.python.org/view/python/trunk/Include/pyport.h?r1=36519&r2=36793&pathrev=36793
Wed Aug 4 06:33:51 2004 UTC
えーっと、少なくともPython2.4には入ってますね。
#ifdef __FreeBSD__
#include <osreldate.h>
#if __FreeBSD_version > 500039
となっているのですが、このマクロが Mac OS X では効かないんでしょうか。
--
Naoki INADA <songof...@gmail.com>
INADA Naoki
> 稲田です。
>
>> ちなみに、対応が入っていると思われる「最新の Python」って、
>> どの版を指すんですかね？ > パイソニスタの皆様
>
> http://svn.python.org/view/python/trunk/Include/pyport.h?r1=36519&r2=36793&pathrev=36793
> Wed Aug 4 06:33:51 2004 UTC
> えーっと、少なくともPython2.4には入ってますね。
>
> #ifdef __FreeBSD__
> #include <osreldate.h>
> #if __FreeBSD_version > 500039
>
> となっているのですが、このマクロが Mac OS X では効かないんでしょうか。
>
効いていなかったようです。
Pythonのissue trackerに登録しておいたので、 Python 2.6.4 が出るころには
Python側で対策されるかもしれません。
・・・というか、こんな古いバグ持ち出すなよ・・・ >apple
--
Naoki INADA <songof...@gmail.com>