2016年2月20日土曜日

Mono 4.0.3に戻しました

Mono のバージョンを lang/mono のアップデイトに合わせて、4.2.1 --> 4.2.2 とあげてきたのですが、OpenSim内のオブジェクトのスクリプトを編集し保存すると、
Region (????) # * Assertion at memfuncs.c:81, condition `unaligned_bytes (dest) == 0' not met
というAssertionエラーがでて、止まってしまうようになりました。 memfuncs.c というのは、monoのソースコードです。 OpenSimを 0.9.0 Devというまだ不安定なバージョンにしているせいもありますけど、 やっぱり、安定してうごいていたバージョンに戻す事にしました。 今の状態だと、メモリリークして、3-5日で勝手に落ちてるような状況なので、 OpenSimの方も、0.8.3 という 0.9.0 Devになる前のものに戻してみようかなぁ...。

Portsは、ソースコードをSubversionでチェックアウトしているので、次のようにして、以前のPortsファイルに戻して、コンパイルしなおしています。
# cd /usr/ports/lang/mono
# svn update -r 397063

2015年12月6日日曜日

Monoを 4.2.1 に更新しました

Monoのバージョンを 4.2.1 に更新しました。

FreeBSD 8.4 は、システム標準のC/C++コンパイラが gcc 4.2.1なので、Monoをビルトできません。ですんで、まず lang/clang34 がインストールされて、これをつかってMonoをビルドします。でも、いろいろPorts全体のバージョンがあがってて、途中でエラーでこけてしまう。
もう、FreeBSD 8.4は、EOF(End Of Life)なので、積極的にはサポートされてないからだとは思いますが...。
/etc/make.conf の書き方も、古いまんまで、それが問題を起こしてたりと、試行錯誤して、やっとインストールできました。

OSGrid側の OpenSimを新しいMonoでうごかそうとしたら、libgdiplus の共有ライブラリでエラーになりました。アップデイトが中途半端だったのかしら...。もう一度、x11-toolkits/libgdiplus に関係するportsを全部更新し、バイナリーpackage作って、OSGrid側でアップデイトかけて、ようやく動くようになりました。かなり時間かかった.....。動く標的を撃つのはシンドイ...。

OpenSimも、http://www.osgrid.org/index.php/downloads から取得できる、「2015-12-02 OpenSim 0.9.0.0 Dev d5e21a0」をインストールしました。以前つかってたバージョンは、リージョン間の移動のときに、なんかおかしかったのが直ってます。
今見たら、2015-12-05付けで、もう新しいOpenSimがでてる....。

FreeBSD 10.2 だと、すんなりMonoなどもコンパイルできたので、もうFreeBSD 8.4 で運用するのは限界かなぁ....。変更するものが多くて、めんどうだー。でもやるしかないなぁ...。

2015年8月29日土曜日

NeXTBSD

NextBSD登場

昔、NeXTやMacOSX Server ってコンピュータ使ってたから、けっこう気になるなぁ...。

Mach IPCをFreeBSDカーネルにいれるのかぁ...。Mach IPCってケーパビリティベースのセキュリティなんだけど、ケーパビリティってのをちゃんと解説したドキュメントがすくなくて、いまいちちゃんと理解できてる気がしない。OpenSimのプロトコルでもケーパビリティって用語がでてくるけど、同じ概念に基づくものなんだろうか...。信用の連鎖をつないでいく方法のセキュリティと考えてよいのかしら...。

NeXTBSDが出た背景には、MacOSXやiOSの流儀で、データーセンター側のサーバーのプログラムを配置したいというのがあるんだろうなぁ...。MacOSXで作ったサーバー系プログラムをそのまま、データセンターに配置する、というような...。

ある程度、まともに動くようになったら、うちのリージョンは、このOSでうごかしてみたいなぁ...(そのまえにまわりのサーバーをFreeBSD10.2にアップデイトしないと....www)。

でも、もう頭が世の中についていけてないのが問題だ...www。

2015年4月12日日曜日

Monoを3.12.1に更新完了

