コグノスケ


link 未来から過去へ表示  link 過去から未来へ表示(*)

link もっと前
2013年9月26日 >>> 2013年10月9日
link もっと後

2013年10月1日

JetBrains PyCharm 3.0リリース

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

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

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

編集者:すずき(2013/10/02 20:41)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2013年10月2日

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

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

編集者:すずき(2013/10/03 01:28)

コメント一覧

  • hdkさん(2013/10/03 08:37)
    「以上のリポジトリをサーバ上に移し」の部分を、hg clone . ssh://サーバー/hoge みたいな方法で行うと最初から null になりますね。あるいはサーバー上で init した後そこに push するとか。Git だと clone で「リモートに複製」ができないので後者しかない。
  • すずきさん(2013/10/03 21:26)
    >hdk さん
    はい、ローカルに push でも OK だと思います。
    ローカルでリポジトリ複製する場合は、clone -U で作業ディレクトリを無視して clone してくれます。
    clone し忘れて cp や rsync でコピーしてしまったら update -C null の出番です。
open/close この記事にコメントする



2013年10月5日

Python初歩で既に挫折気味

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

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

Pythonにおけるバイト列

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

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

bytesオブジェクトの要素、bytesオブジェクトのスライスの型
Python 3.3.2(Windows), Python 3.2.3(Linux)
>>> type(b'abc'[0])
<class 'int'>
>>> type(b'abc'[0:1])
<class 'bytes'>
bytearrayオブジェクトの要素、bytearrayオブジェクトのスライスの型
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のリファレンスをご参照ください。

array.arrayオブジェクトの生成
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の仕様を見る限り、要素の型は配列の各要素の型になるはずです。しかし…、

bytearrayのメモリビューの要素、スライスの型
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型の要素を参照した場合は、さらに具合が悪いです。

array.array('l') のメモリビューの要素、スライスの型
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使いはこういう問題にどうやって対処しているのでしょう?

編集者:すずき(2013/10/05 18:53)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2013年9月26日 >>> 2013年10月9日
link もっと後

管理用メニュー

link 記事を新規作成

<2013>
<<<09>>>
1234567
891011121314
15161718192021
22232425262728
2930-----

最近のコメント5件

  • link 24年10月1日
    すずきさん (10/06 03:41)
    「xrdpで十分動作しているので、Wayl...」
  • link 24年10月1日
    hdkさん (10/03 19:05)
    「GNOMEをお使いでしたら今はWayla...」
  • link 24年10月1日
    すずきさん (10/03 10:12)
    「私は逆にVNCサーバーに繋ぐ使い方をした...」
  • link 24年10月1日
    hdkさん (10/03 08:30)
    「おー、面白いですね。xrdpはすでに立ち...」
  • link 14年6月13日
    2048player...さん (09/26 01:04)
    「最後に、この式を出すのに紙4枚(A4)も...」

最近の記事3件

  • link 24年10月28日
    すずき (10/30 23:49)
    「[Linuxからリモートデスクトップ] 目次: Linux開発用のLinuxマシンの画面を見るにはいろいろな手段がありますが、...」
  • link 23年4月10日
    すずき (10/30 23:46)
    「[Linux - まとめリンク] 目次: Linux関係の深いまとめリンク。目次: RISC-V目次: ROCK64/ROCK...」
  • link 24年10月24日
    すずき (10/25 02:35)
    「[ONKYOからM-AUDIOのUSB DACへ] 目次: PCかれこれ10年以上(2013年3月16日の日記参照)活躍してく...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 10/30 23:49