最近の(でもないけれど)出来事/落書帳/仲間内のネタ/覚え書き/whatsnew

基本的に落書き帳/メモ帳/備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。


Sun,01 Apr,2012

年度替わり。
読み方

気閘 : きこう

安穏 : あんおん、あんのん

通函 : かよいばこ、つうかん

Thu,05 Apr,2012

「未来の二つの顔」 J.P.ホーガン

終章またまた急いでまとめた感じが。

楽天的なエンディング。 この結末は無理がありすぎる気がする。

Fri,06 Apr,2012

Anthy:拙作パッチの安定版(release)のパラメータチューニング:

かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ

辞書化した文節区切り情報を利用する機能の パラメータチューニングが悪いらしく、 たとえば「ごごからはきゅうなあめにちゅうい」とか変換すると 滅茶苦茶な文節区切りを提示してくる。

そもそもこの機能を無効にしたい方は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-1
にて無効化できます。

また、本機能の効き目を無効にはしないけれど 弱めに調整したい場合は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 3.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 7.6e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 3.6e-8
とかして下さい。 値を小さくすればするほど、本機能の効き目が弱くなります。

Sat,07 Apr,2012

Anthy:試験版に読み仮名ベース文字 変則2グラムを実装してみた。

一部の界隈で騒がれている(らしい) 統計的かな漢字変換のNグラム方式が、そんなに良いのか、 と気になったので、読み仮名ベース文字 変則2グラムを実装してみた。 単語2グラムとか文節2グラムとかじゃない辺り日和ってる。 本来のNグラムの漢字表記のデータが付いておらず 読み仮名のみの変則であるのは、 Anthy の構造上、文節区切り判定の際に表記の一致判定を行うと、 使い物にならないくらい処理が遅くなる為。

${HOME}/.anthy/conf に
#
YOMICHAR2GRAM_MODE true
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-8
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_UCDIC 0.0e-1
#MBR_MODE_LATTICE_BIASPROB_BY_OCHAIRE 6.6e-1
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2KY 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2T 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2D 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_PRE_CORE 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_CORE_POST 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_PRE_CORE 0.0e-12
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_CORE_POST 0.0e-12
LATTICE_BIASSCORE_BY_COMPOUND 0.0
LATTICE_BIASSCORE_BY_CORPUSUDIC 0.0
LATTICE_BIASSCORE_BY_UCDIC 0.0
#LATTICE_BIASSCORE_BY_OCHAIRE 1000.0
#LATTICE_BIASSCORE_BY_LEARNEDFREQ 10.0
#LATTICE_BIASSCORE_BY_DEPHISTORY 5.0
#
を追加すると、 読み仮名ベース文字 変則2グラムモードで文節区切りを行ないます。

数分試してみましたが、結構無難な候補が出るのね……。 ちょくちょく変な文節区切りも出てくるけれど。 読み仮名ベース文字 変則2グラムで ここまでまともな変換結果が出るとは思わなかった。

Sun,08 Apr,2012

Anthy:拙作パッチの安定版(release) のパラメータ調整。

かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ

今回追加した 辞書化した文節区切り情報を利用する機能の パラメータチューニングがまだ悪いらしく、 調整してみた。

そもそも今回の機能を無効にしたい方は、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-1
として下さい。

Mon,09 Apr,2012

Anthy:拙作パッチの試験版に読み仮名ベース変則単語 変則2グラムを実装してみた。

かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ

一部の界隈で騒がれている(らしい) 統計的かな漢字変換のNグラム方式が、そんなに良いのか、 と気になったので(その2)、 読み仮名ベース変則単語 変則2グラムを実装してみた。
その2と言うのは、 その1が読み仮名ベース文字 変則2グラム、 その2が本日の読み仮名変則単語 変則2グラム。 何が変則かと言うと、 助詞(Anthy で言う所の付属語)は 2単語以上連続していても1単語と数えているので。
文を変換する際、コーパスに該当する内容が全く見つからない場合、 文節数最小法と等価になります。