Monoのバージョンを 3.12.1に更新完了しました。
特に変わったところは感じません(まあ、OpenSimうごかしてるだけなら違いはわからない)。

これで、Linuxのバージョンに追いついた。
最近、FreeBSDのlang/monoの本家のMonoへの追従がわりと早いです。

また、バイナリーのパッケージングシステムがpkgになったので、パッケージ作成マシンにssh経由でアクセスできるようにしとくだけで、他のマシンに作成済みのパッケージをすばやくインストールできるようになりました(以前もできなかったわけではなかったけど、Webサーバーたてたりとかが必要だった...と思う...)。
うちみたいな小規模用途の場合、特別にパッケージサーバーとかを立てる必要もないので、結構便利です。
でも、まあ、やっとLinux並みになったというところなんでしょうけどwww。

2015年3月2日月曜日

x11-toolkits/libgdiplus のビルドの問題が解決

Monoを3.10.0に更新中 #2」の記事で書いた、x11-toolkits/libgdiplus の問題は、数日前にPortsをアップデイトしたら、files/patch-src_gifcodec.c のパッチが追加されていて解決しました(万歳!)。

ただし、そのままコンパイルしてしまうと、XOpenDisplay()等の関数を呼び出してしまうので、Xをインストールしていない環境では、OpenSim起動時にエラーになってしまいます。
この為、次のMakefile.localと、files/patch-src_general.c を  x11-toolkits/libgdiplus のディレクトリに追加してビルドします(昔の記事には、このパッチを載せてなかったみたい...そのうちちゃんとまとめねば....)。
ただし、これはXをインストールしていない環境で無理やりOpenSimを動かすためのものなので、Xが存在する環境では、この作業はしないでください。libgdiplus を使う他のアプリケーションに悪影響がでる可能性があります。

Makefile.local

#
# Makefile.local  --- Local settings for OpenSIM
#

.if defined(WITHOUT_X11)
CFLAGS+=        -DWITHOUT_X11
MAKE_ARGS+=     'SUBDIRS=src'
.endif

files/patch-src_general.c

--- src/general.c.orig  2011-01-13 22:28:19.000000000 +0000
+++ src/general.c       2012-08-27 07:31:08.000000000 +0000
@@ -132,6 +132,9 @@

                dpis = h_dpi;
                return dpis;
+#elif defined(__FreeBSD__) && defined(WITHOUT_X11)
+               dpis = 96.0f;
+                return dpis;
 #else
                char *val;
これで、Portsを最新にしても、OpenSimを動かすことができるようです。

2015年2月22日日曜日

Monoを3.10.0に更新中 #2

lang/mono をFreeBSD8.4で最新のものをビルドすると devel/llvm34 がインストールされてしまうので、更新をずっとためらっていたんですが、FreeBSD10.1でもemacsをインストールしようとすると、(たぶん、まだclangに全面的に対応できてないのか) gccがインストールされてしまうようです。
まあ、それならあんまりためらっている事もないか....と、portsを最新にしていろいろアップデイトを掛けてました。
なんか、FreeBSDのバイナリーパッケージングシステムがpkgngに変わったので、いろいろと調整が必要で、結構時間かかってしまいました。一番時間かかるのは、古い頭を新しいシステムになれさせる事なんですが....。

で、別環境で作成した最新バイナリーパッケージを使って、OpenSim動かしているマシンを更新かけたところ、libgdiplus.soが読み込めなくて、OpenSimが立ち上がらなくなりました(;Д;)。

Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.so 

あれぇ?と思って、libgdiplusを再構築してみたら、src/gifcodec.c のコンパイル中にエラーがでてました。調べてみると「2015-01-15  Update graphics/giflib to 5.0.5」ってMakefileのSubversionログにはかかれているけど、giflibライブラリのインターフェイスが変わっているのに、ソースコードが未修正なのが原因みたいです(libgdiplusのporterさん、ちゃんとテストしてるのかしら?)。

しかたないので、中身の意味もろくすっぽ調べないで、適当にパッチあてて、コンパイルだけ通して、バイナリーパッケージ作成し、更新かけてみましたけど......やっぱりだめでした....。

