コグノスケ

JetBrains PyCharm 3.0 リリース

PyCharm がメジャーアップデートされ PyCharm 3 がリリースされました。

特筆すべきは IntelliJ IDEA に続き、PyCharm にも Community Edition が追加されたことです。つまり基本的な機能は「タダ」で使えるということです。ただ個人的にはショックでした…。

なぜならこのあいだ（2013年 8月 7日の日記参照）一念発起して Personal Edition のライセンスを購入したばかりだからです。まさかこのタイミングで Community Edition がリリースされるとは、なんと間の悪い…。

Mercurial 作業ディレクトリの容量節約

Mercurial で下記のような集中式リポジトリ「風」の運用をしているとします。その運用なら Subversion でも良いんじゃないの？ってツッコミはさておき…。

• リポジトリサーバにマスターの役目を果たすリポジトリを置く
• 各開発者はマスターリポジトリに hg pull/hg push する

このときリポジトリサーバ上で開発するという運用はまずしないので、マスターリポジトリの作業ディレクトリ（Working directory）に存在するファイルは誰も使いません。残しておいても害はありませんが、ストレージ容量を無駄に消費します。

イメージ沸きにくいと思うので、下記のリポジトリを使って説明します。

#### 適当なリポジトリを作成 ####

$ hg init

$ echo a > file_a
$ echo b > file_b

$ hg add file_a file_b

$ hg status
A file_a
A file_b

$ hg commit -m 'add files.'

#### 以上のリポジトリをサーバ上に移し、マスターリポジトリとした ####

このように作成したマスターリポジトリの作業ディレクトリには、当たり前ですが file_a と file_b が含まれています。

これらのファイルを rm コマンドで強引に消しても構いませんが、Mercurial の作業ディレクトリのキャッシュ（.hg/dirstate）が残ったままになって、やはり容量が無駄です。

#### 作業ディレクトリ内のファイルを確認 ####

$ ls
file_a file_b

#### 作業ディレクトリの状態を確認 → 結果: 変更点なし ####

$ hg status

#### 作業ディレクトリ内のファイルを強引に削除 ####

$ rm file_a file_b

#### 作業ディレクトリの状態を確認 → 結果: ファイルが存在しない状態 ####

$ hg status
! file_a
! file_b

#### 作業ディレクトリのキャッシュも残ったまま ####

$ ls -la .hg/dirstate
-rw-r--r--  1 user       users  86 Oct  3 01:09 .hg/dirstate

#### ちなみに dirstate は 1000 ファイルくらいのリポジトリでも 70KB 程度で、
#### 大した容量ではないです。

何よりも邪魔なのは hg status を実行すると、大量の「! filename」状態（リポジトリには存在するが、作業ディレクトリにはファイルが存在しない、という状態）が表示されることです。

そんなお悩みを解消するのが、hg update -C null です。作業ディレクトリを綺麗さっぱり消してくれて、hg status にも文句を言わせないのです。

#### 作業ディレクトリを削除 ####

$ hg up -C null
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

#### 作業ディレクトリにファイルはない ####

$ ls

#### 作業ディレクトリの状態 → 結果: 変更点なし ####

$ hg status

#### 作業ディレクトリのキャッシュサイズも縮小 ####

$ ls -la .hg/dirstate
-rw-r--r--  1 user       users  40 Oct  3 01:15 .hg/dirstate

「ゴミ」が残っているのが気になる、または、気になっていた方はぜひお試しあれ。

Python 初歩で既に挫折気味

Python の初歩と思われるバイト列処理で、既に挫折気味です…。

Ruby やら Lua やらの、他の動的型言語はどうしているんだろう…。この手の問題が多発したら、私の弱い心は挫折してしまいそうです。

Python におけるバイト列

Python 3 は文字列とバイト列を明確に区別しています。バイト列の表現には 2種類あり、bytes 型は読み取り専用のバイト列を表し、bytearray 型は読み書き可能なバイト列を表します。それぞれ、組み込み関数 bytes() と bytearray() で生成します。