${HOME}/.anthy/conf に
#
YOMIWORD2GRAM_MODE true
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-5
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-8
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_UCDIC 0.0e-1
#MBR_MODE_LATTICE_BIASPROB_BY_OCHAIRE 6.6e-1
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2KY 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2T 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_D2D 0.0e-7
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_PRE_CORE 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_NN_CORE_POST 0.0e-4
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_PRE_CORE 0.0e-12
MBR_MODE_LATTICE_BIASPROB_BY_COMBINED_CORE_POST 0.0e-12
LATTICE_BIASSCORE_BY_COMPOUND 0.0
LATTICE_BIASSCORE_BY_CORPUSUDIC 0.0
LATTICE_BIASSCORE_BY_UCDIC 0.0
#LATTICE_BIASSCORE_BY_OCHAIRE 1000.0
#LATTICE_BIASSCORE_BY_LEARNEDFREQ 10.0
#LATTICE_BIASSCORE_BY_DEPHISTORY 5.0
#
を追加すると、 読み仮名ベース変則単語 変則2グラムモードで文節区切りを行ないます。

100文の変換所要時間を見てみると……、
MBRダイクストラ : 3.5秒
読み仮名ベース文字 変則2グラム : 3.1秒
読み仮名ベース変則単語 変則2グラム : 3.7秒
MBRダイクストラより遅くなっているし……。

Tue,10 Apr,2012

Anthy:拙作パッチの試験版に読み仮名ベース変則単語 変則2グラムを実装してみた。

かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ

文頭/文末の確率計算をちょっと修正。

Sun,15 Apr,2012

断線

秋月の DC-DC Step Up レギュレータを使う際に、 ヘッダーピンがじゃまなのでニッパで切った。
で、配線つないで電源入れても出力が出てこない。
テスタで追っかけてみた所、 ヘッダーピンをニッパで切った付近のパターンが一緒に切れて断線していた。 ああ…… orz

紫外線ブラックライトの自作

Fri,02 Sep,2011の続き。

ふと気づくと半年以上あいているのだが。
以前買った 5mm 砲弾型 UV-LED 365nm 10個セットを使って、 今更ようやく懐中電灯*2個に組み立てた。 自作と言うか、組み立てたと言うか、 既存の 100円 1玉 白色 LED マグライトをベースに、 LED 増設の穴を掘って、 玉を UV-LED に交換して3玉付けた物と6玉付けた物の2種類を用意して、 DC-DC 付けて昇圧して、 しただけだが。

定格通り 約 20mA で駆動したのだが、 秋月の DC-DC の出力電流が足りないらしく 3玉でも6玉でも明るさが大して変わらなかった。 いやまあ出力電流が足りないのは 事前に秋月の web サイトのカタログを見て知ってはいたけれど。 それでも微妙に6玉の方が明るくはあった。 しかし6玉でもホルキンで買った 電池 6V 直結 1玉 100mA オーバードライブな UV-LED キーライトと 同じ位の明るさだった。 概算で3玉が 60mA、6玉が 120mA、だから、そんなものかな。 定格越え5倍駆動なキーライト、よく焼損しないものだなぁ……、 寿命が1万時間とか数千時間とかに縮まっているのだろうか。

あと、定格駆動でも青紫色に発光しているのが見えた。 赤外線 LED だと発光が全く見えないので、 同じ感覚で 紫外線 LED も発光が見えないものと思い込んでいたのだけれども。 そんなものなのかな。 データシート見てみればいいのだろうけれど。
紫じゃなくて青紫色に見えるのだよなぁ……。 紫外線で発光するインクもちゃんと発光する辺り、 紫外線もちゃんと出ているのだろうけれど。 なんか変な感じ。
なお、紫外線保護眼鏡無しで直視は危険が危ない。

Wed,12 Feb,2020に続く。

Tue,17 Apr,2012

「未来からのホットライン」 J.P.ホーガン

オチがついていない気がする。

Sat,21 Apr,2012

UTF-8 GearHead2

UTF-8 GearHead-2

GearHead2 とか GearHead Arena-R とかに関して、 「プログラムはわからないけれど翻訳はできる」(意訳)と 言う方が したらば にちょくちょく現れるっぽいので、 プログラムの UTF-8化だけでもできるかどうか試してみた。
そしたら GH2 は、あっさり対応できた。 しかも文字列の 255Bytes超過にも もとから対応済だった。

本音の所は、 未完了のソフトウェアに対するパッチは作りたくないんだけれども。 本家の GH2 が1年半以上止まっていると言うのと。 翻訳マダーと言う人がちょくちょく現れるので、 じゃぁ自分で翻訳してみて下さい、と言うのと。

I18N とか L10N とか M17N とかまでやる気力は無し。