気を取り直して、 OpenSim動かしているマシンに残っていた古いportsソースを元に、libgdiplusを作り直したら、とりあえず動くようになりました。 libgdiplusは、依存するライブラリがかなりあるので、慎重にビルドしないとだめのようです...(ライブラリの依存関係の情報もlibgdiplusはちゃんとかかれてないようですし....。とはいうものの、私もports作成に関しては知識あんまりないけど...)。

ところで、libgdiplusって、OpenSimでは、Mapイメージ作るのにひつようなのかしら???

というわけで、OpenSimが立ち上がって、とりあえず、ホっとしてます。 新しい環境に移行する場合は、テスト用のマシン・環境にインストールして、確認してからの方がやっぱりいいですね....。今後、どうやって、やろうかしら....。やっぱりもうひとつJail環境つくって、そのなかでテストしてからの方がいいかな....。

2015年2月7日土曜日

Monoを3.10.0に更新中 #1

ひさしぶりにBlog書いてみます。

FreeBSDのlang/monoのバージョンがだいぶ上がってたんですが、FreeBSD8.4だとdevel/llvm34 のコンパイラをインストールしようとします(ほかにもPhytonとかいろいろインストールしようとします)。OpenSim動かすmonoの為だけに大きなコンパイラをインストールするのもなんかイヤで、FreeBSD10.xにしたらシステム標準のコンパイラがllvm34レベルになるから、それからって思ってました。

でも、FreeBSD10.1にして、ファイルシステムが「soft updates journaling」がデフォルトになったけど、インストールが悪いのか、なんかミスったのかわかりませんけど、なんか変になってファイルシステムが壊れてしまいました(gmirrorと組み合わせてるのが災いしたのかしら???)。まあ、私のところだけなのかもしれませんが...。

というわけで、FreeBSD10.xに全面移行するのは、もうちょっと先にして、FreeBSD8.4でmonoを最新にビルド中です。

しばらく、portsをアップデイトしてないと、いろいろバージョンがあがってたり、pkgngに代わってたりで、なかなかスムーズにいきません。Subversionも良くわかってなかっので、勉強しなおしたりと.....回り道ばかりしてます。

2014年7月18日金曜日

Raspberry Pi に FreeBSDをインストール #2

ARMでは、まだMonoが動かない

Raspberry Pi + FreeBSDでも、OpenSimうごけばいいなーって思ってたんですが、Portsのlang/monoは、まだARM-CPUでは動きません。残念...。 いずれ移植されて動くようにはなると思うので、そのとき、再挑戦してみることにします。

ヒートシンクをつけてみた

Raspberry Pi のCPUやチップは、わりと熱をもつようです。OS全体をコンパイルする、make world, make kernel とかすると、かなり長時間高負荷でイジめることになるので、熱的に大丈夫か不安になったので、ヒートシンクを買いました。



私の部屋は南向きなので、日中はかなり温度があがってしまいます。これで、長時間システムを動かし続けても、ちょっとだけ安心です。

2014年7月15日火曜日

Raspberry Pi に FreeBSDをインストール #1

> まずは、順当にLinuxでも動かしてみようかしら...。

って書いたんですが、FreeBSD 10.0 のRaspberry Pi 用のインストールイメージがFreeBSD本家サイトにあったんで、こっちを先にインストールしてしまいました...(FreeBSDで遊ぶのに飽きたら Linuxもいじってみることにします www)。

FreeBSDディスクイメージのSDメモリへの書き込み

  現時点での最新は次のものです。
FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140630-r268038.img.bz2

この.bz2ファイルの展開して得られた .imgファイルをSDメモリカードに書き込みます。書き込みは、別に動いてるFreeBSDマシンにUSBメモリカードリーダーライターをつないで行います。 展開後のディスクイメージが1GBぐらいなので、 使用するメモリカードは、2GB以上の容量のものが良いと思われます。 私が、最初使ったメモリカードはClass4の4GBのものでした。

SDメモリカード (4GB)
使用したSDメモリカード

私のところの場合、SDメモリカードをFreeBSDマシンのUSBに挿すと /dev/da0 として認識されます。書き込みは4~5分で終わりました。

