Keep It Simple, i'm Stupid.:最新 5 日分

[最新版] [一覧] << == >>

twitter(log)

2011/12/22(Thu)

○ GWT Designer + SmartGWT 3.0

SmartGWT 3.0 released, but unfortunately GWT Designer doesn't work anymore with following message: 

WindowBuilder supports only SmartGWT versions 2.4, 2.5. But 3.0 found.

it seems that official doesn't have any motivation to solve this problem(see here and here), so i wrote some tiny patch.

get it from here.

if you using eclipse 3.7(indigo), just dropin *.jar to your eclipse/plugins folder.

2011/10/9(Sun)

○[i18n] CSI-xterm

@ まえがき

以前 OpenI18Nで公開されていた、xtermの国際化patchがいまやもうarchive.orgからも取得できなくなっているようですので、私のところでミラーしておきます。

@ でもxtermって国際化されているじゃないですか

はい、今のxterm(uxterm)はThomas Dickey氏により国際化されたものがXFree86-4で取り込まれ、初期には多くあった日本語環境における問題も、Debian開発者のkubota氏によって フィードバックされ、日常使用するには問題のないものとなっています。

@ じゃぁなぜそれ使わないの？

といわれましても、まーいつもの私の持病としか。 

初カキコ…ども… 
俺みたいなCSIでi18nしてる腐れ野郎、他に、いますかっていねーか、はは 

今日のtwitterの会話 
あの異体字がかっこいい　とか　あのAdobe-Japan1と汎用電子はIVS統一してほしい　とか 
ま、それが普通ですわな 

かたや俺は電子の砂漠で0x1bからはじまるエスケープシーケンスを見て、呟くんすわ 
codeset independent. 狂ってる？それ、誉め言葉ね。

なんつってる間に4時っすよ(笑)

真面目な説明はいずれ書きますｗ

@ ダウンロード

  1. Xorg-6.5.1向けのpatch
    http://www.hi-matic.org/distfiles/openi18n_mirror/xterm-6.5.1-i18n-0.7.patch.gz
  2. Xorg-6.6のxtermに上記patchを適用し、conflictを修正したもの
    http://www.hi-matic.org/distfiles/openi18n_mirror/xterm-6.6-i18n.tar.gz
  3. とりあえず日本語使うための.Xdefaultsサンプル
    http://www.hi-matic.org/distfiles/openi18n_mirror/Xdefaults

@ 使い方

とりあえず使いたいという人は 

$ ftp http://www.hi-matic.org/distfiles/openi18n_mirror/xterm-6.6-i18n.tar.gz
$ tar zvf xterm xterm-6.6-i18n.tar.gz
$ cd xterm
$ xmkmf -a
$ make
$ sudo make install