GearHead Arena-R

GearHead Arena-R は、 コンパイルは通るものの、実行すると

LoadSAttScripts ERROR: [string "LoadSAttScripts"]:1: unexpected symbol
  line: "       GG_PERSONANODE = -23;"
LoadLuaConstants ERROR: attempt to call a string value
GH_INIT ERROR: gamedata/gh_init.lua:242: table index is nil
Register ERROR: Cannot register before LUA_IS_GO
Register ERROR: Cannot register variables before LUA_IS_GO
HandleTrigger ERROR: attempt to call a nil value

とかでて lua がこける。
本家 Forum によると、 「FreePascal の amd64版だと駄目。i386版を使って」(意訳) らしい。
手元のマシンは amd64版の OS しか入れていないので、 UTF-8 対応とか日本語対応とかの作業以前に 本家英語版の再現すら駄目っぽい。 amd64上の OS から i386板の FreePascal を駆動できないかと fpc をいじってみたが、 amd64版と i386版の相互クロスコンパイルはできないっぽい。 FreePascal を i386 のエミュレーションとか wine32 とかで実行してまで 開発する気力も無いし。

Sat,19 Oct,2013に続く。

Sun,22 Apr,2012

UTF-8 GearHead2

UTF-8 GearHead-2

チマチマ作業していたら、 %JS %JF %JG 対応できたっぽい……。 行き当たりばったりな作業の仕方をしているのでかなり難があるけれど。

2年半ぶりに Pascal をいじったのだが、 プログラミング言語って案外覚えているものだなあ。 GearHead1 のソースコードの 何処に何をどうやって改造したかの方は覚えていないけれど それは何の言語の何のプログラムであってもフツーだし。 言われるまで %JS %JF %JG の存在すら忘れていたし。

Anthy 読み仮名ベース変則単語 変則2グラム

うーん、 手放しで褒められるほど、良くは無い感じ……。 alt-cannadic/alt-depgraph にする前の Anthy の MBR-Viterbi よりは 許せる様な気がするけれど。気がするだけ。 alt-cannadic/alt-depgraph を搭載した MBR の方が 良い様な気もしなくもないけれど変わらない気もするし。
Nグラムは、2桁違いのコーパスが必要なのかなぁ。 1万6千文位のコーパスじゃ足りないのかなぁ。

Mon,23 Apr,2012

UTF-8 GearHead2

UTF-8 GearHead-2

%JS %JF %JG と UTF-8 な文字を続けて書くと空白が入るとかで。
series と gamedata で、文字列のパースしている箇所が違うのね orz
gamedata は余計な空白が入らない様に修正済みだったのに、 series は忘れていたというか気付かなかった。
直した。

Wed,25 Apr,2012

弁当

boxed lunch

lunch box と言うと、 弁当箱(中身を含まない、箱だけ)に なってしまうらしい。

svn メモ

Fri,28 Aug,2009、 の続き。

タイムスタンプをリビジョン表記に使う:
svn propset --revprop svn:date "2009-07-01T00:00:00.000000Z" -r 123456

svn co とか svn export したディレクトリを、ファイル名順ソートで tar に固める:
find anthy-9100h \! -type d | grep -v "/.svn/" | sort | tr \\n \\0 | xargs -0 tar -cvf - | lzma -9 > tar.lzma

sourceforge.jp にあるレポジトリをレポジトリのままローカルにコピーする:
cd path-to-repository
svnadmin create gearhead1-i18n
svnsync init file:///path-to-repository/gearhead1-i18n http://svn.sourceforge.jp/svnroot/gearhead1-i18n
svnsync sync file:///path-to-repository/gearhead1-i18n

Wed,04 Mar,2020 追記:
tar の引数を xargs で渡すのはマズい。

Sun,25 Aug,2019Wed,04 Mar,2020、 に続く。

Sat,05 May,2012

*band

Mac で hengband-lua 2.0 が動かないと聞いて、 もしかして GearHead Arena-R を amd64 で動かすと lua がこける件の手がかりになるか、と思って追跡調査してみた。

結論から言うと lua は関係無くて、 amd64 非対応なバグ?だった。 原因箇所のソースコードを見てもらった方がはやい。

diff src/h-type.h.org src/h-type.h
--- src/h-type.h.org    2012-05-05 14:02:28.000000000 +0900
+++ src/h-type.h        2012-05-05 14:28:13.000000000 +0900
@@ -113,17 +113,12 @@


 /* Signed/Unsigned 16 bit value */