# bunzip2 FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140630-r268038.img.bz2
# dd if=FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140630-r268038.img of=/dev/da0 bs=1M

Windowsでディスクイメージを書き込む場合、DD for Windows というツールが使えます。Windows7で使えました。

シリアルコンソールの接続

次に、Raspberry Pi にシリアルコンソールケーブルを接続します。シリアルケーブルが無いと、ログインする方法がないので手も足もでないことになります(液晶ディスプレイやUSBキーボードが接続されていたら、なんとかなるのかもしれないけど、持ってないから分かりません。また、sshd_configを書き換えてrootログインを許可してssh経由で接続ということもできなくはないけど....)。ですんで、やるならシリアルケーブル接続することを、まずはお勧めします。


私はWindows7のマシンに、Amazonで買った次のようなUSBシリアルケーブルを接続しました(中国製でかなり安かったけど、到着まで時間かかるし、ちょっと怪しいので積極的にはお勧めしない www)。入出力の電圧レベルは、TTLレベルのものです。

USB-TTLシリアルコンソールケーブル

このケーブルをTeraTerm経由で接続します。設定は次の通りです。
Baud rate: 115200bps
Data bit: 8bit
Parity bit: none
Stop bit: 1bit,
Flow control: none
結線は、Raspberry Piのビン配置 を参考に、ケーブル赤(VCC, +5V)以外を接続します。
ケーブル緑(TxD) ---  Raspberry Pi  10番pin
ケーブル白(RxD) ---  Raspberry Pi  8番pin
ケーブル黒(GND) --- Raspberry Pi  6番pin
ケーブル赤(VCC) はつながない事! 最初、赤もつないでしまって、なにも出力されないので使えないのかと思ってしまいました。Raspberry Pi 壊れなくて良かった...www。

SDメモリカードに関する注意

FreeBSD for RPI のSDメモリカードドライバーにまだ不具合があるのかどうかはわかりませんが、SDカードによってはエラーになって動作しないものがあります。
次の手元にあったカードは、最初なんどもエラーになり、bootの途中で落ちました。が、何回か書き込みしたり、抜き差ししている間になんとなく動くようになりました(謎だ)。


また、 最初に使用したカードでも、portsツリーをportsnapで展開したり、ヘビーにコンパイルかけると、たまーにエラーでカーネルが落ちしてしまってることがありました。SDメモりカードをTranscend の16GB, Class 10のものに変えて試してみたら、エラーがでなくなり問題なく動作している雰囲気です。可能ならClass 10などの高速なカードを使うことをお勧めします。

SDメモリカードのモードに関して気づいたこと


しかし、今一度、OSが起動しないときのブートメッセージを見てみたら

mmcsd0: 4GB <SDHC LEXAR 1.0 SN 194340 MFG 11/2010 by 40 BE> at mmc0 50.0MHz/4bit
/65535-block
mmcsd0: Error indicated: 1 Timeout
mmcsd0: Error indicated: 1 Timeout
...

となっていました。一方、正常に起動したときのブートメッセージは、以下のようになりました。

mmcsd0: 4GB <SDHC LEXAR 1.0 SN 194340 MFG 11/2010 by 40 BE> at mmc0 25.0MHz/1bit
/65535-block
...
mmcsd0: 4GB <SDHC LEXAR 1.0 SN 194340 MFG 11/2010 by 40 BE> at mmc0 25.0MHz/4bit
/65535-block
...

これを見ると、50.0MHz/4bitのモードになったときはエラーになり、25.0MHzの場合は正常にメモリカードにアクセスできる、ということみたいです。
SDカードの仕様には、まったく詳しくないので、これが何を意味するのかは分かりませんが、メモリカードコントローラーの初期化の部分になんらかの不具合があるような気がします。

とりあえず Raspberry PiでFreeBSDが起動した

紆余曲折はありましたが、Raspberry Pi でFreeBSDが起動しました。
root@raspberry-pi:~ # uname -a
FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul  1 04:2
9:43 UTC 2014     root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B  a
rm
root@raspberry-pi:~ #

