会社サーバーとして、これまでファーストサーバさんのデルタ1 というサービスを利用させて頂いていたのですが、のっぴきならない事由 (ごくごく経済的な事情 T-T) により、さくらインターネットさんのさくらのVPS というサービスに乗り換えることにしました。そして、その移転作業が完了致しましたので、ご報告申し上げます。
と、いっても、現状何かサービスを展開しているわけでも無し、本ブログもこれまで通りそのまま閲覧できますので、「だから何?」とか言われちゃうと困ってしまうわけですが…。
今回の移転作業に於きましては、すべての作業内容を逐次メモに取り、その内容を公開しております。弊社のように、既に他社の専用サーバや VPS を用いてサーバーを構築しているものの、とっても安価でよさげなさくらの VPS に移行したいなぁなどとお考えの方々に、少しでも参考になれば幸いです。
UTF-32 が内部文字列に使えないことがわかったので、 UTF-8 を内部文字列に使用するというルールで libiconv によるエンコーディング操作と Boost.Regex による正規表現の両方を同時に試すサンプルを作成してみました。
Makefile は作ってません＼(^O^)／。試してみたい人は頑張ってコンパイルしてねｗ
$ g++ -std=c++0x -o regex-test regex-test.cpp EncodeString.cpp -lboost_regex
まともな環境 (Linux + GCC4.5 とか) なら上記コマンドで通るはず。libiconv を (glibc に上書きする形で) インストールしている場合は -liconv を末尾に入れる必要があるかも。そして MinGW を使う場合は更にもう一工夫必要かも (((;/^^)/
(さらに…)
C++0x では UCS に対応し、専用の型やリテラルの記法が導入されました。その関係で、以下の点について調査を行っていました。
char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。<regex> は利用可能か。<regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。
(さらに…)
実に楽しいイベントでした。 5時間ほぼぶっ通しだったのでさすがにくたびれましたが… (^_^;A
自分なりにメモしたノートを公開していますので、よかったら復習にご活用ください。かなり荒いメモですが…。
(さらに…)
ご無沙汰ぶりです…。
以前、wchar_t はどうにも使い物にならないからどうしよう、といった記事を書いたのですが、その続きのお話です。
表題の通りで、 libiconv を用いて文字セットを自動認識する処理のサンプルを書いてみました。詳しい経緯はTicket 内で逐次コメントしています。
(さらに…)
今メインでやっているお仕事を紹介してくださった友人に、CiNii という論文検索サイトを教えて頂きました。むしろ今まで知らなかったのかよぐらいの勢いなのですが…(^_^;A それはさておき。
個人的に気になっているのは、今 otoco でやろうとしている、楽譜情報と演奏情報 (シーケンス情報) を融合するデータ表現に関する研究が、MML なりそれ以外なりのアプローチで行われているのか、ということです。別に、既に行われているなら otoco を作るのはやめようとかそういう話ではないのですが、先行研究があれば参考にはさせて頂きたいな、とは思うわけです。
今のところそれらしい研究成果はまだ見つけられていないのですが、music macro language で検索してみたところ、面白いものを見つけました。かなり画期的な概念に基づく MML、その名も「PMML」です。
(さらに…)
otoco に限らず、 PC 上で動作するプログラムの多くは、テキストを処理することを目的の一部またはすべてとしています。 otoco の場合は特に、どこの誰とも分からない人が MML を書き、それを読み込んで XML やら SMF やらオーディオやら楽譜やらに変換することを目的としているので、どこの誰が MML を (あるいは XML を直接) 書いても問題なく処理できるよう、文字セットの扱いには丁重でなければなりません。
当初の方針として、 otoco では内部コードに Unicode を使用し、その物理型は wchar_t で扱うつもりでいました。この辺、C/C++ でのクロスプラットフォーム開発に慣れていないと陥りやすい罠であるように思うのですが… 現状の wchar_t ははっきり言ってクロスプラットフォーム開発には向いていないものといわざるを得ないようです。
とりあえず確認しているのは Windows の VC++ 2008 と Linux の gcc だけなのですが、それだけでも調べた限りで以下のような相違点がありました。
Boost ライブラリの Ubuntu へのインストールは容易でした。単に libboost-dev パッケージを aptitude install してあげるだけです。
問題は、前回も書いた通り、 apt からインストールできる Boost のバージョンは通常で 1.34.1、最新のものを選んでも 1.37.0 になってしまう、ということです。
そこで、 otoco の開発に影響する範囲で、バージョン間にどの程度の差異があるのか、調べておくことにしました。
とりあえず今思いつくのは正規表現まわりだけだったのでまだそこしか調べていないのですが (空文字列マッチは何気に影響範囲大きそうですが…古いバージョンで統一しておけばとりあえず問題にはならないかな…)、実際に開発が進めば利用範囲が広がり、都度気づく部分も増えていくかもしれません。上記ページはその都度更新して行く予定です。