-typedef signed short s16b;
-typedef unsigned short u16b;
+typedef int16_t s16b;
+typedef uint16_t u16b;

 /* Signed/Unsigned 32 bit value */
-#ifdef L64     /* 64 bit longs */
-typedef signed int s32b;
-typedef unsigned int u32b;
-#else
-typedef signed long s32b;
-typedef unsigned long u32b;
-#endif
+typedef int32_t s32b;
+typedef uint32_t u32b;



amd64 だと L64 は undef になっている。
うむ。見事にアレだ。
この型宣言のせいで乱数生成関数が 64bit で乱数を生成してしまっていて、 その返値が 32bit で収まる様になるまで乱数生成を繰り返している。

しまった。 #include <stdint.h> を忘れてる……。

で、これって *band 全般に該当するのではないかと思うのだが、 ちょっと探してみたら angband の総本山とか日本語化サイトとか、 あらかた消滅してしまっている。 *band の時代は過ぎたのか……。

zangband は SIZEOF_LONG_INT > 4 なら L64 を define する 方向で直してあり、 zangband の www.koders.com は #if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L) || defined HAVE_STDINT_H なら uint16_t/int16_t/uint32_t/int32_t を使う方向で直してあった。

mangband は L64 を define する方向で直してあり、 mangband の trunk は #define __STDC_FORMAT_MACROS な 方向で直してあった。

って、一人で *band 全部調べるのは無理だぞ。

Mon,07 May,2012 追記:
angband の総本山は見つかった。

stdint.h を使う方向で直してあった。

となると、hengband だけが追従できていないのかな?

Sun,06 May,2012

メモ:C99/C++

bool : stdbool.h

uint*_t / int*_t / uint_least*_t / int_least*_t / uint_fast*_t / int_fast*_t / uintptr_t / intptr_t / uintmax_t / intmax_t : stdint.h

INT*_MIN / INT*_MAX / UINT*_MAX / INT_LEAST*_MIN / INT_LEAST*_MAX / UINT_LEAST*_MAX / INT_FAST*_MIN / INT_FAST*_MAX / UINT_FAST*_MAX / INTPTR*_MIN / INTPTR*_MAX / UINTPTR*_MAX / INTMAX*_MIN / INTMAX*_MAX / UINTMAX*_MAX : #define __STDC_LIMIT_MACROS して stdint.h

INT*_C() / UINT*_C() / INTMAX_C() / UINTMAX_C() : #define __STDC_CONSTANT_MACROS(C++)して stdint.h

PRId* / PRIdLEAST* / PRIdFAST* / PRIdMAX / PRIdPTR など : #define __STDC_FORMAT_MACROS(C++)して inttypes.h (自動的に stdint.h を読み込む)

Tue,08 May,2012

/dev/ptyp0

FreeBSD 10-CURRENT を5月5日号に更新したら mlterm が動かなくなった。
mlterm をビルドする際に -DDEBUG して、 エラーメッセージの詳細を見てみたら、

WARN: [ml_term.c:184] ml_pty_new failed.
DEBUG: [deleting child windows]
DEBUG: [deleting child windows]
DEBUG: [deleting child windows]
DEBUG: X connection closed.
WARN: [x_screen_manager.c:1334] open_screen_intern() failed.
WARN: [main_loop.c:453] open_screen_intern() failed.
Unable to start - open_screen_intern() failed.

とか言ってくる。
意味が判らなかったのでデバッガで追跡。
/dev/ptyp0 が無いのが原因らしい。
どうも FreeBSD が /dev/?ty?? から /dev/pts/? に移行した為に /dev/ptyp0 が無くなったらしい。
/boot/loader.conf で pty_load="YES" したら、 /dev/ptyp0 が使える様になった。

uim-1.8.0

FreeBSD にも uim-1.8.0 が来ていた。
アップデートしてみたのだけれども、 ステータスポップアップが画面外に表示される事が有るのと、 モードに連動したステータスポップアップの表示/非表示が機能しないのが、 1.7.x系と変わらなかった。

と、言う訳で、 uim のステータスポップアップ改造パッチ 更新。

Sun,13 May,2012

FreeBSD 10-CURRENT r235068