いったん起動すると安定してうごいているように見えます。FreeBSDも10.0になってCコンパイラがClangになったりして、いろいろ変わっているので、まだまだいろいろ変わっていく途中なのだと思います。

SDメモリカードのベンチマークしてみましたが、読みこみはさほど遅くないのですが、書き込みがUSB-HDDディスクの1/4~1/5 のスピードしか出ません。原理的にしかたないようですし、フラッシュ系メモリは書き込み回数に制限あるので、次は、ルートファイルシステムをUSB-HDDにしようと思います。


2014年6月29日日曜日

Raspberry Pi を買ってしまった

今日、BeagleBone BlackでBSDを動かす事に関してSecondlifeの友人からIMがきました。BeagleBone Blackというのは、ARMコアCPUを使った超小型ボードPCです。
http://beagleboard.org/
http://akizukidenshi.com/catalog/g/gM-06867/
友人はこのPCボードでOpenSimを動かそうとしているらしいです。こういう小さいボードでOpenSimが動くというのはすごく面白そうです(それにしてもマニアックな....www)。

以前から、Raspberry Pi などのARMコアの超小型ボードPC には興味があったのですが、私には荷が重そうで、たぶん買っても使いこなせなさそうだったんで横目で見てました。が、しかし、さっき発作的にRaspberry PiをAmazonに注文してしまいました(あーあ、やってしもた...)。

BeagleBone BlackとRaspberry Piのどっちにしようか迷ったんですが、FreeBSD-CURRENTでサポートされているらしいので Raspberry Pi にしました。BeagleBone Blackも動かしている人いるようだしスペック的にはよさそうなのですが、初めてこのタイプのボードをいじるので、情報が得やすいRaspberry Piにしました(軟弱ものな私....BeagleBone Blackもよさげだけど、まあそのうち....www)。

ちなみにFreeBSDのARM-CPUのサポート状況は以下のページに情報があります。
https://wiki.freebsd.org/FreeBSD/arm
まずは、順当にLinuxでも動かしてみようかしら...。
余裕ができたらFreeBSDとかを動かしてみて、monoとか動かして、
そして最終的にOpenSimを動かせたらいいなぁ....。

2013年10月5日土曜日

なんかYouTubeがおかしい

なんかYouTubeがおかしいです。なにがあったんだろう。
500 Internal Server Error

Sorry, something went wrong.

A team of highly trained monkeys has been dispatched to deal with this situation.
If you see them, show them this information:

aCKeDUpZYAN-OvHQiwJuw75PNnIOExicJmtpLMkXSKjhGOfgbUZzfWPvywzE
njnZUxrehIz4Wac52OBiCwXAYJF7mhPMV_GdPEzW1cS2oRa0-kQQR2Yq20gd
dOURttRrotG7_2nCREJn2TxBsPif3_ZErMl9RRGAlo8UrSK8rmU6n1ish88Z
StEZXvk3CTWKQ_kDtZmVABbc80ZJ5jhEc3tYwFIKIIYpBnHe0td1ZztNb0zy
Up6QjY77WhKJKEwTwdMILIOCDvdkGRyBBJRGeDu2G8VLwm9LKimTszvsCx47
...
...
...
TyY9LD8JHrVVEhmyGbPZel5VO1mZaV-AHPKVsZZftgP-1YKHfYNEA-Y7yL0I
HLghOSt5MIqvcQNvUx5wxJp4dxUJ_QWdh7gp76i8Cw4WdtBSEBAsiNINeTQI
kZq6M_RsVKwAp8pVit-l3z8eoIyNTExEKOLeZQx-whGIiUjL26EYLbELrXyT

2013年9月1日日曜日

Mono 3.2.1 のガベージコレクタ

FreeBSD PortsのMono 3.2.1 をインストールしてから、topコマンドでみると、以前は「mono」と表示されていたところが、「mono-sgen」と表示されていました。
ググってみると、MonoのプロジェクトページにGenerational GCというページを見つけました。中身の詳細は理解してませんけどwww、ガベージコレクターが変更になったということらしいです。

