AB開発日記

ウチのサーバーにWordPressをインストールしようと思ったのですが、インストール画面が真っ白になってしまうんです。

色々と調べた結果、phpのmbstringが有効になっていない（またはインストールされていない）のが原因ではないのかという情報があったので、正直に下記のコマンドでインストールを試みます。

yum -y install php-mbstring

すると難なく表示され、WordPressのインストールは1分で終了しました。今までの一時間を返して欲しい気分ですが、できたのでまぁ良しとします。

新たに下記URLにて開発者向けのコンテンツを展開していこうと思います。まずはライブラリの仕様決定を行う場としてWikiを立ち上げます。

自前サーバーで元気に稼動中。開発者用Wiki

http://dev.activebasic.com/dev_wiki/

今日はリファレンスを書いていただく上での決まりごと（ようはテンプレート フォーマット）を作っています。本格的な運用はそれが出来次第ということになりますので、開発に参加いただいている皆さん、よろしくお願い致します（気が向いたらサンドボックスでも編集してみてください）。

sourceforge.jp上のヘルプセンター リポジトリをいじるよりも数倍はラクですよ！

今日はとある用事で都内へ出向くことになっています。今から出掛けるのですが、かなりゆっくりめ。というのも静岡から品川まで一駅で行ってしまう新幹線 “ひかり” が出ているのんですね〜。丁度良い時間に。

それに乗れば静岡〜品川間が55分なようです。今までは新富士から乗ることが多かったので、常に “こだま” だったんですよね（新富士に “ひかり” は止まらないのです（涙））。しかしながら地元から都内まで1時間かからないというのはある意味驚異的ですね。

さぁ、今日もハリキッテいきましょうか！

自宅サーバーを構築中です。OSはLinux（Fedora Core 5）。インストール直後の初期アプリは0にしまして、まっさらな状態から環境構築にチャレンジしています。