FreeBSD 10-CURRENT を5月5日号に更新したら、 スレッド回りだかなんだかで Bus error の誤爆が出まくる様になった。

http://lists.freebsd.org/pipermail/freebsd-current/2012-May/033656.html らしい。

/usr/src を r235068 に更新して、 /usr/src/lib/libthr で make obj depend all install したら、 治った。

CURRENT はこの手の問題があるからなぁ……。 でも Intel_GPU 使うには CURRENT にするしかないしなぁ……。

Wed,16 May,2012

UTF-8 GearHead2

UTF-8 GearHead-2

MS-Windows での GDI での ASCIIモードにて、 バッキングストア(ダブルバッファ)にして、 ちらつかない様にした。

GearHead-1 だと、 バッキングストア(ダブルバッファ)にしなくても、 わりとちらつかない様な表示仕様だったのだけれども、 GH2 になってから表示の仕様が変更されて、 バッキングストア(ダブルバッファ)前提の実装になっていた。

Thu,17 May,2012

UTF-8 GearHead2

UTF-8 GearHead-2

MS-Windows での GDI での ASCIIモードでの バッキングストア(ダブルバッファ)を UNIX系に再移植。

ASCII での表示内容を一旦バッファに溜めて、 再表示実行時に UTF-8 を正しく表示できる様に再加工して Write()。

「正しく表示できる様に再加工」とは。
FreePascal のコンソール出力関数に UTF-8 を流し込むと、 UTF-8 の所謂全角1文字を ASCII 3文字相当として扱われてしまい、 例えば漢字 60文字を表示しようとすると、 ASCII 180文字ぶんとみなされてしまい 横幅 132文字のコンソールの場合だと 途中でぶった切られて改行されてしまう。
そこで、 UTF-8 の所謂全角を表示しようとする場合には、 カーソルを一旦上下の行に移動して再度元の行に戻してから、 1文字毎に区切り表示する、 と言う事をやっている。   FreePascal内にカーソル位置をキャッシュ?して カーソル位置の変更の最適化を行なっているらしく、 カーソルを一旦別の行に動かさないと、 FreePascal内のカラム位置の計算が狂うらしいので。

このへんは、GearHead1 の I18N化がらみで得たノウハウ。 GH2 の ASCIIモードで表示位置がメタメタに狂うのを見るまで、 すっかり忘れていたけれど。

Wed,23 May,2012

fvwm2

fvwm2 上で firefox を使っていると、 ダウンロードダイアログが マウスカーソルを強制移動させてしまい 困っていたのだが、対処法がようやく判明。

設定ファイルに以下を追加。

DestroyFunc UrgencyFunc
AddToFunc UrgencyFunc
+ I Iconify off
+ I Raise

何の事は無い、 fvwm2 のデフォルト設定で、 わざとマウスカーソルを強制移動させていただけだった。

わかってしまえば簡単なのだけれども、 これがわかるまでに gdb でトレースまでしたと言う……。

Thu,31 May,2012

Intel_GPU on FreeBSD in AS3820T-N52B

Fri,22 Jul,2011Wed,03 Aug,2011Thu,04 Aug,2011Thu,11 Aug,2011Fri,18 Nov,2011Sat,28 Jan,2012、 の続き。

Intel_GPUパッチが遂に HEAD(10-CURRENT) に commit されたらしい。 r235859 だそうだ。

KMS なドライバも i915 と drm から、 i915kms と drm2 に、 変わったらしい。

5月中旬頃の Intel_GPUパッチを使っているけれど、 4月以前の Intel_GPUパッチみたいな不安定さには遭遇していない。 以前はちょくちょく起動失敗したり フリーズしたりしていたけれど。

とか書いている時にフリーズ起こした。

Sat,09 Jun,2012 追記:
FreeBSD 10-CURRENT の HEAD に更新してみた。
xf86-video-intel を xf86-video-intel-2.17.0_1 に更新しないと Xorg が刺さった。
loader から load i915kms.ko すると、 起動画面が表示されないのでわけがわからなくなる。 xf86-video-intel を 2.17.0_1 に更新すれば、 Xorg 起動時に自動で kldload してくれるので、 その方が無難そう。

Sat,02 Jun,2012

fenix.ne.jp の非定期計画メンテナンス

6月15日(金)〜17日(日)にかけて、 非定期計画メンテナンスが行われる予定です。
メンテナンス中は、 本サイトに接続できなくなったり、 します。