このページにRootsという項目があるんで、以前でてた「Too many root sets」ってエラーは、このRootsに関係あるんだろうなぁ...ってことは判ります(理解するのは、しんどいww)。

いずれにしろ、いろいろと改善されているようです。 あとは、ODEがクラッシュしないようになれば言うこと無いんだけど。ODE捨てて、BulletSim に鞍替えしたほうがいいんだろうか...。

2013年8月29日木曜日

Mono 3.2.1で、OpenSimを再構築

FreeBSDのPortsでMono 3.2.1にアップデイトできました。
% mono --version
Mono JIT compiler version 3.2.1 (tarball Thu Aug 29 14:09:52 JST 2013)
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notification:  kqueue
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

この新しいMonoでOpenSimを再構築してみることにします。 ビルドする前に、以前作成しているバイナリーをクリーンにしておきます。
% xbuild /target:clean
...

% xbuild
...

ビルドできたOpenSimを実行してみましたが、特に問題なくうごいているようです。しばらく様子を見ることにします。

2013年8月26日月曜日

Mono 3.2.1 がでてた

FreeBSDの lang/mono のPortsが 3.2.1にバージョンが上がってました。Subversionのログ見たら、わりとこまめにバグフィックスされてたみたいだけど、バージョンアップするのをサボってましたw。

しかし、ちゃんとMonoのPortsがメンテナンスされているのは嬉しいですね。 「Too many root sets」というエラーがでなくなればいいな。FreeBSDも8.4にあげてる事だし、Portsもぼちぼち最新に更新しないとなぁ...。

ちなみに、今は Mono 3.0.3 と opensim-c358d5d で、25日間落ちないで安定して動いています。これだけ長く動かし続けてるのは、過去あまりなかったかもしれません (まあ、連続運転するよりOpenSimのバージョンが上るスピードの方が早いからかもしれませんが w)。

2013年3月13日水曜日

"Too many root sets" というエラーが出た

今日、運用しているOpenSimをみたら、「Too many root sets」というエラーを出して、コア吐いて死んでました。
...
Region (root) # Too many root sets

Stacktrace:

Abort trap (core dumped)
検索してみると、どうやら、Monoのバグのような雰囲気です。
Monoのバージョンと動かしている環境は次の通り。

・ Mono  3.0.3 (FreeBSDのportsによるインストール)。
・ FreeBSD 8.3-RELEASE-p5

Mono 3.0.3になってからなのか、OpenSimのバージョンをあげてからなのかはわかりませんが、最近、たまーに発生します。

なんか、対処法あるのかな?

2013年3月4日月曜日

今度はOSgrid OpenSimulator 0.7.6.dev.e70c71aがでた

昨日、アップデイトしたと思ったら、もう次の新しいバージョンがでてました(X_X;)。

Update – Release changes for OSgrid opensimulator.0.7.6.dev.e70c71a

まあ、開発が停滞するよりはいいことだとは思いますが...。

こんどのバージョンは、OpenSim.ini と GridCommon.ini に変更があります。詳しくは上記URLの記事を見てください。

2013年3月3日日曜日

OSgrid OpenSimulator v0.7.6.2642129 にアップデイト

OSgrid OpenSimulator v0.7.6.2642129 にアップデイトしました。2/6に v0.7.6.3646361 にバージョンが上がったばかりだったのに、2/18には、このバージョンに上がりました。時間がとれなかったので放置してましたが、本日アップデイト掛けました。最近、 頻繁にバージョンが上がります。

バージョンあげる時、データベースにSQLiteを使ってる場合は、以前のバージョンで使っていた OpenSim.db をコピーしてくるだけでOKです。OSGridに(Hyperグリッドとかではなく)リージョンサーバーとして接続しているのならば、OpenSim.dbのみが必要なDBファイルになります。
データベースにMySQL をつかっているのならば、GridCommon.ini の設定を以前と同じようするだけでいいでしょう。
まあ、念のため、「save oar コマンド」 でバックアップを取っていたほうがいいとは思います。