今日はWWWサーバーとFTPサーバーのインストール＆設定、ファイアウォールの設定を行いました。すべてSSH経由でやっているので、自宅にサーバーがある感じがしませんf(^^;;;（今までは常にレンタルでしたから…

ほとんどの設定項目がすんだので、ライブラリ開発のための開発者向けWikiをそちらで試験稼動させてみようと思います。

一番の問題は長いLANケーブルを邪魔にならないように配線することですね。今週中にできるかな〜

ぎこちなくではありますが、GCとして動作するライブラリがほぼ出来上がりました。あとは、セーフティで安全にABユーザーの皆様にメモリ管理を行ってもらえるよう、下記のような点に重点を合わせて作業を進めていこうと思います。

1. 既存ソースコードの互換性を最重要視
2. 保守的GCとしてGC管理外のメモリ空間も検査対象とする（malloc/freeとの混在が可能）
3. GCを考慮することによる各種ライブラリモジュールの速度低下を防ぐ

1番目、まずはGCを使わない今までのソースコードが完全にコンパイル・実行できるようにします。GCを利用するしないはプログラマー次第ということになります。

2番目は1番目と言っていることが近いのですが、ようは今までmalloc/freeを使ったスタイルは問題なく動作するのは勿論のこと、mallocで確保されたメモリ空間もGC発動時の検査対象にすることでメモリの不正回収を回避することを意味します（mallocで確保されたメモリ上にGC_mallocで確保したメモリが参照されているにも関わらず、回収されてしまう問題が無くなります）。

過去のソースコードとの互換性を保ちながら、新しいコーディング手法としてGCを取り入れることが可能になります。

3番目は速度の問題です。基本ライブラリに組み込まれる利用頻度が高いモジュールでは、必ずしも内部処理をGCに頼る必要性はありません。例えば、Stringクラスのメモリ管理をGCでしてしまうと、利用する文字列バッファすべてがGC発動時の検査対象としてオーバーヘッドを生じさせてしまうなどの速度的な弊害が生じます。

GCと切り離して考えることができる基本ライブラリにおいては、GCとは無関係なメモリ空間を別途に用意し、速度低下を阻止します。

これが済んだら、正式にGCのリファレンスでも書いてみようと思います。3番目の別口メモリ空間に対するmalloc/freeに関しては、メモリ操作ライブラリの拡張が必要なので、ライブラリ開発フォーラムで仕様を提案したいと思います。

9月20日をもちまして、Discoversoftは法人としての活動をストップすることになりました。（有）Discoversoftとして業務を行った半年間、色々な方にお世話になり、私にとって今までの人生の中でとても良い経験ができました。

一人の技術者として、まだまだ私は力不足です。個人の考えの範疇で経験を積むのではなく、尊敬できる上司・先輩方の中に自らの身を置き自分を伸ばしていくこと、社会の一員としての責務を果たしていくことが今の私にとっての一番の目標です。

この半年は、働くことの意義や尊さを身をもって考えさせられた期間でもあります。それと同時に、快く相談にのってくださる関係者の方々、的確なアドバイスを与えてくださる諸先輩方が私の周りにはたくさんいること、本当に自分は恵まれた場に置かれているのだということに再度気付かされた次第でございます。

さしあたり、Discoversoftの法人活動はストップさせていただきますが、ActiveBasicの開発及びサポート、activebasic.comのWebサイト運営に関しましては、今までどおり、またはそれ以上の気持ちで取り組ませていただきます。

応援してくださる皆様、本当に感謝いたしております。

今後とも、暖かい目で見守っていただければ幸いです。

OverTakerさんのブログでインデントについての面白い記事を読ませてもらいました。

OverTakerの日記:

http://d.hatena.ne.jp/OverTaker/20060918

ウーム、ただ単にTABインデントをしやすくするのではなく、コードの意味に応じて見やすい形式にインデントを整えてしまうとはアッパレです。ABのWithステートメントでも “=” を境目に同様のインデント機能を付けたら…という意見がありましたが、これは好き嫌いがありそうですね〜。こういう機能って、もしかしたらあまり利用頻度のない（少なくとも私は）Withだけに限定させてしまうのももったいない話なのかもしれませんね。

話は多少変わりまして、ちょっと発案しているインデント機能があります。それはソースコードの一部をペーストした際に、自動的に最適なインデントに整形されたソースコードが貼り付けられるというものです（C#のエディタにはこのような機能が付いているようです）。例えば、下記のようなソースコードがあったとします。

Print "test"
Print "test2"

これを下の部分に貼り付けると、、、

Sub foo()
    'ココに貼り付ける
End Sub

↓

Sub foo()
Print "test"
Print "test2"
End Sub

まぁ、こういうことになるわけですが、2つのPrint文は誰がどー見てもインデントを入れて欲しいわけです。こんな些細な問題にも対応できるだけのインデント機能、せっかく思い立ったんで次回のバージョンアップ時には対応させたいと思います。

とあるユーザー様から、下記のようなコードがうまくコンパイルできないというバグ報告をいただきました。

function func(n As double) as String
    print "double";n
endfunction

function func(n As dword) as String
    print "dword";n
endfunction

func(123)  'オーバーロードを解決できません
func(1.23) 'オーバーロードを解決できません

一見すると、エラーなどはでないハズなのですが、AB5β5で試すと確かにエラーがでます。

最適化中...
コンパイル中...
test5.bas(11) - "func" オーバーロードを解決できません
test5.bas(12) - "func" オーバーロードを解決できません

-----------------------------------------------------
コンパイルは中断されました（エラー:2、警告:0）。

色々と調べた結果、実体オブジェクトを戻り値にしていることが引き金となって生じるバグでした。このバグの原理はこうです。

実体オブジェクトを戻り値に持つ場合は、隠れ第一パラメータ（クラスメソッドのときは第二）というものが存在し、そこには戻り値を格納するためのオブジェクトポインタを保有することになっています。オーバーロード解決時に実体オブジェクトの戻り値が隠れパラメータとして存在してしまうと、今回のような不具合を生じさせてしまうということなのです。

下記は現在の間違った手順でオーバーロードが解決される流れです。

1. 戻り値の実態オブジェクトを隠れパラメータとして考慮
2. オーバーロードを解決
3. 呼び出し

呼び出し側はまさか戻り値用の隠れパラメータが考慮された上でオーバーロードが解決されるなどとは知る由もないので、この手順を下記のように修正します。

1. オーバーロードを解決
2. 戻り値の実態オブジェクトを隠れパラメータとして考慮
3. 呼び出し

隠れパラメータは呼び出し直前に考慮しろってことですね。隠れパラメータがあるパラメータリスト、ないパラメータリストの2つを管理するのが面倒という発想でコード設計をしてしまったのがいけなかったのかもしれません。原因も明確になりましたし、次回のバージョンアップでキッチリと修正しようと思います。

本日はmark&sweepの手法で実現されるであろう次期ABのGCについてのコーディングを行いました。特に手を加えた部分はスウィープ（メモリ収集）のタイミング。使用メモリが上限値に達するまでは全速力でプログラムが実行されるため、GCが発動しないうちは従来のmalloc/freeを用いたプログラムと同等の処理速度を実現できました。

あとは、GCが発動したときの付加をどのように処理するかという問題と、従来メモリ管理との併用による規制の定義をきちんと行うことです。この点は、プレビュー版をリリースし、皆様のフィードバックを待ちながらコツコツやりたいですね。