Sat,09 Jun,2012

3820T で FreeBSD 10-CURRENT の make buildworld & make buildkernel

acer AS3820T-N52B は 第1世代 Core i5 でカタログ上は 2.4GHz まで出るのだけれども、 2.266GHz を越えるとサーマルシャットダウン起こすので、 2.133GHz をリミットにして常用している。 Hyper-Threading も切りたい所だけど、 HT 切るのに対応していないので切れない。
その状態だと、 make buildkernel には40分、 make buildworld には4時間、 かかった。

…… Core2 Duo 2.1GHz クラスの 1400x1050 SXGA+ な中古なら、 新品の 3820T-N52B 1366x768 の半値で買えたのか……。 今更だけれど。
あーでも Core2 Duo 近辺の世代だと液晶バックライトが蛍光管なのか。 中古の蛍光管式のバックライトは寿命が怖いしなぁ。

Sat,16 Jun,2012

DELETER NEOPIKO Line 02 ブラック 水性顔料

プラモデルのスミ入れに、 deleter ネオピコライン 0.03mm (黒)(水性顔料) ¥160- を使ってみた。
.Too コピック マルチライナー 0.03mm (黒)(水性顔料) ¥210- じゃないのは、 入手性と値段の問題。 近場の大きな文房具屋ではネオピコラインしか売っていなかったし、 たいして使わないなら安物でもいいや、と。
マックスファクトリー コピックモデラー 0.02mm (ウォームグレー)(水性顔料) ¥230- じゃないのは、 色の好みと値段の問題。 ニュートラルグレーが好みなのだが、 グレーだと 0.02mm ウォームグレー か 0.03mm ウォームグレー か 0.03mm クールグレー しか売っていない。

ガンダムマーカー スミ入れ用(極細)グレー/ブラック(油性)は スミ入れ後にはみ出した部分を拭き取る事前提だったけれど、 0.03mm ブラック(水性顔料) だと拭き取り不要で綺麗に仕上がった。
ただ、ブラックだけあってグレーよりも濃い。 白とか黄色とかにブラックだと濃くて好みに合わない。 あとは、 油性と水性顔料の違いが どんな感じなのかよく判らない点が残っているかな。

……ガンダムマーカー スミ入れ用(極細)グレーを紙に書いてみたら、 なんか濃い目のクールグレーな気がしてきた。

Sat,18 Jan,2014Wed,03 Dec,2014Fri,29 Sep,2017Sat,13 Jul,2019に続く。

Sun,17 Jun,2012

fenix.ne.jp の非定期計画メンテナンス

一応完了らしい。 乙です > wheel

bsd-tar on pefs(2011-12-25) in FreeBSD 10-CURRENT

Tue,07 Feb,2012、 の続き。

pefs 上で tar -cf を実行すると 「tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device」 が出るのだが、 これって何だろう?
webで検索しても情報が見つからないし。
メッセージの内容からすると、 pefs が SEEK_HOLE に対応していないっぽい雰囲気がするけれども、 はてさて?

pefs の Commit History 見たら何か書いてあった。
pefs: Prevent userland from assuming SEEK_HOLE/SEEK_DATA are supported
4db924ea65 Browse code
March 25, 2012
らしい。

Sat,06 Mar,2021Fri,30 Apr,2021、 に続く。

Thu,21 Jun,2012

読み方

黒鉄色 : こくてつしょく
黄橙色 : おうとうしょく
暗緑色 : あんりょくしょく
濃緑色 : のうりょくしょく
青竹色 : あおたけいろ
焼鉄色 : やきてついろ
明灰白色 : めいはいはくしょく

情報源 : http://www.excite.co.jp/News/bit/00091135197457.html

Sat,23 Jun,2012