Python 3 からバイト列リテラルが追加され、bytes 型を生成する際に bytes('abc', 'ASCII') から、b'abc' のように書けるようになったそうです。ふーん…。

Python 3.3.2(Windows), Python 3.2.3(Linux)
>>> type(b'abc'[0])
<class 'int'>
>>> type(b'abc'[0:1])
<class 'bytes'>

Python 3.3.2(Windows), Python 3.2.3(Linux)
>>> type(bytearray(b'abc')[0])
<class 'int'>
>>> type(bytearray(b'abc')[0:1])
<class 'bytearray'>

なおバイト列（bytes と bytearray オブジェクト）の要素は 0 から 255 までを取る整数型（int）となります。従って b'abc'[0] + 1 の結果が 98 となるなど、要素に対する計算が可能です。

アレイ

バイト列だけではなく、整数列や、浮動小数点列はないのか？という疑問にお答えするのが、array.array 型です。この型により要素のバイト長が 1 以外の配列を扱えます。

オブジェクト生成の際 array.array() の第一引数により、配列の要素の型が決定されます。指定可能な型の一覧は、Python のリファレンスをご参照ください。

Python 3.3.2(Windows), Python 3.2.3(Linux)

#### 長整数型（singed long, 1要素 4バイト）の配列を作成

>>> import array
>>> a = array.array('l')
>>> a.itemsize
4

#### 要素の追加

>>> a.append(1)
>>> a.append(12345678)
>>> a
array('l', [1, 12345678])

#### 要素とスライスの型

>>> a[0]
1
>>> type(a[0])
<class 'int'>

>>> a[0:1]
array('l', [1])
>>> type(a[0:1])
<class 'array.array'>

#### signed long 型の値域から外れる値は追加できない

>>> a.append(11111111111111111111111111111111111)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

以上の bytes, bytearray, array.array の 3つの型はいずれもバッファプロトコルという、内部のメモリをオブジェクトの外に見せる仕組みを持っています。

この仕組みにより、以下に述べるメモリビューを使ってオブジェクト内部のメモリをコピーすることなく読み書きすることができます。

バイト列のメモリビュー

オブジェクトの持つメモリをコピーすることなく読む（可能なら書く）ために使うのが memoryview 型です。

オブジェクトの持つメモリが何の配列に見えるか？は、見たいオブジェクトに依存します。signed long として見せてくるオブジェクトもあるでしょうし、バイト列として見せてくるオブジェクトもあります。

オブジェクトが内部メモリをどう見せてくるにせよ memoryview の仕様を見る限り、要素の型は配列の各要素の型になるはずです。しかし…、

Python 3.3.2(Windows)
>>> type(memoryview(bytearray(b'abc'))[0])
<class 'int'>
>>> type(memoryview(bytearray(b'abc'))[0:1])
<class 'memoryview'>

Python 3.2.3(Linux)
>>> type(memoryview(bytearray(b'abc'))[0])
<class 'bytes'>
>>> type(memoryview(bytearray(b'abc'))[0:1])
<class 'memoryview'>

なぜか Python 3.2 では要素の型が「bytes」になっています。おかげで memoryview(...)[0] に対して加減乗除、ビット演算する個所が全滅です。

無理やり memoryview(...)[0][0] として切り抜けることも不可能ではありませんが、今度は Python 3.3 で動かなくなるので困りものです。

整数列のメモリビュー

ちなみにメモリビューによって long 型の要素を参照した場合は、さらに具合が悪いです。

Python 3.2.3(Linux)
>>> import array
>>> a = array.array('l')
>>> a.append(0x01234567)
>>> a.append(0x79abcdef)
>>> a
array('l', [19088743, 2041302511])

>>> type(memoryview(a)[0])
<class 'bytes'>
>>> type(memoryview(a)[0:1])
<class 'memoryview'>

>>> memoryview(a)[0]
b'gE#x01'

