対応ありがとうございます。alpha4リリースを明日にでも行いたいです。alpha3からBayGUIで何か追加機能があればぜひ、いつものところに記入をお願いします。†タイマーメッセージ機能を追加しました。sample/non-gui/hello.cppを参照ください。同期版は破棄し、非同期版となっています。下にくっつけると見落とされる危険があるのでageで。大文字+アンダーバーの命名は伝統的にマクロで使う。いう命名を見たらマクロだと思うのが普通。定数をマクロで表現するのはオブジェクト指向的ではない。定数をグループ化して型として扱えるので定数にはenumを使う。マクロではないので命名規則を変えるべき。Monaでenumなのにマクロ的な命名規則になっているものは、歴史的には元々本当のマクロだったものを、ソース互換性を保ったままenumに置き換えた結果だと思われる。いわゆる過去の遺産に縛られているというやつ。ソース互換性を放棄するなら命名を保つ理由はない。BayGUIのメソッドが小文字で始まるのもJava(とWaba)のAPIを参考にしているためで、マクロかどうかというのは考えておりません。いう使い方ができるのを最近知ったので早速採用させていただきました。baysideおや、AWTとAPIを同じにしたいとは変更理由として明記されていませんよね。見れば分かるだろうというのはなしです。Javaを基準にするのか、C/C++的に自然なようにアレンジするか、というのは自由ですが、方針を明確にした方が良いでしょう。どこかで書いたかもしれないですが、もう一度書きます。BayGUIはJava(Waba)を知っている人なら全く違和感なく使えることを目標にしています。残念ながらMonaPJにはJava好きな人が少ないようでちょっと悲しいですけど。いう書き方は抽象的過ぎます。「違和感なく」ということの具体的内容が書いてありません。JavaのAPIと完全互換でない部分に関して、実装上の都合なのか、Javaを参考に自分なりにアレンジした結果なのかということすら明記されていない以上、他人には分かりません。それにあくまでC++なのですから、第三者にしてみれば、第一にC++的にどうなのかと受け止められるのは自然なことです。上記の問題は「決め」の問題なので最終的な結論はBayGUI作者のbaysideさんの方針でよいと思います。ところで最近はクラス用のヘッダファイルでprivate,publicなenumを使うのが好みなのですがconst作戦の方がよいのですかねぇ。ないと通らなかったのでそちらに合わせました。個人的にはあまり綺麗な記述じゃないなぁと思います。bayside行き着くところまで行けば「決めの問題」ではなくなる。AWTのC++用のヘッダがgcjを入れると/usr/include/java/awtに入るから研究しておくべき。トランスレーションなので機械的にJavaに忠実。なるとあとはBaysideさんがBayGUIをどのような形にしたいかってことですかねぇ。ひげぽんJavaを推進する立場であれば、そろそろJITについて真剣に考える時期かもしれませんよ。サブセットで限定的に取り扱うなら、classファイルをasmに変換するツールをJavaで書くくらい出来そうに見えますけどね。APIだけJavaに似せてもC++はC++で、たとえばヘッダとか書くのは面倒なのに変わりはないわけで、それだけではJavaが好きな人にはアピールしないでしょうし。†CVS版に以下の修正を入れる予定です。基本的にはカプセル化(クラスフィールドのprivate化)と可読性の向上が目的です。若干ですがソースの修正が必要になることがあります。†ISO9660ではファイル名・ディレクトリ名に「-」が使用できません。mkisofsに取り込まれたときに「_」に変換されてしまいます。現在のmona.imgに含まれるファイル名に「-」が含まれないように修整します。bayside修正済みです。上のファイル名の件が片付いたら今晩中にもα3をリリースします。不都合のある方はここに書き込みをお願いします。外部にアナウンスするレベルの機能の追加はMona/開発版/0.3.0への追記をお願いします。ひげぽんファイル読み込みバグの修正が完了するまでα3のリリースは延期します。ひげぽんこれからα3のリリース作業を開始します。ひげぽんリリースしました。†secondbootから個別にファイルを読み込めるようにしてローダーに昇格させました。C♯secondbootはC#で書き直されています。src/kernel/secondboot.asmはtools/MonaNET16で生成されたものです。ビルドが.NETに依存しないようにするため、通常のビルドではMonaNET16は無視されます。ルートディレクトリのファイルしか読み込めないため、暫定的に必須サーバー群をFDイメージのルートに置いています。bin/rootには置かずに直接イメージに取り込む形になっています。MONITOR.BINサブディレクトリに対応した後、本来の場所に配置する予定です。ありがとうございます。起動の様子が変わってて面白いですね。こちらだけかもしれませんがエラーが出ました。ひげぽん起動時にFILEサーバが死にます(ソースはCVS最新版です。"連絡帳/200402-200601"ワークエリアの指定を間違えてカーネルを破壊していたので修正しました。alpha2リリースを今夜行う予定です。リリース完了しました。†CDセクタリードのツールをメインに1/30,31あたりにリリースを考えています。不具合等の報告がなければ、2005/01/22-23あたりにリリースする予定です。懸念点がある人ははやめにひげぽんまでお願いします。PDFは資源の節約にはなりますが、閲覧性が悪いので。注文が結構あるようなら頼んでみようかなと。QP出版から出ていたようですが、もう絶版みたいです。少量出版なので料金はちょっと高めになってしまうかもしれません。割込みマスク操作のAPIを追加してよいか?ひげぽんは必要だと思っています。inp8で自作可能ですが間違いの元なのでライブラリを提供したい。enabled時にIR2を自動的にenabledにするか?IR2というのがどのように使うものなのか、それ以外のオプションはIRQ処理では使用していないのかという説明がほしいです。0-15のうち8-15は、スレーブコントローラなのでマスタコントローラのIRQ番号2も割り込み可能にしないと割込み可能になりません。これを自動で行なうかがauto_ir2です。irq番号が8-15でかつ、enabledがtrueの時のみauto_ir2が評価されます。ないようなので追加の方向で検討します。ひげぽんsrc/lib/monapi/io.cppにio関連のコードを集約しようかと。ひげぽん追加に異論はありませんが、こういうシステムの根幹にかかわるAPIは使用制限とかを考える必要があると思います。急いで制限機能を作る必要はありませんが、将来制限されるようになんだなぁくらいの意識で設計するといいと思います。†BayGUI/applicationsについて心当たりありますでしょうか。余裕がないようであればひげぽんのほうで調べさせていただきます。shadowありがとうございました。†0.2.0リリースに向けて、近々カーネルの仕様凍結とRCリリースを行ないたいと思います。仕様を凍結するのは、カーネルのみです。BayGUIや、monesはその限りではありません。(リリース時にどこまでの機能を載せるかは別途相談させてください。)>ALL(ななしさんふくむ)懸念点(賛成・反対)等ありましたらここに書いていただけると助かります。shadow基本lib/monapiも凍結対象となります。他の部分は相談させていただきたいです。ひげぽん漠然とカーネルと書かれていたので、どのファイルが対象かを明確にしたほうが良いかと思っただけです。shadowそうですね。†monalibcにlogprintfを追加しました。monapiでなくて、monalibcにしたのはライブラリのリンクの関係です。†Monaをtek5対応にさせていただきました。monapi-el5.incのように変更してください。eprm:z0のように変更してください。tek5(stk5)の拡張子はBN5DL5EL5EX5を予約させていただきます。tekは主にOSASKで使用されている圧縮形式です。stk5はtek5のサブセット版と位置付けられていて、tek5はstk5の上位互換です。実験の結果tek5(stk5)はbzip2より圧縮率、解凍速度ともよかったです。アプリの起動もかなり目に見えて早くなりますのでどうぞ使ってみてください。bim2binとlzmaのコンパイルがgccだとうまくいかなかったので、挑戦してみてくれる人がいれば大歓迎です。prompt);を使ってください。それ以外は特に何も考える必要はないはずです。bim2binデコーダのライセンスはKL-01、圧縮に利用するLZMAのライセンスはLGPLです。apps/baygui/gbball/GBBALL.EX2.cvsignoreをbaygui関連のディレクトリにおいて欲しいです。baysideMona/binにある2つのexe(OSASK圧縮形式ツール?)はCVSに追加が必要でしょうか。ソースをツリーに追加してMake時にexe生成の方がうれしいです。ひげぽんもしかしてASKA等の外部ツールが必要なのかな・・・それならしょうがないか。ひげぽん外部ツールは必要ないですが、私の技量ではgccでまともにコンパイルできませんでした。shadowすいません改行コードがLFになっちゃってました。ひげぽんにCR+LFに直してもらいました。baysideMONA.CFGとかはどれでも通るようですが、MonitorサーバをCRでもLFでもCR+LFでも通るように書くべきでは?ご指摘の通りですとりあえずMONITOR.CFGに注意書きを書いておきました。何で止まるかがまったく分からなかった。shadowMona上に限ればポインタサイズは4byteなので今回の用途に限ってはセーフだと思っています。意図的に隙をつくことが出来そうなので、好ましい書き方ではないかもしれませんが苦肉の策です。MonaServerのソースをまねしました。shadowGCCのBuiltinってライセンス等の縛りなしに使っていいものなのですか?これだときちんと動きます。__builtin_va_arg確かにMonaServerのものはバグっていますね。(*(type*)((ap+=sizeof(type))-sizeof(type)))元のやつは、自分が持ってるC言語辞典から持ってきたものですが、↑のやつとその変形バージョン↓も載っていました。((type*)(ap+=sizeof(type)))[-1]↑をCVSに反映しました。infoなど修正候補の調査に入ります。†baysideさんによりBayGUIがソースツリーに追加されました。monitor.cfgのoldshell.ex2をコメントにしてbaygui.ex2をアンコメントすれば起動します。作成しないのでしょうか?monalibcを利用していないのでノータッチです。Tinoさんじゃありませんでしたか、すみません。sprintfをDLLの中から使いたいなというのが主旨です。monalibcの中の人です。DLLのほうにノータッチだったので考えてなかったのですが、やり方がわかったらやっておきます。俺がやるぜって人がいたらやってもらえると助かります。shadowとりあえず、Makefileだけ、それっぽいのを書いてみた。普通にコンパイル通るけど、中身はいじってないのでまだDLLとしては使えません。shadow中身をいじらなくても良かった感じ。?質問の意図が分からないのですが、strcpyは、MonAPIのstringのほうにあります。つくっているのはどなたですか?string.hにstrcpy、monalibc.hにstrcpy2があるようです。2の方は、書き込みバイト数になっています。†CVS最新版(2004年7月10日現在)で移行可能なアプリはPEに移行しました。TinoまだPEサーバーでDLLをキャッシュする仕組みを用意していないため、ロードが遅くなっています。近日中に対処予定です。バンドルがELFでもPEでも認識されるように整備していないためvtable周りについては調査中です。再コンパイルせずにDLLだけ差し替えたときのvtableの問題(→FBC問題)と関連するかもしれません。†とりあえず、現在、こんな感じ。Gakuコマンドプロンプト画面dllwrapではなくldを使用するようにしたものをcommitしてみました。コンパイル&動作確認できました。リンクされてないです。Gaku了解しました。†PEの採用に伴ってLinuxをビルド環境から外しました。PJ.http://mona.sourceforge.jp/Linuxサポートの復活のためには以下の選択肢が考えられます。クロスコンパイラを使用サポート担当者がいないので、ノウハウをまとめる人、動作検証を行う人が必要です。ELFのバイナリをPEに変換するツールを作成あくまで構想だけで、実際の作業予定には入っていません。†STLを復活させました。ベースにしたのはSTLport-4.6.2です。Tinoプロトタイプ宣言が混ざっておかしくならないように、システムのヘッダ(CygwinならCygwinの/usr/include以下)を読みに行かないようにしてあります。ヘッダは必要最小限のものだけを入れるように心掛けました。STLの動作テストをしていてmemmoveがバグっているのに気付いたので修正しておきました。デフォルトでSTLのヘッダにパスを通す予定はありません(あくまでオプション)。使用する場合はMakefileに以下のように追加する必要があります。shadow理由は不安だったと聞いています。ライセンスに対する不安ではなく、移植の完成度や中身が複雑でブラックボックスとして扱うことに対する不安から、コレクション関係は自作して、STLは削除したと聞いています。†CVS最新版(2004年7月9日現在)のソースツリーではデフォルトでDLLを生成するように変更されました。TinoCVS最新版(2004年7月5日現在)のソースツリーは以下のように環境変数付きでmakeを呼び出すことでMONAPI.DLLとGUI.DLLを生成するようになっています。TinoデフォルトではDLLは生成されません。アプリはDLLをリンクするようになっていません。移行可能なものは移行しました。0xA0000000と-Bstaticを取り除いて替わりに--image-base=0xa0000000を追加して、-lmonapiや-lguiを-lmonapi-impや-lgui-impにします。拡張子はELFではなくEXEにします。-lmonapi-imp※objcopyを呼ばないでください。DLL化の際の注意点DLLでは関数内のstaticインスタンスのコンストラクタが呼ばれないようなので、関数の外に出します。DLL内には独自の__CTOR_LIST__が存在するためそれは呼ぶことでグローバルや関数外のstaticインスタンスは初期化されますが、関数内のstaticインスタンスについてはリストアップされていないようです。関数内のstaticインスタンスは最初に関数が呼ばれたときに初期化されるので、プロセスの起動時に初期化されるわけではないため、__CTOR_LIST__には入っていないようです。DLL内の関数だと最初に関数が呼ばれたときに初期化されないようです。これはMonaと関係なくWindowsだけをターゲットにしたDLLでも同様の挙動を示しました。対策方法は分からなかったので関数の外に出すことで対処しました。†apps/nongui/ataにHDDANGERというアプリを追加しました。テスト中なので実行しないように気をつけてくださいませ。m(__)m6/25にHDD対応のテストコードであるsrc/kernel/IDEDriver.cppが追加されました。今後ソースツリーをダウンロードしてビルドする際には以下の点ご留意ください。--HDD対応のテストコードがソースツリーに追加されたので以前より実機テストが危険になります。HIGEのなかでのみHDD対応のコードが実行されます。HIGEがdefineされていないひげぽん以外の環境では安全なはずです。Formの順番で破棄する方が無難だということに気付きました。AnaClock)は書き換えました。Formsの動きに近いため)、明示的にOnPaint()を呼ぶ必要がなくなりました。Tino該当するアプリは書き換えました。今までRefresh()ではマウスカーソル表示の制御あり、RefreshInternal()はマウスカーソル表示の制御なしという区別があり、GNOIZ2BGのように頻繁に描画を行うものでは後者を使用していましたが、GUI.SVRで描画領域とマウスカーソルの位置をチェックして重なる場合だけ制御するように変更したため、区別してRefreshInternal()を呼ぶ必要がなくなりました。Tino描画をGUI.SVRで行うようになった関係上、RefreshInternal()を使用してもGUI.SVRへの描画要求が発生しないため更新されなくなりました。名前の通りinternalな用途のための存在になりましたので、アプリ側からはRefresh()のみを使用するようにしてください。該当するアプリは書き換えました。†tan()の実装にcosが0の場合のチェックが必要だと思います。fptanを使用したtanに変更しました。atanの実装が、atan2になってます。atan2をしてみてください。ありがとうございます。atan2両方とも入れておきました。†まだテスト中ですがPEEKを実装しました。詳細仕様は議論/メッセージ/PEEKをご参照ください。TinoさんMonAPI::Message::peekの中身が現在はsyscall_peek()になっていますが、cmesagexxxxを追加した方がよいでしょうか?peek対象にローカルキューを含めないとあまり意味がないので、そうなるとcmessageで書くことになってしまいますが、現状cmessageの存在意義がほとんどないので、微妙です。Tinoしばらく様子見ということで了解いたしました。ひげぽん問題はそう単純ではないのです。peekがあったらローカルキューがなくても良くなるので、cmessageを消してMessageクラスをリファクタリングする方が良いかもしれません。懸念はやはり排他処理で、peek中に追加されたメッセージを見逃さないように注意しないと、例の問題が再発してしまいます。Tino失礼いたしました。peekはシステムコールでかつ割込み禁止状態なのでメッセージ逃しは多分ないと思います。ひげぽん私が言っているのはそういうことではありません。peekされたデータをユーザー側で調べている最中のことを言っています。例の問題はこれが原因でしたから。カーネル内で排他処理を徹底するだけでは補い切れません。言うと、例の問題対策のためカーネルキューにアイテムがある場合は新着を待たずにsyscall_mthread_yield_message()から帰って来てしまうので、カーネルキューに残したまま処理するというpeekの強みが何も生かせません。TinoTinoさんとの協議の結果、以後の議論は議論/メッセージ/cmessage廃止へ移動しました。>Yui_Nekoさんmonacapi更新の際には対応いただけると助かります。†VPC-5.2では、システムを起動させた時間から秒以外が進まないようです。CLOCK.EL2を再起動させても同じです。TinoVPCでは他のOSでも時間がおかしくなるので、VPC側の問題だとは思います。Bochs-2.1.1では異常に早く進みます。タイマー周りは設定で変わるようです。これも仕方ないですね。Tino上記現象確認できました。qemuでもそれぞれ微妙に時刻がおかしいですね。256MB)で試してみたところ、CLOCK.EL2は起動直後に落ちて、マウスやキーボードの反応がなくなって操作不能になってしまいました。同時に動かしておいたTUBE.ELFは動き続けているので、OSは生きているようです。他のアプリではこういった問題はないようです。killedご報告ありがとうございます。時刻取得は割込み禁止領域があるのでそこでアクセス違反が起きているようですね。こちらも実機を含めてテストしてみます。512MB)でも同様の現象が発生しました。clock/Form1.cppで実機の場合dayofweekが0ではなく7で返ってきていて曜日ラベル用配列をオーバーしていたのが原因でしたので修正いたしました。ひげぽん拝見しました。実機でも問題なく動くようになりました。あとはフォントがプロポーショナルなので文字によっては横が切れてしまう問題があるのですが、その件はこちらで直しておきますね。Tinoご確認・修正ありがとうございました。ひげぽんそういえば確かNTでは起動時にだけ時間を取得して、あとはOSで数えていたような記憶があります。そのためサスペンド(NTではサポートされていない)から復帰してもサスペンド前の時間から続行するような現象が起きたはずです。Tinoそれははじめて知りました。†メッセージ消失問題のデバッグのためlibmonapiのprint()と、OLDSHELL.SVRとELF.SVRにあるMSG_PROCESS_STDOUT_DATAのハンドラにデバッグコードを追加しています。Tinoそのため出力が非常に見苦しいことになっていますのでご了承ください。その後、test_higepon.cppのsendの部分にもデバッグコードを入れました。ひげぽんこのコードにより、startguiの際にメッセージのバッファ溢れが検出されました!!続きは議論/デバッグ/メッセージ消失の方が良さそうなので、そちらにもこの件を太字で書いておきました。誤ったメッセージでした。正確にはメッセージバッファの使いまわしの開始の合図のメッセージです。ひげぽんそのことは後で気付きました。Tinoどうやらバグが直ったようなので、元に戻しました。Tinoさん(他の方にも周知になりますが、代表ということで)Clockの部分に記述ミス(コピペのまま?)ってのがありました。応急処置だけしておいたので確認してください。shadow2行分#でコメントアウトして、上に習って記述しました。shadowよく見たら、前のコミットはひげぽんさんだった模様。いうことで>ひげぽんさんも。shadow申し訳ありません。Tinoさんは全く悪くありません。shadowさんフォローありがとうございました。ひげぽん既に回答があるようですが、この件に関して私は関与していません。vsprintfを使っている人。monalibcにitosnとその付属関数uitosnを追加しました。itosは、itosnを呼ぶのみにしました。uitosは、必要なくなったけど、一応、uitosnを呼ぶ形で残してます。itosの依存関係があるため、今回の変更の影響を受けます。基本的な使用には問題ないと思いますが、何か動作に不都合な点、バグ等ありましたら、連絡ください。attributeを追加いたしました。現時点ではこれでエントリがディレクトリかどうか?がこれを見れば分かります。ビルドを通すためにShellとLauncherに修正を入れました。Shellの方は使用例なのでTinoさんの方で好きなように変えていただければ幸いです。機能追加ありがとうございます。いじらせていただきました。Tino>Yuiさん。monacapiのフォローをお願いいたします。思うところがあり、すべて書き直しました。思うところがあり、ロールバックする予定です、すみません。†シェルの内部コマンドKILLを使用する都合上、GUI.SVRに依存するPS.EL2を起動して調べることができないので、シェルに内部コマンドPSを追加しました。cleanをかけても、apps/gui/ps/ディレクトリ内にPS.ELFとPS.EL2の残骸が残ってしまいます。お手数ですが手動で削除をお願いいたします。>Gakuさん他殺用のシステムコールを追加し、ShellでKILL出来るように内部コマンド追加しました。やるならばKILLされますよメッセージを飛ばす方向になる感じでしょうか。GakuKILLが空振りするだけなのでOKだと思います。>Gakuさん--ひげぽんちなみに、終了しているものにKillですが、errorが返れば良いと思います。error自体が嫌いな人もいますし、この辺は好みの差がでるところですね。される可能性が、、、再利用はされないのか。しても気を付けた方が良いと思うけど。Gakutid再利用の件、思いつきませんでした。ご指摘ありがとうございます。ひげぽん自殺するスレッドが死ぬ前に確実にメッセージを投げ返すとか、自殺したら親にメッセージが投げられる機構を作るとかすれば、自殺してくれたかどうかはチェックできますけどね。発行しない対処ができるので。(何か対策は必要だよねってことかな。Gakuそれは、難しい問題ですね。同一IDの再割り当てを遅らせる以外に、いい案は思いつきません。shadow↑の流れは、終了しろメッセージを投げるもののみって感じに読み取れるわけですが、強制終了させるものとあわせて2個とも用意で良いですよね?で、今回は、簡単そうな即終了を実装したわけですから。メッセージの方も議論があるのでそれの決着がついてから、終了メッセージの方も実装したら良いと思います。shadow両方あることを前提に話してます。†GUI.SVRをデフォルトで起動させるのをやめました。MonaGUIアプリを起動させる前に/SERVERS/GUI.SVRを起動させる必要があります。SHELL.SVRの場合はそのためのバッチファイル(STARTGUI.MSH)を追加しました。Tino現状では裏面の再描画をまったくしていないのでハリボテ感ありありなのですが、なるべく早めにまともな裏面再描画を実装します。画面が壁紙で塗りつぶされますが、裏では普通にSHELL.SVRが動いているので、コマンドラインは普通に使えます。これはちょっとまずいのですが、GUI版ターミナルを作って標準出力を受け取るような仕組みを作らないと、どうしようもない部分です。壁紙の再描画だけ実装しました。裏のウインドウの再描画はまだです。Tinoさん>Yui_Nekoさん>shadowさん>Gakuさん議論/PJ管理で話題にでていた。各自宛のメッセージを探しやすくするための仕組みを試験運用いたします。気が向いたら使ってくださいました。MENUから更新チェック(試験運用)をで進んでください。実は他の人の分も作り始めていたり。表示に時間が掛かってるみたいなのが懸念点ですか。とろいと使い辛いですし。-Gakuそうですね。ようにTUBE.EL2(圧縮形式)が存在しないアプリがあります。.ELFを補完して実行できていましたが、現在補完されるのは.EL2です。それでは前述のように.EL2でないアプリは拡張子を省略できないことになってしまいます。そこで:汚い実装なのは分かっていますが、FSサーバーやら、Processサーバーなどがその辺をうまくやってくれるまでのつなぎとして修正してみました。"連絡帳/200402-200601"どうでしょうか?>もう1人のメンテナーのTinoさん。(本当に汚い実装で申し訳ないです)なるほど、このためのCStringの質問だったわけですね。確かに私もtubeが除外されるのは気にはなっていたのですが、ファイルがあるかどうかチェックするのはコストがかかるのと、拡張子の付け替えまでサーバーでやっていいのかという問題があったので、多数派の.EL2決め打ちのままにしていたのですが、ローカルキャッシュという手がありましたか。これは思いつきませんでした。汚いなんてとんでもないです。Tinoとりあえずバンドルにも対応させてcommitさせていただきました。私に構わずcommitしていただいて結構ですよ。私が割り込んだものですから......。あ、CVS環境のそばにおられなかったからなんですね。(^^;)手直し&代理commitありがとうございます。Shellは落ち着いたらきちんといろいろ検討しないとまずいですね。今ははっきり言って動けば良いや・どんどん拡張しようのノリなので。最初にShell作ったときにもっと考えればよかったんですが、誰か(忘れてしまいましたが)にMonaにもシェルが出来たよって自慢するためにでっち上げた記憶があるんですよね。ひげぽんいえいえ、そんなに気にされることはないと思いますよ。それを言ったら私の作業なんか全部間に合わせのでっち上げですから......。Tinoフォローありがとうございます。CString最高でした。私のような富豪プログラミング出身には非常にありがたいです。ひげぽんCStringに大バグがあって、shadowさんからご指摘を受けていたのですが、見落としていました......。†Message::Receiveはメッセージキューを探索してメッセージがない場合ブロックしてしまいます。それだと困る場合があるのでtryReceive()が欲しいです。(メッセージがなければ処理が戻る)。syscall_receive()をラップするイメージです。ひげぽんその前に、ユーザ側でメッセージキューを持つのは推奨されてるんでしょうか?単にMONAPIの一個の機能にすぎませんし。Yui_Neko先日のDLLの懸念事項を考えると推奨されないに傾きそうですね。うまい手法があればもちろんユーザー側にももてるようにしたいです。最大ブロック時間を指定できるようにする(前者)のに加えて、peek(後者)も欲しいなぁという感想でした。Yui_Nekoキューから削除せずに見ることができるpeekと、指定したメッセージをキューから削除することが出来れば、現状のsendReceive()でやっている自前キューは一切必要なくなるとは思います。peekはキューの全メッセージの配列を返せば良いですが、削除のときに任意のメッセージを指定するとなると、メッセージは常に入ってくるので、単純な順番では矛盾が起きかねませんね。なるとメッセージに一意のIDを振っておかないといけないことになる気がします。Tinoとりあえず0.2.0リリース以降にメッセージあたりを整理ということで今回は見送ります。議論/ELF圧縮で議論した圧縮ELFの実装が完了しました。Tino従来の.ELFファイルを単純にbzip2圧縮して拡張子を.EL2にするだけです。対応方法については下のenv/monapi-el2.incをご覧ください。サーバー(SERVERS/*.SVR)には対応しません。アプリケーションから圧縮ELFアプリの呼び出しには、include/monapi/messages.hで定義されているmonapi_call_elf_execute_file()を利用するのが簡単です。LAUNCHER.EL2でもこれを利用しています。引数command_lineにはコマンドライン全体(引数込み)の文字列を渡します。messages.hは雑然としているので、整理する必要があるでしょう。議論/メッセージコード1lineshの対応をよろしくお願いします。Shellを参考にすればいいんですよね?やっておきます。shadowはい、よろしくお願いします。Tino対応しました。エラーコードが-1ばかりなのは悲しいです。shadowお疲れ様です。エラーコードが定義されているものに関しては修正いたしました。下で書いたenv/app-elf.incのEL2版です。Tinoご対応ありがとうございます。ひげぽんmonapi-el2.incを見ていただくと分かると思いますが、cleanの処理も書いてあります。従ってmonapi-el2.incを利用してEL2に対応したものに関しましては、自動的にcleanも対応します。後述のように.cvsignoreは手動での対応となります。Tinoありがとうございました。思いつく部分はEL2対応いたしました--ひげぽんお手数をお掛けしました。GREVERSI.APPもシェルとランチャーの方で対応させましたので、EL2に移行しました。GREVERSIのMakefileを見ていただくと分かると思いますが、バンドルも非常に簡単に記述できるようになっています。TinoEL2を利用したいアプリ作者の方はMakefileの書き換えをお願いいたします。env/monapi-el2.incを利用する必要はありません。出力されたELFをbz2で圧縮して拡張子をEL2にするだけです。app-elf.incを利用したMakefileになっているものに関しましては、その部分をmonapi-el2.incに書き換えて、TARGETから拡張子を外すことでEL2が生成されるようになります。XXX.cvsignoreに*.EL2を書き加えてください。具体的なMakefileの例としてsamples/non-gui/hello/Makefileを以下に示します。†アプリケーションのMakefileを簡単にするため、共通部分を抽出しました。これに合わせてCVSでの関係するMakefileは短くなっています。Tinoコンパイルにはこれを使わないといけないということではありません。Makefileを短くするのが目的です。問題があれば戻しますのでお申し付けください。圧縮ELFのmonapi-el2.incに合わせて、近日中にmonapi-elf.incに名前変更する予定です。これはapp-elfという名前から、アプリ作成に強制されるというイメージがあるためです。事実はそのようなことはなく、手順の簡便化のためのものでしかありません。ご理解をお願いいたします。app-elf.incを使っていたアプリはEL2に移行したため、現在サーバーでしか使われていません。app-elf.incを使っているものはmonapi-elf.incに変更しました。2004//アスキー転送されて折角の美貌が台無しです。Yui_Neko加工・ascii転送共に私が犯人です。NEKO.JPGでとりあえず対応いたしました。文字列クラスを追加しました。Tino最低限の機能しかありませんので、Charingとのマージを希望します。ひげぽんどんな風にマージすればいいですか?Charingには、領域の拡張がないですけど。shadowマージについてですが、Charingで出来てCStringで出来ないこと(sprintfとか)を実装して、1lineshで使えるようにするとか、そういうことを考えていました。Tinoもし想定する使い方が違ってマージする意味がなさそうということでしたら、無理にマージする必要はないとは思います。文字列クラスが乱立するとややこしいかな、と思ってそういうことを書きました。TinoちなみにCStringは*C*har+Stringに由来するので、MFCとは関係ありません。関数名はJavaのパクリです。別途UCS-4を扱うStringがあるという前提の命名です。いちおうUCS-4を扱うStringはMonaGUIのSystem::Stringを想定しています。TinoSTLを復活させることも考えましたが、ひげぽんさんが乗り気でないようなので、やめました。Tinosplitで止む無く(?)MonaGUIのSystem::Arrayを使っていますが、実はSystem::Arrayは独立したクラステンプレートなので、ヘッダだけ#includeすればlibgui.aに関係なく使えるという代物です。shadowCharingでは、関数は大文字から始まり、切れ目っぽいところが大文字となっています。ひげぽんさんの好みかと思ったので同機能の関数はJavaと同じにしました。Java互換を目指しているわけではないので、Javaにない機能を追加することは問題ないです。Javaの命名規則は関数は小文字から始まり、切れ目っぽいところが大文字となっています。周りのコードに合わせて、適当に追加してみます。shadowよろしくお願いします。?そうであるならば、ついでに直しておきます。this->buffer;すみません、見落としていました。お手数ですが修正をよろしくお願いいたします。Tinoとりあえず、1lineshで使っている、insert、removeおよび、remove内でつかってるresetを追加。shadowsetfについては、sprintfの設計見直し予定につき保留。本日(2004年5月3日)正午頃のcommitでメッセージ番号を入れ替えました。それ以前の環境でコンパイルされたバイナリは正常に動きませんので、再コンパイルをよろしくお願いいたします。Tinoこの件はヘッダ位置の移動のついでにあまり深く考えずに行ってしまいました。バイナリ互換性の問題を指摘されましたが、ロールバックは混乱を助長するとのことでしたので、このまま続行させてください。勝手なことをして誠に申し訳ありませんでした。すべては影響を考えなかった私の責任です。Message::reply()を使うと擬似的なRPCが行えます。strが使用できます。msg.arg2);※非同期の一方通行で良いものは単にMessage::send()するだけでも構いません。現在ELFリロケータブル対応のテストをWin32上でテストしています。FATのときと同様にある程度Win32でテスト⇒Monaへの取り込みを行いたいとかんがえています。その際のテストコードを出来ればCVSにとっておきたいのですがいかがでしょうか?MonaのソースツリーにMonaのビルドには不必要なソースが入ってしまうので皆様のご意見を聞きたいです。#ifdefを使って残すのは?MonaGUIではそうしています。CVSに入れたいということなのかと思います。Yui_Nekoテストの趣旨は分かっていますが、テストコードも最終的にマージさせるものと同期させれば別途含めなくても良いのではないかという意見です。0にして残すとか、そんな感じです。Tinoテストコードを構築中(完成まで)もCVSで履歴を管理したいという意図もあって別ディレクトリ(プロジェクトとして)取り込みたいなと思っていたりします。--ひげぽんテストツールからちょっと進めて、Win32上でELFを表示したり加工(リロケート)したりするような、第三者にも参考になるようなツールとしてまとめて、toolsに入れるというのはありだと思います。その際にコードをアップデートしたら連動するように、私がfat_writeでやったような実体の一本化をするのはどうでしょうか?んー...全くお話になってないな。後にMonaに組み込むかもしれない、でも今は関係ないプロジェクトをMonaのツリーに入れてよいか?って事ですよね?なのに、コーディングスタイルを指摘したり、テストコードなのに最初からツールに仕立て上げるとか、大前提が破壊されています。Yui_Nekoお話になっていなくて申し訳ありません。ひげぽんさんと話し合った結果、tools/elf_toolとして入れることになりました。テストコードとそれを利用したELF加工ツールとを兼ねたものです。現在バグ修正したelf.cppとの折り合いが本当に付くかどうかを調査中です。Tinotools/elf_toolに入れました。†env/*.envでCC/CFLAGSを定義しました。C言語をコンパイルする際には、CXX/CXXFLAGSではなくCC/CFLAGSをご利用ください。TinoMakefileでOBJECTSの再定義を忘れないようにしてください。include/monapi/syscall.hをC言語からのincludeに対応させました。†FreeBSDでMonaをコンパイルできるようになったのですが、なぜかファイルの読み込みに失敗してしまうようです。"連絡帳/200402-200601"シェルのtypeコマンドで確認できます。/mona.cfgリンクエラーになったり【エラーではないですが警告が出ていました】実行したときに落ちたりということはありません。SHELL.SVRでも1LINESH.SVRでも同様の問題が発生します。1lineshでは.ELFを補完しないのを見落としていました。1lineshの動きは問題ありませんでした。Linuxで再現するのかどうかが気になります。動作がおかしいですね。Yui_Neko試してみましたが同じでした。Yui_Nekoよく見たらWarningが出ていました。FreeBSDで挙動が違うのはこれが原因っぽいです。../../../lib/monapi.oこの手のWarningが出るのはSHELL.SVRだけみたいです。CygwinやLinuxで落ちるのはファイル名を小文字で渡したときみたいです。TinoMonAPI::Messageの改造(C言語化)やCStringの採用などを行ったところ、なぜかこの原因不明のリンク問題は解消してしまいました。原因が分からなくて気持ち悪いのですが、とりあえず現時点でFreeBSDで問題は起きなくなりました。†いろいろ変わった部分があるのでお知らせです。KEY_MODIFIER_CHARを追加しました。Keyサーバからのmessageの3番目にcharcodeを入れるようにしました。modifiers(メッセージの2番目)にKEY_MODIFIER_CHARビットがたっていれば、コードが入ってます。Keys::IsToCharにkeyTopMapをとるものを追加しました。mapをとらないものは、JP109で動作します。keyTopMapJP109とkeyTopMapJP109Sを与えたものと同じ。keyTopMapは、char[256]を与えてください。Shiftキーに部分的に対応しました。テンキー部分にShiftキーは効きません。キーボードを変える場合、KeyサーバのinitにあるSetKeyMapでセットしなおしてください。ソース書き換えてコンパイル。JP109とUS102を用意してます。USの方は持ってないので、正しく動くかわかりません。独自のmapを与えることもできます。二つ分、用意してください。0.2.0用にこれでfixしようと思っています。長くなるので連絡帳/VESAに移動しました。†そのうち、Make質問ページでも作ってログを移動させます。shadowMona/Make質問所に移動しました。概要は議論/リソースを参照してください。MonaGUI版リバーシを実際にバンドル化しましたので参照してください。System::getBundlePath()によりバンドルであればパスを得られます。これを実装するためPsInfoにpathを追加して、現在のプロセスのPsInfoを得るためのSystem::getProcessInfo()、それを利用してELFファイルのパスを得るSystem::getProcessPath()を追加しました。シェルやランチャーもバンドルを認識するように修正しました。SHELL)を拝見しました。思った以上にすっきりしていてよい感じです。これを標準にしていく方針もありですね。Tino↑リソースのないものまでバンドルにしようという意味ではありませんので、念のため。TinoWABAとかは*.LIBがリソースに該当するので対象かなと思ったりもします。ひげぽん私もそれはちょっと思いましたが、WabaはMonaGUI対応なども進んでいるみたいなので、下手に前のバージョンをいじらない方が良いかと思って手を出しませんでした。Tino了解いたしました。†26日夜騒いでたバグ潰した版に更新しておきました。ディレクトリ拡張に対応したつもりの部分のバグだったので、ディレクトリ拡張が発生しない状況(用意したFDイメージのディレクトリエントリ数が大きい状況)ではバグは発現しないはずです。エントリ拡張の際に落ちて困ったので、以下のパッチを適用したものをcommitさせていただきました。これで正しいか分かりませんが、とりあえず動いているみたいです。いう話になっていたので、更新しておきました。人が増えてきたし、そろそろ、暗黙の了解でやり取りではまずいですね。Gakufat_tool.lzhのfat.cppと差し替えた所、正常に動作することを確認しました。TinoここにGakuさんから更新したという報告があって、ChangeLogにはひげぽんさんがGakuさんのコードをcommitしたとあったので、てっきり最新版になっているのかとばかり思っていました。Tinoどうやらタブをスペース8文字に置換した結果のようですね。Tinoその通りです。M-uで置換できる設定になっているので。ひげぽん方針についてひとつだけ。GakuさんのサイトのライセンスのURLをファイルヘッダにつけていました。ひげぽんちょっと疑問に思ったのですが、ここまで完成度の高いfat_toolが存在するのに、そのコードをベースにして新たにfat_writeを作っているのはなぜなんでしょうか?恐らく歴史的な理由で、もともとひげぽんさんが全部自分で書いていたのが、途中でGakuさんのコードを取り入れたため、今のようになったのではないかとは思いますが。Tinoもし問題がないようでしたら、fat_writeをfat_toolに置き換えた方が良いように思えます。CVSのfat_writeのディレクトリはsf.jpに頼んで消してもらわないといけないでしょうけど。Tino全く問題ありません。ご指摘の通り歴史的な経緯の問題です。「'」の扱いについてmakeと相性が悪かったような記憶がなくもないです。この「'」でないかと。この仕様だと確かにmakeでは使えませんね。stringとりあえず私としては以下のことが出来れば特にこだわりはありませんので、後はお任せします。Tinoファイルがコピーできる。ディレクトリが作れる。MBRが書き換えられる。(今までddを併用して実現していた部分)フォーマットできる。書き換えのみできません。書き込みできる機能を持っているのは不自然ではない。Gakuなるほど、ありがとうございます。Tinofat_tool導入を今まで試みなかったというのが前提で、簡単にリプレースできるのであればリプレースすべきだと思います。ひげぽんシングルクォート問題の対応次第のようですね。それではよろしくお願いします。Tinoこの件に関しては、私はコードを書いた当事者ではないので、勝手に深入りするのは避けたかったのですが、私の書いたパッチにも問題があったため、非常に悩みましたが以下のように対処させていただきました。Tinoシングルクォート問題でfat_toolが使えないので、fat_writeを継続使用としました。ソースを可能な限り同じにするため、ヘッダ周り以外は一切いじらないで取り込みました。インデントもいじっていません。ひげぽんさんがしておられたのと同じライセンス参照の追加を行いました。同じソースが分散すると同期が面倒になるため、インポートしたコードはtools/fat_writeにだけ置いて、カーネルからはそれを参照するだけにしました。一種のヘッダのような扱いですが、fat.cppは実体を伴う点が異なります。ご対応ありがとうございました。インポート方針も今後このような形で行きましょう。--ひげぽんあくまで個人的な意見なのですが、片方からの参照にするなら、カーネルの方にコードをおいて、toolsの方から参照する方がよくないですか?実験的コードとかカーネルには今は要らないけどツールに要る分をtoolsの方のみに置く。toolsの方で動作が確認できたとかいうときにカーネルの方に移す。いう感じが良いような気がしますが、どうでしょうか。src/kernelの中にカーネルのソースセットがそろっているべきという考えです。†どこでも明記していなかったひげぽんがわるいのですが、「コードのインデント幅」について以下のようなルールでお願いしたいです。(ひげぽんの好みなのですができれば統一したいので)ひげぽんが起こしたコードに関しては半角スペース×4を使用(TABは使用しない)PJメンバが提供してくださるコードに関しては独自のスタイルままで、特に半角スペース×4をあえて使う必要はありません。理由:環境によってTAB幅が違う&ひげぽんはエディタでTAB文字を強調表示しているので混ざっているとすぐわかってしまうから。環境によってTAB幅が違うというのは、逆に強みにもなるんですけどね。置換しなくても幅2が好きとか幅4が好きとか変えられますから。TABが混ざっている場合ひげぽんが、TABを半角スペースに置き換えてしまう場合があります。untabify)すみません。上に書いてあることはだいたい分かっていて、エディタがタブを入れたら手で書き換えるようにはしていたのですが、見逃したところが結構あったかもしれません。