あと、今回、bin/assetcache にあるアセットキャッシュデータ も以前のバージョンの物からコピーするようにしました。
% cp -Rp 以前のバージョン/bin/assetcache .
私ところだと、4つのリージョンで256MBのサイズになってましたので、ここが空っぽだと、OSGridのアセットサーバーにアクセスが集中するので、立ち上がりも遅いし、決して潤沢とはいえないOSGridのサーバー郡に無用な負荷を掛けてしまうことにもなるんではないかと思います。


正常にアップデイトし、OpenSim.exeが立ち上がったら、OpenSimのコンソールコマンドで、「fcache assets」 を実行しとくと、リージョン上にあるオブジェクトがキャッシュ存在するか確認が行われるんじゃないかと思います。効果あるのかどうかはわからないけど、まあ、気休め(^_^;)。


2013年2月3日日曜日

monoのバージョンを 3.0.3に上げました。

FreeBSDを8.2 --> 8.3へあげたついでに、monoのバージョンを3.0.3にあげてみました。Portsで正式に、3.0.3がサポートされています。これで少しはLinuxと同じレベルに近づけたかな?

リリースノート
http://www.mono-project.com/Release_Notes_Mono_3.0.3
 
OSGridのOpenSimのバージョンもあげちゃったし、 メモリリークの量が減ったかどうかは、よくわかりません。まあ、特に問題なく、それなりに安定して動いてるようにも見えます。

nantのPortsは、BROKENなままなんで、OpenSimのコンパイルには、xbuildを使いました。

FreeBSDの方も、CVSが廃止されてSubVersionに移行するとか、いろいろと状況がかわってるので、いろいろとまとめをしたほうがいいかもしれないなぁ...。

2012年12月4日火曜日

CTRL-CでOpenSimが落ちないようにする

OpenSimを端末ウィンドウでうごかしてる場合、CTRL-Cを押すと中断されて落ちてしまいます。これはWindowsでもUNIXでも同じです。UNIXの場合は、端末でCTRL-Cを押すとSIGINTというシグナルが発生し、その端末上で動いているプログラムを中断させます(デフォルトの動作の場合)。

私は、WindowsマシンでViewerを動かしながら、OpenSimが動いているサーバーにTeraTermで接続してOpenSimのコンソールを操作しています。CTRL-CはWindowsでは、Copy&PasteのCopyのショートカットキーになってますので、Windowsのノリで、sshの端末画面の上で間違えてCTRL-Cを押してしまうことがよくあります。また、UNIXのShellのコマンドラインでは入力途中のコマンドをCTRL-Cを押して中断・破棄するということもよくやります。

そういう手クセがついていると、OpenSimのコンソールでついついCTRL-Cを押して、誤ってOpenSimを落としてしまうことがあります。こないだも、OSGridの私のリージョンに人が来ていたにもかかわらず、CTRL-Cを押してしまったようです(手クセなんで、あんまり自覚がない。ごめんなさいwww)。

これを防ぐために、次のような「opensim_start.sh」というスクリプトでOpenSimを起動するようにすると、CTRL-Cを押しても大丈夫になります。
#!/bin/sh
stty intr undef
mono --debug OpenSim.exe
stty intr ^C
キモは、「stty intr undef」 というコマンドで、intr (SIGINT)を発生させる文字コードを未定義にしてからOpenSimを起動してます。これで、OpenSim起動中はCTRL-Cを押してもなにも起こりません。そして終了前にCTRL-Cに戻しています。sttyの詳細についてはオンラインマニュアルを見てください。

まあ、これで不用意にOpenSimを落としてしまうことが少なくなると思います(^_^;)。

2012年11月15日木曜日

OSGridで動画を撮ってみた

BlogにYouTube動画を張ったことがなかったので、試しにやってみました。撮影場所は、OSGridのMARTYS ART GALALERY II というリージョンです。アバターは、「hop://login.osgrid.org/Tryloria%202/192/48/22」でもらったHexeというVampireアバです。


録画は、BB FlashBack Express 2 というソフトでしました。 今見たら、BB FlashBack Express 3がでてました。

動画の撮りかたや編集は、まだ良くわかってないので、適当にやってます。まあ、いちどちゃんとマニュアルや、解説本を読まないと....(^_^;)。