url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEYAAAAOCAYAAACSJWqFAAAABGdBTUEAALGPC%2fxhBQAAAAlwSFlzAAALEgAACxIB0t1%2b%2fAAAAAd0SU1FB9oGAhENK17O5ogAAAAZdEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIEdJTVBXgQ4XAAAAGXRFWHRTb2Z0d2FyZQBQYWludC5ORVQgdjMuNS44NzuAXQAAA99JREFUSMfdlmtMm1UYx%2fkOM1vmBck2EIyZOiLZJRLlMhaXhQSjmRiHiVmi7gKpjshlBAiMhYG0C3UdinyYCUYMgm6MsYVLuV%2fLaArl1pYWGLQwJ6OIEeKnn%2bcdZc4CS6vDyJ7kn%2feck5Nz3vPL%2f3nO8fDYIDFpnwsZvjPL2Ss38T9eTFTmdzT0ahi9paUmJgKNvxejfl6M%2b3phFt8BX0%2b0vp4hHo97WO1zNJtvE5rdyLOJbXjHVZBbpsZo1TPSUIY%2byIdxAWRMyCSk932CTj9PHsnmcRk%2f%2bgv1COGQ1N7zfwAztbBIrWGKoKwWfFJv8vSpBqIVlWiNOkaH2tBGBWPxW3KNwXcTOvFtE3pUYN4QqhPa4uhLbct6HfaCUsmF%2fPwVPy%2bNOY%2fbFhZoH79DZH4nPkkd%2bCS0E5lbg2aoF4OuhcZDQbTt2kxL4Fbad26mS6RWk9%2bmv60RILciyXm%2fAIUYV1hxB9RpyTnrBsYBQALkDEv1wJgUgz%2ffxXB3jqzKAQKSGtnxWRMJpVq6BnUoFbnEhu7lZOgrfPD%2bXg7HvYTsyPOogp9iJQDbPTlDcRmM5BpHKpWtZ4pIAFQOGPegrOGi44X11A9PoLXNUNAwgrLOIPpjpJ3JoOr6DVo1AlJ3D58X5PFCShjbFK%2bzK%2fXVVdxh4y9A7kORUsriALPFhfk8TC47Z5UUWo6X4y8TlnaZ%2bEtqrvWZsPxqJ1ueR8XVq0zMLlCsn6dk8Hc6zb%2bQcz6HgPT9bJWHrbqWBMJf7iaUB2pLkavzk5Q%2f%2bT1MboFxSqHl2PdpKYGycnbGlpJW0olRpFVCSgrmyWkuaueZ%2fe0PrFN2SnR26scXkZ%2fPZ1tu%2bKpr3YciXwK0bmD%2bdZ1ZTiVHbVkNzlvpPyD7Ss3Zsg6%2bb%2b1FP2lBdkrG6ISNIq0d48g0tW0mCppttEwskph8Gu%2bs8DUL7X3XuAvnP4PiVGhVa9SZmn4LA5NGBkzl9Pcp6OlKISP9JDcqK%2flGgPm2eZxLHdMoNPOUNunIPJPF9nMHVtxKS25xLr421%2bA4HFO37mDcuK7NM5NoWtPR1gQz1BDIoDqQ8qJDvPfum3SIwlthWqB2bJHi2m4%2b%2fPgYkZ%2fE8ExmBK5cy86wNlQM3eqh48p%2bTOog8dINwqjeTX%2fVPgrPHSQ5OZmcPAVfXPyS9IS3UaX6Ex0bwZPxoRvzsO6E6baZ7usxDAkYw9XBGKpfw1gVTp86kbpujbit5LyY9g4HThwkP8mH6q%2bf4%2fBHkY8%2fGMuMNcQ42sxAU5IAc5ThmqOY2nOwTA9zTbx%2b9yhP4K2IZnv2EaJk0ahSvKku3PGPwfwJAW1Er1YzJJgAAAAASUVORK5CYII%3d)

httpd に、↑の様な謎のアクセスが去年くらいから来ている。

サーバメンテのついでに調べてみた。

最初に来たのは 26/Jun/2011:05:24:14 +0900 だった。

user-agent は
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; YTB730; GTB7.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1; YJSG3)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB7.1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR3.0.30729; .NET4.0C)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB7.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E; InfoPath.2)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; GTB7.1; EasyBits GO v1.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0 .30729; Media Center PC 6.0)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; .NET4.0C; .NET4.0E; BRI/2)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
など。
必ず Trident が入っている。 って、MSIE は必ず Trident が入るのか。

はてさて、何だろう?

Mon,25 Jun,2012

WBS

WBS にヨドバシカメラが出ている。 珍しい。 いつもならビックカメラを出すだろうに。


2012年の3に続く。


FENIX HomePage
G-HAL HomePage
Mail to, メールはこちらへ
Suggestion Box, 投書箱
BBS, 掲示板 UserName:BBS、Password:BBS
(C) 2012 G-HAL