とか *1でどうぞ、既存のxtermとapp-defaultsファイルが上書きされてしまいますが、こんなんわざわざ入れようとする人はUnicode版xtermなんかに未練はないですよね(白目

つうか4.99.xな頃はある程度正常に動いてたけど、今どーだろ。

(追記) xterm/{termcap, terminfo} も入れないとcurses/terminfo/termcapつかうアプリの表示がぐちゃぐちゃになります。

NetBSD-currentの人はterminfo化されているので 

$ cat terminfo >>~/.terminfo
$ cd
$ tic .terminfo

この時NetBSD-currentだとmeml(memory lock), memu(memory unlock)ねーよと怒られますが、これ標準にはないHPの拡張なので無視してOK

NetBSD-5以前の人は~/.termcapに追記して下さい(ticはこれterminfoのコマンドなので不要)。

@ スクショ

*1:なんでwgetとかじゃなくてftp(1)でファイル取ってこれるのかって？可能なのさ、そうNetBSDならね(ドヤ

2011/10/2(Sun)

○[RIA][Java] Google Web Toolkit(その1)

最近仕事でGWT + SmartGWTを採用したりしたのですが、前者のドキュメントは古いし日本語訳はアレだし、後者に至ってはJavadocすら内容微妙なもんで、何回かにわけて導入から開発TIPSなど書いてみる予定。いろいろハマりどころ多いので…

@ Google Web Toolkitとは？

Google Web Toolkit(以下GWT)は、いわゆるRIA(Rich Internet Application) を作成するツールキットです。アプリケーションはクライアントサイド、サーバーサイド共にJavaで記述しますが、クライアントサイドについてはトランスレータがHTML5 + JavaScriptに変換するので、Java Appletのようなプラグインを一切必要としません。
http://code.google.com/intl/ja/webtoolkit/

サポートされているウィジェットについては以下のショーケースをご覧ください。
http://gwt.google.com/samples/Showcase/Showcase.html

またサードパーティーにより、よりリッチな機能を持つライブラリも提供されています。

@ GWTの利点

JavaScriptで開発を行う上でしばしば開発者の頭痛の種になるのが、JavaScript処理系の互換性の低さとHTML表示の差異ですが、GWTはこれらをすべてトランスレータが吸収するので、これらの問題を気にすることなくコーディングを行うことが可能です。

現在サポートされるブラウザは以下の通りです

HTML5 + JavaScript技術がベースですのでさすがにi-mode CHTML対応までは無理ですが、近頃急速に普及が進むスマートフォンであればSafari, Chrome, Operaなどで利用することが可能です。また別途GWT Mobile Webkitなど別プロジェクトによりスマートフォン向けの機能も提供されています。
http://code.google.com/p/gwt-mobile-webkit/

またメッセージなどの国際化(internationalization、以下i18n)を支援する機能もあるので、異なる言語でユーザインタフェースを提供することも容易になっています。

クライアントとサーバ間での通信はGWT-RPCという非同期通信がサポートされシリアライズ可能なPOJOのデータ連携が可能です。GWT-RPCのサービスはごく単純なServletの拡張ですので多くのサーブレットコンテナ上で動作します。また他のJ2EE技術(JDBCやEJB/JPAなど)との組み合わせも容易です。

またクライアントがGWTに限定されてしまうGWT-RPCを使いたくないという場合でも、JSON形式のデータも扱うことが可能(若干めんどくさくはあるのですが)ですので、サーバーサイドを別の言語やフレームワークで開発することも可能です。SmartGWTなどを導入すればよりシンプルにJSONを処理したりXML-RPCでの通信も可能になりますので、既存のWEB APIとの連携もより容易になります。

@ 開発環境

開発環境としてはGWT SDKが提供されており、最新のバージョンは2.4.0です(2011/10/02現在)
http://code.google.com/intl/ja/webtoolkit/versions.html

ユーザインタフェースの開発はeclipse 3.7でVE(Visual Editor)を押しのけて標準となったGUIビルダ WindowBuilder(以下WB)上でWYSIWYGなデザインが可能ですので、HTMLやJavaScriptを知らなくても開発できます (フォントの指定などCSSに関する最低限の知識は必要ではありますが)。

WBはかつてApplet/Swing/SWTなどのJavaアプリケーションのみならずGWTをもサポートする開発環境としてInstantiations社から販売される商用製品でしたが、これをGoogleが買収しeclipseプロジェクトに寄贈されました。
http://googlecode.blogspot.com/2010/12/windowbuilder-becomes-new-open-source.html

そしてプロジェクトの作成、ビルド & デバッグ、デプロイを支援するeclipse用pluginが(ちょっと混乱しますが)2種類提供されています。

ぱっと見では前者の方が良さそうなのですが、WB制限版ではSmartGWTやExtGWTを使った開発ができないという落とし穴があります。同時にインストールすることももちろん可能なのですが、両者のメニューが混在した状態となり混乱を招くので、この記事では次回以降は後者を使って話をしていきます。

@ 次回

ここまで書いたところでWindows7がビジー状態に陥ったのでやる気もげたんでまた続きは次回、インストールしてみる編。
つーかこんな記事に需要あるんだろーか、ぜんぜん日本で流行ってないしなー。

2011/9/10(Sat)

○[FreeBSD][NetBSD][nvi] GSoC Multibyte Encoding Support in Nvi

前回のネタ書いた後知ったんだけど、FreeBSDのGSoCで似たようなことやってる人いるみたい、 ここ。
いやー後は若い人に任せて、俺は最近仕事のストレスでIYHした数々のオモチャで遊んでていい?

と思ったんだけど、 これ見ると結局nvi-1.79に1.81系の修正を持ち込んでるだけな希ガス。
EXFってのは先日問題だーといったBerkeley DBをwrapした感じのファイル管理情報用構造体ですな。
んで編集中のラインバッファがc_lp(実際にはEXFでなく画面描画用のSCR構造体にある)であり
これをwchar_t化したぜっ！てことみたいですが、これnvi-1.81ですでにやってるしね。
API名もINT2FILE/FILE2INTと名前も同じなので、学生さんが自分で考えてやったことじゃないっぽい。

んで私が指摘したよなCharacter Encoding SchemeレイヤでUS-ASCIIと互換性のない文字コード(UTF-16/32とか)への対策を
DB1/iconv層に手を入れることで解決したぜ！ということが書いてあるんですが、どの辺で対策したのかよーわからんです。

common/encoding.cのlook_utf16()とか関係してるっぽいけど、githubのアレなインタフェースで脳挫傷したので以下略。
まぁDBに入ってるファイル情報をfileencoding使わずにlocale encodingにしてるのかなーとか仮説。

ただそれやると情報落ち発生するので個人的にはアレ、現時点でのnvi-1.81はfileencodingとinputencodingがあって
これを一致させれば情報落ちは発生しない(ただしnvi-m17nのようにdisplayencodingがなくwcurses/locale依存でそのは化ける)
わけでして(まぁlocaleとは異なるinputencodingってinputmethodが困るような気もするけど)。

それとNetBSD-currentでnvi-1.81はすでに本家にフィードバックせずに徹底的に手がはいってて、
差分はもはやpkgsrcへ反映するのも心が折れるほどの、forkしたといって過言でない量が溜まっておるのですが
こっちは全く中見てないようですな、まぁFはCSI wchar_tなんだけども、GB18030なんかでwchar_tがnegativeにならんよう
localesrcを無理矢理いじったりしてるから問題が出にくいからもあるんだろけど。

あとgtagsサポートなんかのnvi独自機能をばっさり切るぜーゆうとるようですが、それならnviやめて
Caldera(今のSCO)が4-clause BSDLで放流した美流上位オリジナルの traditional-viをベースに
i18nやり直した方がいいんじゃねーのと思うアテクシ、nviもしょせんニセです。
いわゆる商用UNIX(Solarisとか)はこれを自分たちで国際化してつかってますな。

それと文字コード自動判定にfile(1)使うって、Fのfile(1)ってそんな機能まであるのかいな。
Nだと8bitがたってるファイルならeucJPだろーがWindows31-Jだろーが 

$ echo あいうえお >hoge.txt
$ file hoge.txt
hoge.txt: ISO-8859 text

と、ISO-8859-*という答えが返ってくるはずなんですが…

まぁ結論からゆーとFreeBSDのことなのでどうでもよろしい(ぉ

2011/9/6(Tue)

○[NetBSD] nvi-1.81 の問題点(その1)

新たな作業をする前に、何回かに分けて今のnviのイケてない点をあげつらって
寝てる間に小人さんが直してくれないかなーと期待してみるテスト(ぉぃ

@ Berkeley DBにつよくたくましく依存している

Berkeley DBとはKVS(キーバリュストア、イオン系列店) *1の一実装で、その中でもRECNOというDB形は

として扱うものです、nviはこのRECNOを利用して様々な処理を行っているのですが、このことがかーなーり困った問題を生んでいます
(まぁ感のいい人ならこの時点でピーンとくるでしょう)。

まずRECNOの内部実装を考えてみましょ、「1行」をここからここまでと切り出すためには

という処理が必要です、RECNOではこの改行文字については

ちゅーインタフェースを持っています、以下ヘッダファイル。 

/* Structure used to pass parameters to the record routines. */
typedef struct {
	...
	uint8_t	bval;	/* delimiting byte (variable-length records) */
	...
} RECNOINFO;

改行文字ってーのはこんなチラシの裏好き好んで読んでる人は当然ご存知とは思いますが
dos2unix/unix2dosなんてコマンドがあることからお判りの通り、まず環境によって異なります。

んで上記の通りDOSなんかでは改行は2byteなのですけども、先刻ご覧の通りRECNOのインタフェースでは
残念至極なことにuint8_tとして定義されてるので、恐悦至極ながら1byte 以上のより大きい改行文字(列)はサポートできんのですな。
助けてーfopen("b")〜といってもそれじゃ改行文字は変更できないし、そもそもRECNOの中の人はmmap(2)なので以下略

どうです、これはひどい問題でしょ？といってもこれだけだとWindozeプギャーm9(^д^)で片付けてしまいかねないのですが
よーく考えよう。もういっちょ重大な問題が裏に隠れています、それは何かとゆーと。

つまり

なのですよな、例えばみんな大好きUTF-16/32なんかだと改行文字がLFであっても

と、2〜4byteあるわけです、つまりRECNOに強く依存したnviはUTF-16/32のサポートなどがまず不可能ちゅーことを意味します。

この問題は現時点のBerkeley DBバージョン5でも 解決されていないですし、また将来のバージョンで対応されたとしても
ライセンスの縛りがきつくなったバージョン1.85以降をNetBSDにインポートすることは極めて困難です *2。

まぁ解決法はRECNOを

とかなんですが、破壊的インタフェース変更になるゆえ Berkeley DB を fork するってー話になるわけで
非常にめんどくさいし、本家がOracleちゅーことを考えると最悪のケースであの最強法務部門と以下略。
まーぶっちゃけBerkeley DBなんぞ捨てて、もっと軽量なRECNO作るんでしょうな(お待ちしております)。

世間一般の人だとインタフェースを破壊せずBOM使って対象がUTF-16/32なら暗黙的に内部でUTF-8に変換するんでしょうが
世の中のstateful encodingにおいてはエスケープシーケンスをともなった改行コードは別の意味を持つ場合もあるので
そういう実装にも対応することを考えちゃうようなパラノイアの私にはちょっとそんな実装恥ずかしくて無理です(ぉ

あと別件ですがRECNOがらみなので。
nvi-1.81はメッセージカタログにまでRECNO使ってるせいで、時々余計なエラーメッセージでたりするし
文言に plural とか u?intN_t format string なんかが必要になった時のことを考えると、これもさっさとgettext化すべきですな。
餅は餅屋。

*1:最近はKVSちゅーと分散KVSを指すことがおおいっす、memcachedとかredisとかいろいろありまんな。
複合キーのどー考えてもRDBMSを採用した方が楽な事案にRedisを採用してしまい、複合キーをTSV形式にして無理矢理単独キー化して回避したら
実はRedisはプロトコル上isblank()な文字を問答無用でkey/valueの境界と扱うため、set/get時にエラーは起きないがデータは破壊という事象が発生し
この対策にURIEncodeする知恵もなくShift_JISの2byte目は1byte目と被るという知識も無くただ闇雲にデリミタを試行錯誤して
簡単なテストだけして本番リリースたらもっと盛大に壊れたデータが数TBほど完成し、この時点で納期ギリギリで心が折れた実装者が失踪し
かわりにお前が直せとActivePerlとメモ帳ひとつで監禁されたりすると、半年チラシの裏が更新されなくなったりするわけです。
*2:そもそもnvi-1.81ではdb3以外はサポートしてなかったのをわざわざdb185でも動くよう改造しているくらいですしおすし。

[ホームへ] [ページトップへ]