なんと 4要素の bytes が返ってきます…。これを一々 int に組みなおすのも大変だし、値をコピーせずに参照できる、という利点が完全に死んでる気がします。

せめて何か言ってくれよ Python さん

もしかして Python 3.2 と 3.3 で memoryview の仕様が変わったんでしょうか？

C や Java ならコンパイル時に「型が違うぜ！」って怒られて気づきますが、Python は実行時にクラッシュするまで何も言ってくれません。世の中の Python 使いはこういう問題にどうやって対処しているのでしょう？

Windows 8 のリモートデスクトップ

ノート PC（Windows 8 Pro）からサブ PC（Windows 8 Pro）にリモートデスクトップで接続したまま、ノート PC をスリープしたら、サブ PC に二度と接続できなくなりました。

ノート PC からサブ PC に、何度接続しなおしても「このコンピューターへの接続数は制限されていて、すべての接続は現在使用されています。後で接続するか、またはシステム管理者に問い合わせてください。」と言われるばかりで接続できません。

試しに別のデスクトップ PC（Windows 7 Ultimate）からサブ PC に接続してみましたが、同様のエラーメッセージが出るばかり。

同じことを Windows 7（デスクトップ PC）にやってもこんなエラーは起きないのですよね。Windows 8（サブ PC）がおかしいのかなあ…？

そもそもログインすらできない

その後、サブ PC にキーボードとマウスを繋いで直接ログインしてみたのですが、全く同じエラーが出ました。もうダメだこれ。

意味が良くわからんまま、とりあえず再起動したら直りました。一体、何だったんでしょうなあ…。

Windows 8.1

最近 Windows 8 のストアアプリを起動すると「僕と契約して、無料で Windows 8.1 にアップグレードしてよ！」と超オススメしてきます。しばらく無視してたんですが、せっかくオススメしてくれているのでアップグレードしてみました。

ストアアプリさん曰く、アップグレードファイルのサイズは 3GB 超と、DVD 1/2 枚に相当するデータ量です。このサイズでもネットワーク経由で配布してしまうんですね。さすがに光回線でもダウンロードに時間かかりますが…。

何が変わったんだろう

アップグレードは特に問題なく終わり、無事 Windows 8.1 になりました。噂通り、スタートボタンが復活していますが、他にはさほど変化を感じません。アップグレードと言うより、サービスパック 1 的な位置づけなのでしょうか？

良いところ

今のところアップグレードして良かった点は、ONKYO の SE-U33GXV2 を 24bit モードで使っても変な音が鳴らないことです。

あと内蔵オーディオのエフェクタがおかしいぜ！無効にするかい？って聞いてくるようになりました。何でだろう？ひとまず ONKYO 君が居れば内蔵オーディオは用済みなので、内蔵オーディオデバイス、エフェクタ、もろもろ全部を無効にしておきました。

悪いところ

逆にアップグレードして悪かった点は、頻繁に WiFi が途切れることです。

Windows 8 のときもスリープから復帰させた後は、WiFi が怪しい挙動を示していましたが、Windows 8.1 だと何の前触れもなく通信できなくなることが多くなり、激しく劣化しました。かなり使いづらいです…。

いずれにせよ原因は良くわかりません。使っているノート PC 自体がイマイチなのかもしれないなあ…。

VirtualBox 4.3

VirtualBox 4.3 のアップデートが出ていたので適用してみたら、Windows 8.1 x64 版と非常に相性が悪いらしく「CRITICAL_STRUCTURE_CORRUPTION(0x00000109)」で BoD しまくります。短ければ 数十分で、長くてもせいぜい 1時間で死んでしまいます。

VirtualBox のフォーラムにトピックがあったので読んでみたら、「Arg 4 が 0x00000007 つまり 7: Critical MSR modification って言われるぜ！」「俺も！俺も！」的な書き込みがありました。

私を含め、世界中で同じエラーに悩まされている人が居ることはわかりましたが、肝心の解決方法が良くわかりません。困ったね。

とりあえずダウングレードするしかないかな…。