OSを作ろうPart15Mona専用

独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドだったのですがMona専用スレッドに移行しました。
OSを作ろうpart11　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1098713480/
OSを作ろうpart10
http://pc5.2ch.net/test/read.cgi/os/1083420872/
OSを作ろうpart9
http://pc3.2ch.net/test/read.cgi/os/1081561384/
OSを作ろうpart8
http://pc3.2ch.net/test/read.cgi/os/1076216434/
OSを作ろうpart7
http://pc2.2ch.net/tech/kako/1066/10669/1066968321.html
OSを作ろうpart6
http://pc2.2ch.net/tech/kako/1052/10525/1052537020.html
OSを作ろうpart5
http://pc2.2ch.net/tech/kako/1042/10423/1042375466.html
OSをつくろうpart4
http://pc3.2ch.net/tech/kako/1037/10370/1037096449.html
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2

一般的な「OSを作ろう」的話題は
http://pc5.2ch.net/test/read.cgi/os/1093825736/
へ誘導よろしく。
本家：http://monaos.org/
開発Wiki：http://wiki.monaos.org/
ひげぽんはてなダイアリ：http://d.hatena.ne.jp/higepon/
ダイアリの広告をほどほどにクリックするとひげぽんのモチベーションが上がるらしい
Mona本「MONA〜2ちゃんねる発祥の手作りOS」発売中。
http://www.amazon.co.jp/exec/obidos/ASIN/4839917639/
http://www.cbook24.com/bm_detail.asp?sku=4839917639

ここから買うとひげぽん氏の収入になるみたい。
http://d.hatena.ne.jp/asin/4839917639/higepon-22

>>1
【過去ログ追加分】
OSを作ろうpart14　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1127467365/
OSを作ろうpart13　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1121690722/
OSを作ろうpart12　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1114611781/
OSを作ろうpart12　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1114611721/

>>2
【一般的な「OSを作ろう」的話題】
OSを作ろうpart12
http://pc8.2ch.net/test/read.cgi/os/1108836476/

Mona 0.3.0alpha7 をリリースしました。

大きな変更点は以下の通りです。

(1) uIP が移植されました。
　　uIP とは Adam Dunkels さんが開発した組み込み向けの TCP/IP スタックです。
　　ドライバー回りは mones2 をベースにしています。
　　IP アドレスは 192.168.100.2 に固定されています。
　　IP アドレスを変更するには /contrib_0.3/Net/uip/Mona/uipopt.h を変更してください。

(2) HTTPDが移植されました。
　　uIP にはサンプルアプリとして HTTP サーバーが収録されています。
　　http://192.168.100.2/ にアクセスすると動作を確認することができます。

ダウンロードはこちらから
　　http://sourceforge.jp/projects/mona/files/?release_id=18288#18288

mona-0.3.0alpha7-fd-bootable.zip
　　Mona のブート可能な FD イメージです。

mona-0.3.0alpha7-iso-bootable.zip
　　Mona のブート可能な ISO イメージです。

mona-0.3.0alpha7-qemu-20050121-tap-windows.zip
　　Mona の CDブート を qemu で簡単に実行できるパックです。
　　TAP 対応版ですので設定をすればネットワーク機能も使用可能です。

mona-0.3.0alpha7.tar.gz
　　MonaNew/contrib_0.3 が収録されています。

なお本リリースでは、uIP、Yamamiさんの成果物が取り込まれています。
また数多くの方々にアドバイスをいただきました。
この場を借りてお礼を申し上げます。

おｋ

QEMU上じゃ重くて使い物にならんな。FDでブートしてみたいもののどう扱えばいいか。

PSPでmonaは動かんのか(´･ω･｀)
まぁキーボードが使えんので起動してもダメだがｗ

>>4-5
QEMU同梱版についてですが、
今までのようにただバッチファイルを起動させるだけではありませんから、
ネットワークの設定手順を入れた方が良いと思いました。
# 面倒そうなので試していません。

そうするとQEMUのREADMEと混在して何が何だかわけがわからなくなるので、
アーカイブのルートにはISOとBATとMonaに関するREADMEだけを入れて、
QEMU自体はフォルダを掘って入れた方が良いでしょう。

>>6
実機でFDブートしてもNE2000を搭載していないとネット周りは使えないですよ。

>>7
PSP上のbochsでOSASKを動かした人がいたはずです。
初期型ファームのPSP自体が既に入手困難ですが。

>>8

面倒そうという意見は同意。
TAPなんて一部の開発者くらいしか使わないですから。

>>6

FD版はシェルが起動するだけで、アプリは何一つ入っていません。
自前のアプリを入れて実行してみたい人用です（MonADKとか）。
8さんのいうとおりNE2000が載っていないとネットワークにはつながりません。
そのうちカーネルが肥大したらFDに入らなくなるなぁ・・

>>9
Linuxみたいなスタンツを採ればいいのでは？

Mona 01(normal)
BAYGUI起動中Escキー連打でエラー発生
[Mona]CD0:messages.cpp/APPD> :34:ERROR: can not connect to GUI.EX5
awt/FontMetrics.cpp:50:ERROR: can not get font!
messages.cpp:34ERROR: can not connect to GUI.EX5
awt/FontMetrics.cpp:50:ERROR: can not get font!
messages.cpp:34ERROR: can not connect to GUI.EX5
awt/FontMetrics.cpp:50:ERROR: can not get font!

前スレの873で指摘された
マウスサーバの不具合が修正されました。
修正コードを提供くださった論拠なしアンチさんありがとうございました。

>>11さん
ありがとうございます。
todoリストに入れて将来的に修正したいと思います。

いまMonaで使えるプログラミング言語ってCとC++とBrainfuckだっけ？

naskも使えます。
http://wiki.monaos.org/pukiwiki.php?cmd=read&page=nask&word=nask

Java
http://wiki.monaos.org/index.php?gcj

D言語
http://wiki.monaos.org/index.php?gdc

C♯
http://wiki.monaos.org/index.php?Mona.NET

wikiが�d�j

>>17さん

復旧しました。
http://wiki.monaos.org/index.php?%CF%A2%CD%ED%C4%A2#edfa7a01

ttp://japan.cnet.com/news/biz/story/0,2000050156,20094209,00.htm

>>19
ずいぶん今更なネタだけど、VFATの話なので念のため。

http://l.pic.to/5zdva

□！！！これを見た貴方は３日以内に死にます！！！■
■死にたくなければ、このレスをコピーして他のスレに　□
□１０回貼り付けて下さい。１時間以内にです！もし無　■
■した場合は、今日寝ている間に富子さんがやってきて□
□貴方の首を絞めに来ます。富子さんは太平洋戦争の■
■時に16歳という若さで亡くなった女の子で、未だに成 □
□仏していないそうです。信じる信じないは貴方次第。　■
■今年になってからこのレスを無視した人で、“呪われ □
□て死亡した人”が続出しています。これは富子さんの ■
■呪い。呪われて死んでもいいのならこれを無視するこ□
□とでしょうね。　　　　　　　　　　　　　　　　　　　　　　　　■
■――貴方がこうしているうちに富子さんが後ろから見□
□ていますよ…。　　　　　　　　　　　　　　　　　　　　　　　■
■□■□■□■□■□■□■□■□■□■□■□■□

まじT-T

保守

富子が成仏してないなら
第２次世界大戦で死んだ人は大抵成仏しているのか？
数百万も無くなっているんだけど、
三日後も生きてる自信100%な俺がきましたよ

Mona OSの導入の仕方がよく分かりません
何とかしてください

バグ報告がちゃんと機能してないような希ガス
まとめたほうがよくね？

>>27
ひげぽんその他の方は基本的に忙しいので、
自分ができそうなことを自発的にはじめてください。

現在Monaは何人で製作してるの？

日本人

>>26
オレもわからねぇ
monaos.org のダウンロード/インストールのページ見ても
インストール方法書いてないし、ダウンロードも色々あって良く分からないし･･･

とありあえず、>>5 のFDブート版と qemu版は出来たけど
HDにフルインストールするにゃどうすりゃいいんだ？

HDDにインストールする方法はまだない。

>>32

あ、そなの？

とりあえず、まずは Wjndows 上で便利に動かせるような
作りかたして、あとから独立したブートOSにもっていく、
アプローチした方がよいような。

ウィンドウサイズを変えても、使いにくくならないような
仮想OSとしてまず成熟させてから、ブートメニューから選択できる
ようにする、とか。

いずれにしても、WinFX，FSより先の未来を頭に描けて、
メディアの接続，ネットワーク接続をホントに自然なものとして
意識できる人につくってほしい。

きずいたら、Windows みたいなのができましたぁって
ならないように・・がんがれ！！！

>>33
おまいもいい事言うなあ・・・・・・・・おまい最高・・・・・・

EFI対応はいつですか？

久しぶりの書き込みです。

uIPをラップしたサーバー(NetServer)とネットサーバーを利用するライブラリ(libnet)をCVSに追加しました。
libnetを利用すると簡単にTCPアクセスをすることができるので、wgetっ ぽいものならば簡単に作れそうです。
ただし、QEMUのTAPのバグ?なのか、長いパケットが途中できれてしまうので次はそのあたりを調べようと思っています。

Monaって最終的に何を目指すの?
最近の開発状況を見てるとWebサーバOSを作ってるようにしか見えない…

個人的にネット見れて、メールできて、動画見れれば満足だけど
ブラウザが難しそう。Flashもあるし、いろいろ面倒だからね。
…Firefox移植か？

10 ：Be名無しさん ：2006/02/05(日) 17:11:04
>>1
Monaってなに？

11 ：Be名無しさん ：2006/02/07(火) 14:06:27
>>10
>>3が誘導してくれている所へ行こう
２ちゃんねらーによるＯＳなんだそうだ

12 ：Be名無しさん ：2006/02/08(水) 20:25:19
けっきょくパクリ糞OSになったけどな

パクリOSにならないためには、既存資産を使ってでも
一歩先予測できないとな。岐路にきたな

FILE構造体はどこにあるんですか・・・？

>>40
tmpmonalibc

>>41
そんなとこに・・・

macで動きますか？

>>43
VirtualPC for Mac なら動きます。

すまんがぴゅう太専用ＯＳ！ＯＳ！ＯＳ！なのでMacとかかっこ悪いコンピューターで動作するかどうかは
自己責任で頼む。

Macでビルド　で　き　ま　す　か　ね　？

>>46
MinGWのクロスコンパイラを自分で用意すればできる筈。

>>47
Monaがcscなんてものを使ってくれてることにきずいた・・・

>>48
Monoのmcsにも対応している。
それにMacにもMSがRotorという実装を提供している。

MonoはMonaのtypoではないので念のため。

Monoは今さっきインストールした。

なんとかカーネルのコンパイルまでは終わったがリンクでこけやがる・・・
VirtualAllocとGetSystemInfoってどこで定義されてるんだ？

>>52
それはWin32のシンボルなので定義はない。
コンパイラオプションでWin32を殺しきれていないっぽい。

>>53
CFLAGSに-U_WIN32と-UWIN32を追加したら通りました。
現在、bim2bin in:MONAPI.DLL out:MONAPI.DL5 -osacmp -tek5 BS:0 eprm:z0のとこ、
かなり時間かかってます。

だめだ、Mac OS Xでのビルドは諦めよう・・・
bim2binが動かず、fat_writeが使えなかった・・・

>>55
後学のため中途半端でいいので
作業に使ったアーカイブを単純に固めたやつと
エラーログを晒していただけませんか？
うｐはwikiにページを作ればいいと思います。

>>56
http://wiki.monaos.org/pukiwiki.php?Mac%20OS%20X%A4%C7mona%A4%F2%A5%D3%A5%EB%A5%C9

把握したニダ<丶｀∀´>

>>57
乙!!
でもごめん、漏れの手元にマックないんだ・・・
IntelMacでXPがブートしたみたいだし
iBookのIntelが出て懐に余裕があれば買うよ・・・（多分

>>58
Intel積んでるMacはMacBookとiMacとMac miniがあるニダ

>>59
はい、それは知っているのですが・・・
ノートを持ってないので買うならノートなんですが
MacBookは高過ぎなのでiBook出るまで待ちますって意味です・・・

やぁ(´･ω･`)
君のクオリティが問われる時がきた。

http://4leaf.iam-hiquality.com/vote.html
このサイトのブサキモ面の山本先生を一位にしようぜ。
2時間につき一票だ。
他のスレにコピペしてくれると嬉しいお。
みんなの成果を期待してるお。

あとちょっとでOS Xでもビルド出来るんはずだ・・・

フル実装なlibcはないんだろうか・・・

>>63
ttp://wiki.monaos.org/index.php?newlib

とりあえずctype.hとstring.hだけ実装した。
面倒くさいニダ

math.h
stdarg.h
stdlib.h
string.h
ctype.h
limits.h
float.h
setjmp.h
stddef.h

まで書き終えた。まだライブラリは作っていない。

newlibのビルドが通ったのでもうlibcは作らないことにした。

すまないニダ

netlib/sample/gikoって動きます？
「接続...OK」とは表示されるけどそのあとなんも起きないんだけど…。

monaのISOイメージをCDRに焼くとknoppix(linux)のようにCDブートOSになるんでしょうか。

>68
TAPの設定はしましたか？アドレスはIP直打ちですよ？

>69
なるよ。

>70
IP直打ちしてます。
QEMU動かしてるホストマシンからping打つと応答はあるので
TAPも設定できてるかなぁと。

MONAのアプリは通常のC or C++ のソースで動くんでしょうか。
それとも違う方法なのでしょうか。

>72
ごくごく普通のC or C++で動きますよ。
もちろんWindowsやLinuxの実行ファイルは実行できませんが・・

ビルドはどのような形式で行えば？

皆さんに。
BAYGUIかMONAFOMEか
私はBAYGUIがいいかと。
メニューバーをOSで提供。
そのためフォトショップのようなウィンドウを大量に使用するアプリでもMONAFOME（WI○DOWS）のようにアプリごとに窓を作らないためスッキリしDESKTOPへのアクセスも窓を最小化OR窓ごとどける必要もなく、たとえばファイルを読み込むときも楽だと思います。
また、M○COS　XのようなEX○OSEのようなことがでるかと思います。
全体のデザインとしてはM○COS　Xのような斬新かつ美しいフォーム　そして使いやすさ　誰にでも簡単に使える　等をコンセプトにしていったらいいのでは？
FRONT○OWやD○CK等のOSが直接コントロールするランチャーソフトも開発してみたいと思います。

>>75
いっそNEXT

あ、でもすごく似てるかも　NEXTSTEPに
ランチャーとか

>75
使えばわかると思うがBayGUIはすぐに壁にぶち当たる
本気なら0から作ったほうがよさげ

>>78
作りたいがGUIの実装なんかしたことないからな

そういや昔Windmillなんてものもあったな


NEXTSTEPが欲しいならGnuStep移植すればいいじゃない

>>75
壁とはなにかい？

>79
簡単なのでもやってみたら面白いよ。
要は四角を沢山描いて、マウスとキーボードが処理できればいいだけだし。

1から作るのはかなり難しいだろうがなｗ

>>80
部品がない
→自分で作る
→親クラス(Component,Container)の必要なメンバにアクセスできない
→Componentから自分で書く必要がある
→Windowクラスもいじりたくなってくる
→自分で全部書いたほうが早いのでは…と思い出す
→めんどくさくなる

なるほど。

無償ダウソ可能となったVirtualServer2005R2で試してみた。
体感QEMUよりちょっと遅い感じ、ｲﾗﾈ…。

QEMUはソフト自体が軽いからね。

ウリはGUIを作ろうと思ったニダ

なので今はXMLパーサを作ってるニダ

空気を読まずに質問。
kernel.hで宣言されてる構造体のDokodemoViewってどこで使われてるの？
デバッグ用か？
詳細ｷﾎﾞﾝﾇ。

ihandlers.cppでdokodemoViewって関数で使われてるけどその関数が何のためにあるかわからん…

ああ、わかった。

>>88
試しに例外割り込み0hを発生させるプログラム書いてみ。
そのときにレジスタの中身をダンプするのに使うっぽい

>>87
?MLパーサと文字コード変換あたりがそろえばWWWブラウザや
2chビューアもすぐだねぇ。
あとはネットの安定あたりか。

ただ作っていて気づいたことが１つ…

D言語で作っちゃった

>>92
http://wiki.monaos.org/index.php?gdc

>>93
Phobosが使えない限りD言語はC以下ですよ

フルにPhobos使うにはlibcがないと…

よく解らんのだけど「ただ使いたいだけ」の漏れが使ってみるってある？
今のところ出来る事はかなり少ないんだよね？
「○○してて××してたらフリーズした」とかの報告程度でも協力になるかな？

>>95なるとｵﾓｰｳﾖ

>>96
ｔｈｘ。う〜ん素人が遊べるほど完成してないんだね。
今後の発展も願って使ってみる。

つーかここの板はIDじゃなくてIPなのか

おれのIPは・・・

junjunnさん見てるかなぁ。
メールしました。

http://cell.fixstars.com/pukiwiki/index.php?The%20Cell%20Processor

>>99
ひげぽんさん・・・

やってみるきない？

　ＭＯＮＡのインストール方法を、どこかのページに貼ってほしいです。
せっかくＯＳなしＰＣ買ったのに、使えないのはなぁ。(゜O゜;
お願いします＞＜

Mona for PS3？　本体買うのが難関そう（苦笑

>100さん
今のところ興味ないです。
あといろいろ今は勉強のときなので正直時間が足りないです。

>101さん
ごめんなさい。
いまのところMonaは実用性がないので全然使えないと思います。

　じゃあ実用性が出る日まで応援します！がんばってくださいｗ
ＭＯＮＡはウィンドウズ内でしか起動できないのかな？、ヽ｀(~д~*)
インストール方法読んで、ＦＤで起動したけど効果なし・・汗
まだまだ私は未熟ですが返事を期待します！

>>101
ＳＵＳＥ　ＬＩＮＵＸ　でも入れて使えば
結構いいよこれ

ttp://wiki.monaos.org/pukiwiki.php?%CF%A2%CD%ED%C4%A2
junjunnさんの大物ってなにかなぁ。
今までの情報からすると、
ファイルIO＋GUI＋ネットワーク＋IME＋2chブラウザ？

ぬるぽ

>>107
ガッ

最近思った・・・　MonaOSって相当変態な環境じゃないんじゃないのかと・・・

>109
詳しく

SHELL.EXEの動きがヤバすぎる。
プロセスが動いてるときにキーボード叩くとシェルが出てきてくれる…

>111
EXEC XXX で実行すればシェルは黙る。
XXX で実行したときは UN*X で XXX & で実行したのと一緒。

>>112
一応黙ってくれたがまだまだ挙動不審

http://nidayume.web.fc2.com/libc/nidalibc.tar.gz

まだまだ関数が充実してないが作ってみた。
main関数のスタートアップは実装出来てない。

>114さん
ダウンロードできないです。

>>115
http://nidayume.web.fc2.com/libc/

こっちにリンク張りました。
あとcrtの実装によりmain関数から実行が出来ます。
$MONADIR/share/configsにnidalibc-ex5.incなどのファイルも追加してあります。

リンク先でダウンロードを試みましたが 404　になってしまいます。

>>117
fc2ってtar.gzってアップロードしちゃだめなんですかね。

http://www.vipper.org/vip280139.zip.html

とりあえずこっちに置いときます・・・
すいません

404でした。
大変申し訳ないのですが http://wiki.monaos.orgのどこかに添付していただけませんでしょうか?

>118さん
Mona Wikiでご意見募集中です。
よろしくお願いします。

まだ開発が進んでいたんだ
地道だなあ…

ファイルシステムの実装が進まないと
将来が無いないのに
よく寄り道ばっかりしてて飽きないよね

ttp://pc8.2ch.net/test/read.cgi/os/1138681234/73-74
>> 73 ：junjunn：2006/08/04(金) 20:47:44
>> 書き込みテスト
>> 74 ：junjunn ◆juNJunRuNQ ：2006/08/04(金) 20:56:03
>> ↑は私っス。
>> IMEとテキストエディタと書き込み機能作ったので
>> Monaの中から日本語で文章打ち込んでポストしてみました。
>> 成功みたい。
>> もう少し安定したら公開します。

> 本日 Mona OSプロジェクトはfile_server_on_linux-0.0.1をリリースしました。
> download
>
> https://sourceforge.jp/projects/mona/files/?release_id=21273#21273
> 開発者向けリリースです
>
> Mona OSのサーバーなどを開発する devloper 向けのリリースです。
>
> file_serverの開発者だけでなく、他の必須コンポーネントやGUIをLinux上で開発するのに参考になると思います。
>
> 特にMona OSの core であるメッセージAPIと共有メモリAPIをLinux上でエミュレートしている部分は再利用が可能でしょう。
>
> file_server_on_linuxとは？
>
> file_server_on_linuxとは、Mona OSのサーバー（ユーザーモードで動作するOSコアコンポーネント）であるfile_serverをLinux上で動作するようにしたものです。
>
> Mona OSプロジェクトでは、Mona OS上で動作するOS機能をできる限り、cygwin/Linux上で開発・デバッグ・動作確認をし、その後Mona OSにportするという開発スタイルを心がけてきました。
>
> これを実践することで
>
> * 開発を安定、成熟したOS上で行うので開発効率が上がる
> * 既存OS上でも動作することが必須なのでポータビリティが上がる
>
> など多大なメリットが得らています。

> 開発の動機
>
> 次期Mona OSのリリースでサポート予定の仮想メモリの実装に必須であったため。
>
> 大きな変更点
>
> 今回file_serverをLinuxにまず移植し、その後に以下の大きな拡張をしました。
>
> この拡張は今後Mona OS本体に取り込まれる予定です。
>
> * VFS/Vnodeフレームワークの導入
> o Solarisなどでも利用されている、ファイルシステムフレームワークであるVFSの概念を導入し、フルスクラッチで書きおこしました。
> o ファイルアクセスをすべてVnode経由でおこなうようになり open/read/write/stat/close/readdirなどのAPIを提供しています。
> o 今後新しいファイルシステムを追加する場合はVFSフレームワークを利用することになります。既存のFAT12も簡単に再利用できたという実績がああります。
> * touch/writeのサポート
> o FAT12に関してMonAPI経由の touch/write を正式にサポートしました。
> * file_serverが提供するすべてのAPIに関してCPPUNITによるテストコードを付加しました。
> * valgrindを利用しfile_serverのメモリリークをつぶしました
>
>
> ひげぽんの個人的な感想
>
> OSの必須コンポーネントであるファイルシステムがまるごとLinuxで動くようになったのは大きなメリットだと思います。
>
> おおげさではなく開発効率は10倍くらいになるのではないでしょうか。
>
> 以前から気になっていたfile_serverのジャングルコードが解消されたのと、VFSについて深い理解が得られたのも個人的にはかなり大きかったと思います。

OS板で呼び出されたので愚痴でも書きます。
プロジェクトに参加しても実質フォークだという疎外感がやるせなかったです。

たとえばかなり昔、STLportを移植して寄贈しました。
しばらくするとSTLはブラックボックスで挙動が怪しいので
気持ちが悪いから独自実装にするとして外されました。
確かにSTLは複雑なので気持ち悪いのは理解できます。

それからかなり経って、ひげぽんさんがSTLに目覚めました。
一貫性がないというか、人の話を聞かないというか、
他人が何をやってもあまり関係ないなと思いました。

GUIに関しては個人的な遊びだと割り切っていたものですが、
GUIに興味はないので勝手にやってねみたいなことを言われて、
またまたやるせなくなりました。

嘘でもおだてるくらいじゃないとね、という感じです。

昨日徹夜で人のパソコンを組み立ててインストールとかしてたのでもう寝ます。
こんな落ちぶれた生活をしている人間に期待しても無駄ですよ。

>>126さん
こんにちは。お久しぶりです。
>STLportの件

まずは移植してくださったことを感謝し、途中ではずしたことをお詫びします。
その一連の流れで不愉快な思いをさせてしまったことは事実なのですみませんでした。

以下は言い訳ですがどうしてそのような振る舞いになったかを説明しておきます。
＞一貫性がないというか、人の話を聞かないというか、
STLportを外したときは
-裏で何が起きているか
-どこまで深追いすればよいか
を見極める技術力がありませんでした。

そして最近STLが自分が思っていたよりも多く使われており信頼されていて優れていることを再認識しました。
また時の経過とともに以前よりはSTLの裏にうごめくものや、Linux周りの知識がついて
ひげぽん個人としてSTLを使うリスクが減ったと感じ、また使うようになっています。(file_server_on_linuxでも使っています。）

という経緯です。

＞GUIに関しては個人的な遊びだと割り切っていたものですが、
＞GUIに興味はないので勝手にやってねみたいなことを言われて、
＞またまたやるせなくなりました。
＞嘘でもおだてるくらいじゃないとね、という感じです。


これまた申し訳ありませんでした。
モチベーションを下げるようなことをいったのは事実なので謝ります。すみませんでした。

GUIに関してはMonaFormsやBayGUIやjunjunnさんによる実装など、Monaは大変恵まれていると思っています。
それはとてもありがたいことです。

井上さんがひげぽんはもっとGUIに入り込んできたほうが、モチベーションがあがるということであれば、もちろん参加する意思はあります。（勉強になりますし。）

>>128
どうもご無沙汰しております。
お返事が遅くなってすみません。
片道2時間の通勤で午前様だったもので……。

STLの件ですが言い掛かりみたいになってすみません。
多分そうだろうとは思っていました。
価値が理解できなかったのは未熟だったからということは、
一見不可抗力ですが実は根が深い問題です。
STLに限らず同様のパターンが繰り返されていると感じます。

他人が意味不明のことを持ちかけてきた場合に、
無視するのも丸投げするのもあまり良い対処ではないです。
一期一会と言う言葉があるように縁というものは一瞬で、
後で気付いてももうその人はいないのです。
かと言って丸投げすると、その人がいなくなったら行き詰ります。
人と人との関わりはそのようなものです。

普通は二度目はありません。
今回のように後になって掘り返すということは珍しいことです。
というわけで技術的な面ではなく処世的な面で重要な問題だと考えています。

>>129
いえいえ、別に悪いことをされたわけではないので、
謝っていただく必要はありません。
私が勝手に押しかけただけですので。

「やるせない」などと書いたので精神論みたいな話になってしまいましたが、
現実問題としてモチベーションよりも重要なものは必要性です。
やる必要があれば興味がなくてもやらないといけないからです。
逆に言えば、やる必要がなければそれは蛇足であるわけで、
モチベーション次第でやるかどうかを決めることになります。

つまりモチベーションの問題になった時点で
それは必要不可欠なものではないということになります。

GUIが作れそうかどうか確認してみるというのが当初の目的でしたが、
いずれGUIは必要になるだろうと考え、
少しでも手本になればと考え続行しました。
その目的がなくなったのでやる必要がなくなったということです。

というわけで精神的な面よりも事実関係が重要な問題だと考えています。

問い詰めるような展開になるのは好ましいことではありませんから、
話題を変えてなぜ私がMonaに手を出したかという話でもしましょう。

もともと私が興味を持っていたのは開発手法についてです。
業務用の定型アプリなどでフローを描くだけのようなものがありますが、
本当に画期的な手法であれば汎用的に使えないといけないと考えています。

ある手法が汎用的に使えることを実証する最も手っ取り早い課題として
真っ先に思い浮かんだのがOSです。
というわけで私はOSを作るということそのものではなく、
それに使う手法の方に関心を持っていました。

そのことは最初にSTLを寄贈したときのやり取りで
一方的にまくし立ててお返事が貰えなかった記憶がありますが、
別にそのことを責める気持ちはありません。
そんなことに興味を持つ人は珍しいということは百も承知ですから。

私がMonaを見て感動したのは、開発に特別な環境を用意することなく、
Cygwinでmakeして動くものが出来上がったという点に尽きます。
前述のように漠然と
・OSを作ることができれば何だって作れるだろう
と考えてはいましたが、それはあくまで妄想の類で、
それを調べて実行に移すような気持ちは更々ありませんでした。
特定用途のクロスコンパイラを用意して面倒な手順が必要だという
先入観に捉われていたわけです。

それが普通のCygwinでmakeするだけで出来るのです。
想像していたような極端に複雑な手法は使われていません。
これには本当にカルチャーショックを受けました。
こんなものを作り上げたひげぽんさんというのはどういう人なんだろうと、
Monaよりもひげぽんさんの人となりに興味を持ちました。
匿名で事情がありそうなので詮索したりはしませんでしたが。

もっともコードやMakefileなどを見ると不慣れなのは一目瞭然なので、
技術的に変な幻想を抱いたというわけではないです。
逆に勉強しながらここまでまとめ上げたことに後世畏るべしと感じました。
そこで、私の知っている情報は惜しみなく提供して、
もっと勉強を加速してもらおうと考えるようになりました。
というわけでMonaよりもひげぽんさんの能力に関心があったのです。

手始めにSTLを移植してみたのは、当時のMonaを見て、
それがどのくらいの可能性を秘めているか確かめたくなったからです。
そのためにSTLは規模と作業量でちょうど良いと判断しました。
結果、遊びではなく、真面目に検討に値するとの結論を得ました。

ですがOSそのものに関心があったわけではなかったので、
開発や議論に参加しようという意思はありませんでした。
ですからそのときはMakefileなどに簡単なアドバイスだけして、
私自身もスレなどで名乗ったりせずにヲチに徹しました。

後にユーザープロセスが動かせるようになって、
これならGUIも作れるんじゃないかと思って確認のために試作しました。
予想外の反響があったので名乗ることになってしまいましたが、
まあ裏でこそこそするのも限界があるし、という程度の感覚でした。

というわけで私のスタンスは見極めるために簡単なテストをすることと、
ひげぽんさんの勉強に貢献しようということがメインでした。
OS自体の開発に貢献しようと考えていたわけではありません。
この辺のスタンスが異常だったので色々と誤解を産む結果になりましたが。

現時点では、ひげぽんさんの興味の方向性が私と異なるのが明白なので、
距離を置いて干渉する気もありません。
私の知識はひげぽんさんが勉強したいと思っていることに役に立たないでしょう。
たとえばLISPや関数型言語の知識はありません。
C/C++に関しても、既に私よりもお詳しいでしょう。

あと個人的なことを言うと、LinuxもGNUも大嫌いなので、
可能な限り避けたいと思っています。
というわけでもう私は用済みというか、出る幕はないでしょう。

今日はもう寝ますのでこれまで。

>>135
うちに来ませんか？

>>135
必要なツールが cygwin だけで済むというのが Mona の魅力の一つであったことに同意です。
いきなり開発が SVN になったり、STL を多用したり、Linux に突っ走ったり・・
というのを見ていると冷めますね・・自分も距離を置きたくなります。
でも、GUI のときのいきなりの引退はやるせなかったなぁ・・

この際これで行く！
ってやつ真剣に決めたほうがいいのでは？？
これ以上開発ツールに振り回されるとちょっと…

>>136
続きは乗っ取られたスレに逝きますね。

>>137
私が混乱を助長させた面があることと、引退の件は申し訳ありません。

私の皮算用ではひげぽんさんのGUIが私のものを置き換える形で開発が始まって
それを見守りつつフェードアウトさせるつもりだったのですが、
（ちょうどmonesに対するmones2のような形を期待していました）
その意思はないときっぱり拒否されたので打ち切りにしました。
当時私のGUIは叩き台であると強調したのは本音です。

私の引退が影響するのは関係者だけだろうと考えていたので
関係者には事前に打診して了解を得たつもりだったのですが、
それ以外の方からも予想した以上に反響があったのは意外でした。

ともかく技を伝授しようという意思はありましたが、
自分で何かを作って貢献したいという意思はありませんでした。
ぶっちゃけC/C++は嫌いだしエディタでゴリゴリ書くのも嫌いなので、
みんながびっくりするような凄いものを作るのは無理です。

井上さんへのお返事
> どうもご無沙汰しております。
> お返事が遅くなってすみません。
> 片道2時間の通勤で午前様だったもので……。

どうもこんにちは。遅くまでお疲れ様です。

> STLの件ですが言い掛かりみたいになってすみません。
> 多分そうだろうとは思っていました。

いえいえとんでもありません。
STLの件に関しては、こちらに非がありますので。

> 価値が理解できなかったのは未熟だったからということは、
> 一見不可抗力ですが実は根が深い問題です。
> STLに限らず同様のパターンが繰り返されていると感じます。

同様のパターンが繰り返されているとの指摘はその通りだろうと思います。
それまた私に非がある部分だと思います。

> 他人が意味不明のことを持ちかけてきた場合に、
> 無視するのも丸投げするのもあまり良い対処ではないです。
> 一期一会と言う言葉があるように縁というものは一瞬で、
> 後で気付いてももうその人はいないのです。
> かと言って丸投げすると、その人がいなくなったら行き詰ります。
> 人と人との関わりはそのようなものです。

これまた特に反論もありません。
このようにするべきだろうし、過去に自分ができていなかったのであれば謝ります。ごめんなさい。

何故過去にそのようなことが発生していたか？を分析するに、私の姿勢の甘さももちろんですが技術面での弱さが理由の大半だと考えています。
これはある技術について知っているとかそういう話ではなくて
-未知の技術に対峙したときに、過去に学んだ技術から類推できる
-検索や調査に関して効率的な方法を身に着けている
-人のソースコードを読む技術がある
と言うような話です。

例としては悪いかもしれませんが、例えば井上さんは参照カウンタにより delete しなくて済む仕組みを導入してくださいました。
これはGoogleでそれらの用語を検索して用語の意味を調べて、ソースを見て、井上さんに2、3質問しただけではなかなか理解できるものではないと考えます（天才なら別ですが）。
深い理解には、上であげた基礎力（IT系全般の基礎体力のようなもの）があってこそ
-スマートポインタなどの導入の動機
-アルゴリズムの概要
-他の言語での導入事例
-実際に使ってみる
-C++のデストラクタ等をうまく利用したテクニック習得
のように、いろいろ学べて血となり肉となるのではないでしょうか。

この自分の弱点は自分でもきちんと分析理解できているつもりで改善につとめてきました。
例えば、どんな用語を言われても「？」となってしまっていたネットワーク系を実装を通して学んだのもそうですし、情報系の学生であれば教科書として読むことが多いSICPを読んでいるのもこれを意識してのことです。
あとは完全にブラックボックスになりがちなコンパイラ／インタプリタについても知りたいのでSchemeインタプリタを作っています。
また関数型言語とか再帰とかになると思考が停止する自分が嫌だったのでそれも合わせて勉強しています。

長くなってしまいましたが何が言いたかったかといいますと以下2点に集約されると思います。

-井上さんを不快にしてしまった点は本当にごめんなさい。こちらに非がありました。
-現在ではひげぽんも（ある程度は）基礎体力もついたのでこういうことは起こりづらくなったと思いますしさらに改善します

> 「やるせない」などと書いたので精神論みたいな話になってしまいましたが、
> 現実問題としてモチベーションよりも重要なものは必要性です。
> やる必要があれば興味がなくてもやらないといけないからです。
> 逆に言えば、やる必要がなければそれは蛇足であるわけで、
> モチベーション次第でやるかどうかを決めることになります。

はい。理解できます。

> というわけで精神的な面よりも事実関係が重要な問題だと考えています。

はい。ここも理解できました。

> 問い詰めるような展開になるのは好ましいことではありませんから、
> 話題を変えてなぜ私がMonaに手を出したかという話でもしましょう。
>
> 略
>
> それに使う手法の方に関心を持っていました。

ふむふむ。

> 私がMonaを見て感動したのは、開発に特別な環境を用意することなく、
> Cygwinでmakeして動くものが出来上がったという点に尽きます。
> 略
> 匿名で事情がありそうなので詮索したりはしませんでしたが。

大分背景が見えてきたとともに、誤解していることが分かりました。
例えば井上さんはGUIマニアで、GUIを作ることが楽しくてそれが目的なのだと思っていました

> もっと勉強を加速してもらおうと考えるようになりました。
> というわけでMonaよりもひげぽんさんの能力に関心があったのです。

とてもありがたいことです。今さらかもしれませんがありがとうございます。

> というわけで私のスタンスは見極めるために簡単なテストをすることと、
> ひげぽんさんの勉強に貢献しようということがメインでした。
> OS自体の開発に貢献しようと考えていたわけではありません。
> この辺のスタンスが異常だったので色々と誤解を産む結果になりましたが。

> 現時点では、ひげぽんさんの興味の方向性が私と異なるのが明白なので、
> 距離を置いて干渉する気もありません。
> 私の知識はひげぽんさんが勉強したいと思っていることに役に立たないでしょう。
> たとえばLISPや関数型言語の知識はありません。
> C/C++に関しても、既に私よりもお詳しいでしょう。

ここは否定しておいた方がよさそうですね。
まず興味の方向性はまったく同じではないと思います。それはまぁ人それぞれなので。

ただ私が関心があるのは、自分の持っていない技術なので
井上さんが持っていて僕が持っていないものは例えば
-GUIに関する知識(API/フレームワーク)
-移植力
-C++の知識(MonaFormsのコードを見れば私よりはるかに良く理解されていることが分かります。)
-一度決めてから実装にいくまでの時間の短さ
-困難なものを小さく細かいタスクに分けるなどの一般的なノウハウ
-Makefileなど開発ツールのノウハウ
-Windows API/FreeBSDなどのAPIの知識
などなどは、私が井上さんからぜひとも盗みたいと思っているものです。

> あと個人的なことを言うと、LinuxもGNUも大嫌いなので、
> 可能な限り避けたいと思っています。

ここはまぁひとそれぞれ好みはあると思うのでありだと思います。

> というわけでもう私は用済みというか、出る幕はないでしょう。
> 今日はもう寝ますのでこれまで。

長文書き込みありがとうございます。
まず尊重すべきは井上さんの意志だと思います。
ひげぽんやMonaと一切かかわりたくないということであれば、残念ですが仕方のないことだと思います。


ただ今回の書き込みで、お互いのスタンスの違いや誤解があったことが発覚したと思うので、誤解が解けて「手なり口なりをだしてやってもよい」と思われたのでしたら歓迎です。

>>137さん
> 必要なツールが cygwin だけで済むというのが Mona の魅力の一つであったことに同意です。
> いきなり開発が SVN になったり、STL を多用したり、Linux に突っ走ったり・・

Baysideさんかな？（違っていたら申し訳ありません）振り回して申し訳ないです。
Subversionはもちろん cygwin でも普通に使えますしCVSから移行するのに大きなメリットがあると判断したので移行しました。
Subversionに移行することで
-履歴を保持したままファイルのリネーム／移動ができるようになった。→ツリー構造をダイナミックに変えることができるようになった。
-svn:externalsでソースの重複を避けられる

STLも同様に使うことのメリットは大きいですしcygwinでも使えます。
またBoostまで行くとやりすぎえですが、STLは一般的なC++プログラマであれば読みやすく使わない理由はあまりないかなぁと思っています。
私個人は、Linuxの開発環境に移りつつありますが今のツリーはcygwinでもビルドできていますし、他の開発者の方が無理にLinuxにつっ走る必要なないと思います。

>>138さん
どのあたりが振り回されているとお感じでしょうか。
開発ツールをある程度固定化するのは賛成なのでご意見おきかせください。

>>137
失礼ですが、ひょっとしてbaysideさんでしょうか？

開発環境に関しては、私はGNUが嫌いなので、Cygwinも嫌いで、
最終的にはVS環境に持って行きたいと考えていました。
これはLinux化よりも遥かに恨みを買う行為で、
現段階で賛同する人は誰もいないでしょうけど……。

その前哨戦のブートローダのC#化で既に相当恨みを買いましたが、
（もう周知の事実だと思いますがcsharpは私です）
この時点では事前にひげぽんさんに
「ポインタやヘッダに振り回されるC/C++はもううんざりじゃないですか？
C#やJavaが使えるなら移行しますよね？」
と強引に持ちかけて同意を引き出した（と私は解釈した）上で行いました。
もっともブートローダから手を付けるとは言いませんでしたけど、
正月休みの間にやっつけで出来る範囲がブートローダだったのでした。

その後、ひげぽんさんの興味はどんどんC/C++に傾いたので、
GUIのときと同様、続けても無意味だと思って打ち切りにしました。
この時点でひげぽんさんと興味の対象がまったく異なるということは自覚しました。
もちろん責めているのではありません。単なる考え方の違いです。

今日の書き込みはここまでです。
長文失礼しました。
さて開発に移ろう。

>井上さん
VS環境への移行はかなりびっくりですが(笑）
bootコードをC#化したのはかなり良かったと思っています。
またYumeさんが電源対応でsecondbootをいじってくれているのですが
そこでも活用されています。（し、ひげぽんもコードが見やすくて好きです。）

>>141
> 何故過去にそのようなことが発生していたか？を分析するに、
> 私の姿勢の甘さももちろんですが技術面での弱さが理由の大半だと考えています。
私はその時点で理解を求めてはいないのです。
世間の大半の人はWindowsやOfficeを使うのに実装を理解していませんが、
それと同じことです。

勉強というのは教科書的に演繹することだけではありません。
資料も何もない泥沼の中でもがきながら帰納するというのも一つの方法です。
私がひげぽんさんに必要だと考えていたのは後者（帰納）の手法です。
>>141の見解は前者（演繹）の価値観から抜け出せていません。

私が物事を簡単に扱っているように見えるのは、
中身を完全理解しようなどと考えていないからです。

>>142
> 例えば井上さんはGUIマニアで、GUIを作ることが楽しくてそれが目的なのだと思っていました
もちろんそうです。だからGUIを作る楽しさを伝えたいということです。

>>143
> まず興味の方向性はまったく同じではないと思います。それはまぁ人それぞれなので。
これは極端です。まったく同じなどということがあるわけがありません。
私がひげぽんさんに期待していることにひげぽんさんは興味がないし、
その逆もまた然りということだと認識しています。

>>144
> ただ私が関心があるのは、自分の持っていない技術なので
> 井上さんが持っていて僕が持っていないものは例えば
買い被りです。
大半はただ使っているだけで、本当のプロから見たら鼻糞みたいなものです。

> ただ今回の書き込みで、お互いのスタンスの違いや誤解があったことが発覚したと思うので、
> 誤解が解けて「手なり口なりをだしてやってもよい」と思われたのでしたら歓迎です。
これは>>149で書きましたように、物事を取り扱う際の切り口が違うのだと思います。
人それぞれで済むと言えば済む問題なので、食い下がる気はありません。

多分、私がうざいことを言うと感じておられることの大半は、
教科書的な完全理解を前提にした膨大な労力を回避するためだと感じます。
そんなことは要求していませんし、自分自身そのような境地にありません。

ともかく今更蒸し返すような問題ではないと思いますし、
それがお互いのためだと思います。

>>145　開発ツールも確かにこれでＯＫってのが無いかな　と思っていました。　考え方は>>137と同じですが；
開発方向の点でも解決すべき点が少し散らばりすぎていると思います。
現段階での優先順位を決めた方がいいのでは？？　と思います。
それから一度開発者全員に確認を取ってみるのもいいと思います。　
こんなこと言っていいんですかね…

それから
file_serverをLinuxに
fat_writeがMacOSXに対応
ありますが方やPC/AT　方やMAC
これは多少まずいのでは？？

>>152

fat_write に関しては、MacOSX で Mona をビルドする際の障壁のひとつだったので。
移植性の面からいってもそう変なことではないでしょう。
file_server の linux への移植も gdb でデバッグするために必要です。
開発方向が散らばっているのは、もともと Mona は好きなひとがすきなように
いじるための OS なので、しょうがない面もあるでしょう。

>>152
Mac OS X対応と言ってもエンディアン絡みの部分だけですよ。

私は全般的に、井上さんの行動に関しては井上さんの意思を尊重するべきだと思っています。
以後の私の書き込みはそれを前提にしています。

> 私がひげぽんさんに必要だと考えていたのは後者（帰納）の手法です。
> >>141の見解は前者（演繹）の価値観から抜け出せていません

演繹・帰納の相反する方法のどちらの重要性も認識しています。
前者は井上さんもおっしゃっているような教科書的なもの→SICP
後者はScheme,ネットワーク,Perlなどといろいろな特殊環境に身をおいてその中から一設計の類似や背景などを理解する
というので実践していると考えています。

> 私が物事を簡単に扱っているように見えるのは、
> 中身を完全理解しようなどと考えていないからです。

これはなるほどと思いました。
私は井上さんと比べると中身を完全に理解しないと落ち着かないタイプなので、そこが成長のボトルネックでもあり期待できる部分だと思っていてバランスが難しいですね。

>もちろんそうです。だからGUIを作る楽しさを伝えたいということです。
GUIが作れるかという興味とともに、楽しさを伝えたかったのですね。理解できました。

> 私がひげぽんさんに期待していることにひげぽんさんは興味がないし、
> その逆もまた然りということだと認識しています。

ここは誤解があるかもしれません。
私は、本であれプログラミング言語であれ、音楽であれ、自分の尊敬する人が「すごいからとりあえず試してみろ」と言われれば試すタイプです。（or そのつもりです)
これは、優秀な人が強く勧めるものには外れが少ないことを今までの人生で学んだからです。

> 買い被りです。
> 大半はただ使っているだけで、本当のプロから見たら鼻糞みたいなものです。

となると私は鼻糞未満ということになります。だからこそ勉強しようと思うわけですけど。

> ともかく今更蒸し返すような問題ではないと思いますし、
> それがお互いのためだと思います。

井上さんが不愉快であったり面倒であればいつでも返事を書くのはやめていただいてかまいませんし、もしそうなっても私は十分元は取れていると感じています。
Mona・ひげぽんの問題点をきちんと言葉にして書いていただいたのですから。

>>151さん
具体的な不満、たとえば「ｘｘｘツールが使いづらい」「ｘｘｘの導入は失敗だった」などありましたらぜひご指摘ください。
ほかに参加いただいている方も何かあれば遠慮なく書いてもらうのが良いと思います。

>>152さん
これは 153,154さんがフォローしてくださっているとおりです。

売り言葉に買い言葉みたいになっているので立場を整理しておきますが、
私が一方的に良かれと思って押し付けた提案の大半が拒否されたので、
有難迷惑なのだろうと考えて距離を置くことにしたということです。

そうでなく、どうぞひげぽんさんに関係なく、ご勝手に進めてください、
ということで事態の収拾を図るという選択肢も理解は出来ますが、
これは実質ひげぽんさんを抜きにしてMonaと関わるということを意味します。

私の中ではMonaからひげぽんさんを取ったら何の意味もないというか、
開発ターゲットにわざわざ茨の道を選ぶ意味がなくなってしまいます。
そのため距離を置くことになるわけです。

見方を変えると、意見が通らなかったから怒って出て行ったことになりますが、
出て行かなかったとして何かすることがあるかと言えばないわけです。
やりたいと思っていたことが拒否されたら、やることがないわけです。
その状態で出て行かなければ、粘着して何度も蒸し返すくらいしか
やることがなくなってしまいます。
そんなことをしたら迷惑なのは明白です。だから袂を分かつのです。

拒否されて手持ち無沙汰になってしまうのは、
提案を拒否する理由が、興味がないとか、時期尚早であるとか、
不要とか、存在理由自体を否定するようなものだからです。
問題の存在を認めた上で方針との不一致を指摘して、
方針に沿った代替解決案が示されているわけではなく、
問題自体の存在が不問に付されているということです。

>>155
> 私は全般的に、井上さんの行動に関しては井上さんの意思を尊重するべきだと思っています。
これは私も同様です。
ひげぽんさんの意思を尊重するべきだと考えているからこそ、
拒否されたことに関しては諦めるわけです。

> 演繹・帰納の相反する方法のどちらの重要性も認識しています。
> (中略)
> というので実践していると考えています。
実践しておられるのであれば、>>141の見解に反映できますか？

私が指摘しているのは、
・技術的に未熟なので理解できるわけがない
という問題は回避可能なので理由としては認められないということです。

回避策は遅延評価を前提にブラックボックスを扱うという方法です。
遅延評価というのが重要な点で、言い換えると、
いつか分かる日が来るべきであるということを期待しているので、
ブラックボックスとして理解を諦めろということは意味しません。

> となると私は鼻糞未満ということになります。だからこそ勉強しようと思うわけですけど。
この見解には違和感があります。技術的にはもう私より上です。
勉強する内容は技術的なテクニックとか知識とかではなく、
運用上の意識とかマネジメント技術とか、そういう内容だと私は考えます。

残念ながらそういう方面ではほとんど成長が見られないというか、
そういう分野の存在がかろうじて認知されてはいるものの、
自分が勉強すべき対象として意識されていないように見受けられます。

>>155
> 私は井上さんと比べると中身を完全に理解しないと落ち着かないタイプなので、
> そこが成長のボトルネックでもあり期待できる部分だと思っていてバランスが難しいですね。
はい、それが伝わったのであればわざわざ出てきた甲斐がありました。
まさにそこがボトルネックになっていると感じます。

現時点でのバランスは演繹に異常に傾き過ぎに見えます。
完全理解のために再実装をして確認することが勉強であるという意識が
前にも増して強くなっているように感じます。
もっともMona自体がそういう意識の産物ではありますが。
（OSを再実装することで完全理解するという類）

それはそれで一つの個性というかスタンスなので否定はしませんが、
私が>>158で書いたような遅延評価の運用意識が身に付けば、
おそらく扱える規模が今の10倍というか一桁は上がります。
分割前のMonaのツリー程度の規模のものは軽々把握できるでしょう。

そうなると末恐ろしいものがあるというのが正直な所で、
見てみたいと思ったからこそアドバイスをしようとしたわけです。

>>155
> GUIが作れるかという興味とともに、楽しさを伝えたかったのですね。理解できました。
はい、それは良かったです。

ちょっと脱線しますが、私がGUIに固執する理由は単に好きだからではなく、
情報は視覚化するべきであるというもっと根源的な理由があります。
簡単に言うと、スプレッドシートに延々と測定値だけが並んでいても、
分析しないとほとんど意味がない数字の羅列でしかなく、
グラフにしたり（＝視覚化）して分析を進めないといけません。
そういう観点から実装技術の基盤としてGUIを必要としているわけです。

このことは私が開発手法に固執していることと関係していて、
たとえばコードにおける変数の遷移をグラフにしたりするとこに、
スプレッドシートで数値を視覚化するのと同様の効果を期待しています。
私が本当に追求したいと思っていることはそういうことで、
新しい技術で開発するというイメージで思い浮かべることです。

ここまで書けばもうお気付きと思いますが、そのことに、
Monaが積極的に新しい技術を採用して開発するというイメージを重ねました。
片思いというか、一方的な幻想の類ではありますが。

今までこのことを具体的に書かなかったのは隠していたわけではなく、
単にそこまで話が進む前に頓挫してしまったというだけのことです。

>>156
> 「すごいからとりあえず試してみろ」と言われれば試すタイプです。（or そのつもりです)
マネジメントの観点から、Mona全体の履歴やto doを含めたPERT図を描いてみることをお勧めします。
個別の分科プロジェクトの管理という目先の話ではありません。Mona全体です。
ですが私の知る限りフリーでPERT図を描くのに便利なソフトはないので、
もし実行されるのであればMS Projectを購入して寄贈いたします。

でもこれだけ書いても何を期待しているのかまったく伝わらないと思います。
抽象的過ぎて何をするのかさっぱり分からない類の提案で
検討する前に直感的に拒否してしまうようなことでしょう。
現実的には、合宿みたいにして二人で描くくらいのことをしないと、
具体的にどう手を付けるのかすら伝わらないと思いますが。

> 井上さんが不愉快であったり面倒であればいつでも返事を書くのはやめていただいてかまいませんし、
> もしそうなっても私は十分元は取れていると感じています。
> Mona・ひげぽんの問題点をきちんと言葉にして書いていただいたのですから。
私の感情を害するとかそういうことはお気になさらないでください。

私が恐れているのは、私と不毛な言い争いをすることで、
不愉快な感情を引きずったり時間が取られたりして開発が滞ることです。

これは私にも実害があって、こうやって公衆の面前でやり取りしているので、
足を引っ張る事態になれば私に集中攻撃が来ることも予想されます。

というわけで私の話に興味がなければどうかスルーしてください。

お返事が遅れて申し訳ありません。
常用マシンへ急遽 Ubuntu をインストールする必要があり、あれこれははまっていました。

> 売り言葉に買い言葉みたいになっているので立場を整理しておきますが、
> 私が一方的に良かれと思って押し付けた提案の大半が拒否されたので、
> 有難迷惑なのだろうと考えて距離を置くことにしたということです。

それは申し訳ありません。そのような意図はありませんとだけまずは御理解いただければと思います。

> そうでなく、どうぞひげぽんさんに関係なく、ご勝手に進めてください、
> ということで事態の収拾を図るという選択肢も理解は出来ますが、
> これは実質ひげぽんさんを抜きにしてMonaと関わるということを意味します。
>
> 私の中ではMonaからひげぽんさんを取ったら何の意味もないというか、
> 開発ターゲットにわざわざ茨の道を選ぶ意味がなくなってしまいます。
> そのため距離を置くことになるわけです。

略

この思考の流れは良く理解できます。

> >>155
> > 私は全般的に、井上さんの行動に関しては井上さんの意思を尊重するべきだと思っています。
> これは私も同様です。
> ひげぽんさんの意思を尊重するべきだと考えているからこそ、
> 拒否されたことに関しては諦めるわけです。

御理解ありがとうございます。

> > 演繹・帰納の相反する方法のどちらの重要性も認識しています。
> > (中略)
> > というので実践していると考えています。
> 実践しておられるのであれば、>>141の見解に反映できますか？

141の見解に関しては特に変更はありません。
その当時は帰納的な考え方はありましたが、それを実践する基礎力がなかったということだったと自分では分析しています。

> 私が指摘しているのは、
> ・技術的に未熟なので理解できるわけがない
> という問題は回避可能なので理由としては認められないということです。
>
> 回避策は遅延評価を前提にブラックボックスを扱うという方法です。
> 遅延評価というのが重要な点で、言い換えると、
> いつか分かる日が来るべきであるということを期待しているので、
> ブラックボックスとして理解を諦めろということは意味しません。

ブラックボックスとして捉えて、詳細は遅延評価というのは難しさの軽減にはなる有効な手法だと思います。
Monaの開発自体も
-開発ツール
-リンカスクリプト
-ELFの構造
-アセンブリプログラングの詳細
などなどは詳細は知らずにブラックボックスとして捉えたからこそここまでなんとかやってこれたのだと思います。


有効性にはまったく異論がありませんが、「回避可能なので理由としては認められないということです。」は個人的に極端すぎるかなと思います。
例えば、素人に「とにかくgcc hoge.cと打ち込め」と教えてブラックボックスとしては理解させることは大抵の場合出来るとは思いますが
それはあくまでもパソコンをある程度使ったことのある人が対象なわけであって、パソコンを一切使ったことのない老人などにいきなりそれは無理だと思います。
このようにブラックボックス理解にも、その人の基礎力が効いてくるわけです。
上記のようなことを踏まえまして、私は当時は基礎力がなかったと思っています。


> この見解には違和感があります。技術的にはもう私より上です。
> 勉強する内容は技術的なテクニックとか知識とかではなく、
> 運用上の意識とかマネジメント技術とか、そういう内容だと私は考えます。
> 残念ながらそういう方面ではほとんど成長が見られないというか、
> そういう分野の存在がかろうじて認知されてはいるものの、
> 自分が勉強すべき対象として意識されていないように見受けられます。


これはとても良い指摘ですね。ありがとうございます。
客観的な意見を頂けることは大変貴重だと思います。
この話はPERT図あたりにつながると思うので後述します。

> 私が>>158で書いたような遅延評価の運用意識が身に付けば、
> おそらく扱える規模が今の10倍というか一桁は上がります。
> 分割前のMonaのツリー程度の規模のものは軽々把握できるでしょう。
> そうなると末恐ろしいものがあるというのが正直な所で、
> 見てみたいと思ったからこそアドバイスをしようとしたわけです。

ありがとうございます。
もしその見積りが正しいのであれば取り組む価値はあると思います。

> 情報は視覚化するべきであるというもっと根源的な理由があります。

なるほど。

> ここまで書けばもうお気付きと思いますが、そのことに、
> Monaが積極的に新しい技術を採用して開発するというイメージを重ねました。
> 片思いというか、一方的な幻想の類ではありますが。

こういう姿勢は維持したいですね。

> マネジメントの観点から、Mona全体の履歴やto doを含めたPERT図を描いてみることをお勧めします。
> 個別の分科プロジェクトの管理という目先の話ではありません。Mona全体です。
> ですが私の知る限りフリーでPERT図を描くのに便利なソフトはないので、
> もし実行されるのであればMS Projectを購入して寄贈いたします。
-マネジメント力が弱い
-PERT図を書いてみると良い。おすすめである。
という点が理解できました。
PERT図を描いてみようと思います。
ただためすだけでMS  Projectを寄贈していただくのはありえないので、タブレットで描いて私がどこかにアップロードするのはどうでしょうか？
またMona全体の履歴をPERT図にする場合の履歴とはどれくらいの粒度をイメージされていますでしょうか。

>>164
不毛な言い争いになることは承知で、敢えて突っ込ませていただきます。
こういうことをなあなあで済ませていると、いつか必ず表面化します。
スルーしても問題が表面化する時期が遅れるだけ、つまり遅延評価です。（ｗ

> 上記のようなことを踏まえまして、私は当時は基礎力がなかったと思っています。
これは当時を追認しているだけなので、否定しようがありませんし、
そのような話をいくらしても歴史は覆らないので無意味です。

> 「回避可能なので理由としては認められないということです。」は
> 個人的に極端すぎるかなと思います。
以下に「ひげぽんさんは一人ではない」という理由でこれを否定します。

> このようにブラックボックス理解にも、その人の基礎力が効いてくるわけです。
客観的に見て、STLやスマートポインタを使うことが
当時の力量を遥かにオーバーしていたとは思えません。
老人にgccを教えるのとはかなり異なります。
gccを使いこなしている人にclを教えるようなものでしょう。
それはそれでプロプラだとか反発されそうですが、（ｗ
今回の状況もそれに近いものがあるという印象です。

環境的に選択の自由がなく、何が何でもSTLは使わないといけない状況だった場合、
それを使いこなす基礎力が不足している素人の老人状態だったとは思えません。
中身がブラックボックスで気持ち悪いと思いつつ、
使っているうちにそんなものだと思うようになるんじゃないでしょうか。
というか現在のSTLに対する認識がそのような経過を経ていませんか？
だとすれば時期的に前後するかどうかというだけの話です。

私の知る限り、初めてSTLを見て「すごい！」と感動した人はいません。
意味の分からない複雑な構文で拒絶反応を示すのが普通です。
私自身、心情的にSTLを許容するまで2年くらい費やしました。
STLはコンパイラが対応していないケースもあると言い訳して
（実際に当時はgcc-2.7系とかSTLに対応していない処理系が使われていて、
　組み込みも考慮するならテンプレート自体を避けるのが普通でした）
自前実装に走ったりしたりしたものです。
だからSTLが気持ち悪いので自前実装しようという気持ちはよく分かりますし、
STLを毛嫌いする人にごり押しする気にもなりません。

私が試行錯誤する羽目になったのは、
当時の私が引き篭もりのような生活で回りに相談できる人もなく、
何でもかんでも一人でやるしかないような状況だったからです。
ネットなどを見てもεπιστημη氏のように先進的な人以外は
STLに否定的な人が大半だったような印象を受けました。

> その当時は帰納的な考え方はありましたが、
> それを実践する基礎力がなかったということだったと自分では分析しています。
前述のような私も人のことは言えないわけですが、
私の状況と決定的に違うのは
・相談する相手がいる
ということです。
だからこそ
・回避可能なので理由としては認められない
ということは非現実的だと片付けることではなくなります。

私は今まで1から10まで聞いて答えてくれる人に
プログラミングを教わった経験がありません。
教えてもらえば3分で分かるようなことに
何ヶ月も費やしたりということはザラでした。

たとえばQB→VBの飛躍（イベントドリブン）を理解するのには1ヶ月掛かりましたし、
CocoaでIBとPBを連携して組み立てる手法を理解するのには半年も掛かりました。
その間、意味が分からないままひたすら試行錯誤して、
偶然突破口を発見するまでは挫折して不貞寝するということを繰り返しました。
ドルアーガの塔を攻略本なしにプレイするのに似ています。（この例で分かるかな？）
こういうときほど自分の無能さに絶望するときはありません。

このようにブラックボックスとして使うことすら出来ないという状態は
身をもって経験しているのでよく分かります。

しかしそれは使い方を自力で把握する能力がなかっただけで、
使う能力がなかったというわけではないと考えています。
ブラックボックスでの使い方すら自分で考えないといけない状況と、
使い方を教えてもらう状況では天と地ほどの差があります。
理解するかどうかはともかく、使うだけであれば、
教われば3分で済んだだろうと後で感じるのはそういうことです。

ここまで書けばお分かりでしょうか。
自分の問題であるとした時点で他人の存在は関係なくなりますが、
他人（今回は私）の存在がなければ今回のような軋轢は生じません。
それに敢えて向き合うということは、
他人の存在に向き合うということに他ならないのです。
スレで外部の問題だというご指摘がありましたがその通りだと思います。
ひげぽんさんが私を拒絶するというのも一つの解決法です。

どのような結論になるにせよ、ここを解決しないと、
同じことを繰り返す（意図が不明→放置）ことになります。

その他のことはまた後ほど。

>>162
いえ、こちらも帰省中であちこち行ったりしていて、
パソコンを触ることができないような状態でした。
時間があるときに部分的に書いたものを書き込んだので
変則的な返答の仕方になってすみません。

そんなに謝って頂いて恐縮です。
私との交渉にそこまでの労力を割いて頂くのが申し訳ないです。

>>165
> こういう姿勢は維持したいですね。
あくまでこれは私の独断と偏見なのですが、
車輪を再発明するにしても、原理をより明らかな形で再整理するなど、
付加価値を高めるような方向であれば充分意味があると考えています。

その意味で川合さんの出版は大きな一歩ではないかと考えています。
Mona本出版のときもそのような方向性を求める声が大きかったと感じました。
例：Monaの使い方よりもOSの作り方を知りたかった、等

もっともその方向性で川合さんに張り合っても仕方ないと思うので、
MonaはMonaのやり方があるでしょう。
というかMonaは初心者の教材に適しているとは思えません。
ある程度分かっている人がおもちゃとして弄るのには適していると思いますが。

前にも書きましたが、普通のCygwinだけでmakeできるということが、
OS開発の手法として私には非常に衝撃的で目新しいことでした。
OS開発は特殊なツールで閉じたようなイメージを持っていたのですが、
普段のアプリを開発するのと同一線上で開発されていたからです。
これは非常に分かりやすくて画期的なことだと思います。

また、敢えてC++で記述するという試みも興味深かったです。
RTTIなどランタイム依存部分の制限はありますが、
それでもSTLまで動いてしまったことは驚きでした。
こんな普通のアプリっぽく記述されたカーネルは見たことがなかったので、
（独特のルールに従ってC言語で記述されるイメージを持っていた）
これまた画期的なことだと思いました。

ともかくこの2つは、当時の私にとっては、
画期的な新しい技術のように見えたのです。

旧態依然としたMLを廃してWikiを取り入れたというのも新鮮でした。
ともかく初めてMonaに触れたときの印象は、
新しい技術をどんどん取り入れるという技術革新そのものでした。

ですが、ひげぽんさんが私に対して期待しておられたという
C/C++やMakefileの面での洗練は一定の意味はありますが、
これは新しい分野を開拓するのではなく
既存の物を整備するという保守のようなイメージがあります。
もちろんそれは必要なことではありますが、
そこで止まると技術革新も止まるのではないかという危惧があります。
C++のユーザーランドの上でAPIや個々のアプリに独自性を出しても、
それに使っている技術（C++）は従来の技術の枠を出ないわけで、
いくら工夫して頑張っても仏陀の掌の上の猿という印象は拭えません。

そのため私はC/C++で満足するのではなく、
C#やJavaを持ってくる方法を模索したのでした。
独自言語というのも面白いとは思いますが、
そういうのは現時点の最新の方法に追いついてから、
その手法を踏み台にやった方が良いと思っています。

まとまりがなくなりましたが、C言語がUNIXとともに産み出されたように、
Monaとともに新しい開発手法が産み出されるのではないかという
ある種の過剰な期待が私をMonaの世界に呼び寄せたわけです。

その根拠は、前にも述べましたが、
何らかの言語またはそれに類する体系を作ったとして、
それによってOSを作ることができることを示すことで、
その手法の汎用性を証明できるのではないかということです。
そういう夢を見させてくれる魅力がMonaにはあったということです。

具体的にそれが何かは分かりませんが、
私の予想では視覚化に鍵があるのではないかと考えています。
その一環として、工程管理についても、
箇条書きよりも図示が望ましいと考えて、
PERT図について提案させていただきました。
もちろんそれだけではありませんがそれは後述します。

ともかく私がMonaに対して抱いているイメージは「技術革新」です。
既存の技術は使う対象というより克服する対象だと見ています。
Monaはもっと壊してもっとぐちゃぐちゃな状態であれば面白いです。
新技術の実験場のようなものになれば良いという考えです。

しかし、枯れた技術を安定して運用する段階であるということであれば、
このような私の一方的な思い入れは排除すべきものです。
もしそのような段階に移行したと認識されておられるのであれば、
私が申し上げたことの大半は何の役にも立たない妄想です。

もっとも枯れた状態として整備するのであっても、
それはそれでかなりの大作業になるでしょう。
書きっぱなしで放置された残骸があまりにも多過ぎるのに、
新技術だとか技術革新だとかに浮かれるのは砂上の楼閣で、
今までのものを集大成するという作業が
未来に舵を切るのに必要な土台固めだという見方もできます。
私が想定しているPERT図の件はどちらかというとこの種の作業です。

いずれにしても、Monaの方向性について同意が得られれば、
それに沿って作業をお手伝いしても構わないと考えています。
技術革新とか妄想は棚に上げると、
今必要なのは真の意味での全部入りでしょうか。

そういったものを同意もなしに私が勝手に作ることは可能ですが、
それは一種のフォークであり望ましいことではないと考えています。
ディストリビューションは誰か奇特な人が勝手にまとめてください、というのは、
それによって実益がない現状ではちょっとどうかと思います。

これは開発の能率化とかそういうことよりも、
今までのMonaの軌跡を整理することに主眼があります。
それと平行してPERT図を描いていけば、
ガントチャートとして時系列を示すこともできます。

>>165
> PERT図を描いてみようと思います。
ご決断感謝いたします。

> タブレットで描いて私がどこかにアップロードするのはどうでしょうか？
それだとあまり便利だとは感じられないと思います。

PERT図を描いても、項目が100を超えて枝に分かれまくった規模にならないと、
箇条書きよりも画期的に便利だとは感じないと思います。

また、PERT図そのものよりも、工程やクリティカルパスを自動的に計算したり、
ガントチャートに変換したりすることに利便性があるわけなので、
単に絵としてPERT図を描いても威力は半減してしまいます。

それとPERT図には循環参照してはいけないなどのルールがあるのですが、
これはソフトが自動的に指摘してくれないとどうしても見落としてしまいます。
直感的にパスをつないでいくと無意識に循環参照になりがちです。
人に教えているときに「何でエラーになるんだ！」とよく言われました。

>>165
> ただためすだけでMS Projectを寄贈していただくのはありえないので、
実はこれ、結構深刻な問題だったりします。
ひげぽんさん一人を相手にしているなら出せない金額ではありませんが、
図をみんなで保守することができなくなってしまいます。
かと言ってWeb版を購入してもWindowsサーバーが必要ですし、
CAL制限もありますし、値段も酔狂で出せるレベルではありません。

実業務の大規模プロジェクトでもないので
すべての機能を必要としているわけでもありませんから、
必要な機能だけのアプリを作る方が現実的かもしれません。
車輪の再発明ではありますが……。

実のところ、Monaに限らずPERT図で管理すると便利な局面は多いのですが、
MS Projectは高価過ぎて個人に勧めるのは非現実的だと常々感じていました。
良い機会ですし簡易PERTツールを作っても良いかも、とも思います。
そうなると完成するまでは他のこと（全部入り等）は手が出せませんが、
何を優先するかは悩み所ですね。ご意見を伺いたいです。

長くなりましたがこれで終わりです。

>>165
> またMona全体の履歴をPERT図にする場合の履歴とはどれくらいの粒度をイメージされていますでしょうか。
粒度は最近のWikiでひげぽんさんが箇条書きにされているのと同等のイメージですが、
Mona全体の履歴を追って、置き去りにした部分などを明確にするためには、
項目数は1000を下らない規模になると予想されます。
全部やるのは大変なのでもちろん私も協力したいと思います。

一度書いてしまえばそこから履歴を箇条書きでExportするなどの工夫で
ChangeLogの更新や新規計画の立案にも使えるので、
図を保守させられるというよりも図をベースに動く形になるとイメージしています。

そこまでするならやっぱりプロプラのMS Projectよりも
フリーで独自に用意した方がいいかもしれませんね。
こう考えると、途方もない話になって来ますが、
それが技術革新に繋がるのであれば私にとって悪い話ではありません。

ブラックボックス化の議論ですが

私の主張は
-ブラックボックス化することが理解を助けるという点には同意する
-ブラックボックス化による理解には基礎力が必要であると思う
-当時は自分に基礎力がなかったので問題が起こったのではないか
の3つです。

それに対して井上さんの主張は
1.基礎力がないとブラックボックスとしてすら使えない状況は過去の経験上理解できる
2.ただひげぽんの一件は、基礎力もある程度持っていたし、「ひげぽんが一人ではない」という理由から基礎力がなくても理解が可能な状況は作れるはずだった
3.自分の問題と捉えず他人と向き合うのはどうか？それが助けになるのではないか

というものだと理解しました。

1.に関しては井上さんがそのような理解があることが分かり議論が進めやすくなりました。

2.に関しては、その通りだと思います。
他人(井上さん)に教えてもらうことで気持ち悪さや、裏で何が起きているか等の片鱗を知ることが出来たかもしれません。
質問が2つあります。
(1)当時どの程度のレベルまで井上さんに頼って聞いても良かったのでしょうか？例えば、ひげぽんが死ぬ程調べても分からないレベルまで到達してから質問すべきなのかどうかとか。

(2)井上さんの助けを借りてブラックボックス理解をしようとする場合にどの程度の期間で理解できるものであれば取り組むべきだと思いますか。（重要なのは期間ではなくて必要かどうかという気もしますけど）

> 前にも書きましたが、普通のCygwinだけでmakeできるということが、
略
> また、敢えてC++で記述するという試みも興味深かったです。
略
> ともかくこの2つは、当時の私にとっては、
> 画期的な新しい技術のように見えたのです。
> 旧態依然としたMLを廃してWikiを取り入れたというのも新鮮でした。
略
> 新しい技術をどんどん取り入れるという技術革新そのものでした。
略
> C/C++やMakefileの面での洗練は一定の意味はありますが、
> 既存の物を整備するという保守のようなイメージがあります。
> そこで止まると技術革新も止まるのではないかという危惧があります。
もちろんそこで止まる必要はありませんのでご安心ください。
> そのため私はC/C++で満足するのではなく、
> C#やJavaを持ってくる方法を模索したのでした。
> 独自言語というのも面白いとは思いますが、
> そういうのは現時点の最新の方法に追いついてから、
> その手法を踏み台にやった方が良いと思っています。
このあたりは賛成出来る部分も多いです。
最近はScheme/Haskellなど関数型言語の良さが再発見されています。
いまはRubyのRailsなどがウェブアプリケーションフレームワークとしてもてはやされていますが
現時点でもJavaScriptを関数型言語っぽく使うなど関数型言語の波はきていると感じます。
数年後のウェブアプケーションフレームワークは関数型言語を使ったものになるだろうという見解もあるくらいです。
その意味でSchemeインタプリタを実装してMonaのシェルに組み込んでMSHとするというのも面白いのではないかと妄想しています。
もちろんカーネルもインタプリタも自前なので、シェルからシステムコールを呼べるようにしてSchemeから全てをコントロール出来るようにすることもできるでしょう。
またOS内のあらゆるデータをS式で扱うというのも面白いかもしれません。
Java/C#/Ruby/Haskellの何が次に来るかは分かりませんがそのあたりの技術にチャレンジすることに意味はあると思います。

> しかし、枯れた技術を安定して運用する段階であるということであれば、
> このような私の一方的な思い入れは排除すべきものです。
> もしそのような段階に移行したと認識されておられるのであれば、
> 私が申し上げたことの大半は何の役にも立たない妄想です。

いまはまだまだ攻めのときです。

> いずれにしても、Monaの方向性について同意が得られれば、
> それに沿って作業をお手伝いしても構わないと考えています。
> 技術革新とか妄想は棚に上げると、
> 今必要なのは真の意味での全部入りでしょうか。

ありがたい申し出ですね。ありがとうございます。
ちょっと時間がなくなってきたのでいろいろスキップします。

全部入り→基本的に賛成です。参加します。
PERT図→タブレットが無理なのは理解できました。ツールを作っていただけるのであればとても助かります。（工数にもよると思いますが）
優先順位→話の流れ的にまずはPERT図による整理が必要っぽいので、PERT図＞全部入りではないでしょうか。

完全に蛇足ですがPERT図ツールはC#で書かれるつもりでしょうか。
Ubuntuでも動くといろいろうれしいなあ。というのは冗談です（多分)。

>>179
> (1)当時どの程度のレベルまで井上さんに頼って聞いても良かったのでしょうか？
> 例えば、ひげぽんが死ぬ程調べても分からないレベルまで到達してから質問すべきなのかどうかとか。
調べずに教えて君でも気にしなかったと思います。

> (2)井上さんの助けを借りてブラックボックス理解をしようとする場合に
> どの程度の期間で理解できるものであれば取り組むべきだと思いますか。
時間というか、とにかく使わないと意味がないので、
それを今やっている何かに応用しながら、
使わないときに比べて何が利点か考える（帰納的推測）ようなイメージです。
それが完全に無駄になって外してしまうかもしれませんが、
そういう試行錯誤の経験も無駄にはならないと思います。

このように知識を単体で切り離さないので時間と言われると難しいですが、
外部から何も影響がなかった時間の一割〜二割増しくらいでしょうか。

> （重要なのは期間ではなくて必要かどうかという気もしますけど）
前述のように需要は作り出すものだと考えています。
言い換えると外からの影響で軌道修正を試みるということですが、
そのようなことは生理的に受け付けないということであれば、
無理な干渉は諦めます。
一応、私は時期を見てそのときに応用できそうなことを突付いているつもりです。

>>180
その辺の構想はどこかにまとめておられますでしょうか？
それともまだ胸の中で育てておられる段階でしょうか？

お時間がないとのことなので、
具体的な話（感じたことなど）は控えます。

>>181
それではPERTツールを作ることにします。
Monaと直接関係ないので私が勝手に進めます。
基本的に開発過程は要旨を常にアップする方法でやりますが、
ユーザーの視点で開発を追い掛けて頂けると
（開発者として参加してくださいということではありません）
使い方やPERT図の概念を説明する手間が省けて良いと思います。
その際に疑問点などあればどんどん突付いてください。

>>182
普通だったら、それを言ったらおしまいで、
ブチ切れて今までの話は全部なしにするところなのですが、
今朝は特別にすっっっっごーーーく嬉しいことがあったので、
例外的にLinuxでの動作を考慮してC++で作ります。

本当に、本当に、例外中の例外なので、
○子さんに感謝してくださいねっ！

>>183で書いたようなイメージはこういうことです。

「北斗神拳は戦場の拳！千変万化する闘い中にこそ、その奥義を見出した」

Wikiを設置しました。
PERTに関するやり取りは以後こちらに移行します。
ttp://wikki.sakura.ne.jp/pert/

簡単なPERT図でいいなら、以下のようなガントチャート作成ツールもあります。
http://ganttproject.sourceforge.net/
オープンソースで、フリーです。

>>188
ありがとうございます。
試してみましたがコンパクトで良く出来ていますね。
Swingでももう違和感がないレベルに達しているんですね。
ガントチャートがメインでPERT図だけでの作画が出来ませんが、
PERT図への変な拘りを捨てれば実用的にはそれで充分ですね。

ちょっと心が揺れますが、とりあえず自分でどこまで出来るかやってみて、
挫折したら使わせていただくかもしれません。

> > 例えば、ひげぽんが死ぬ程調べても分からないレベルまで到達してから質問すべきなのかどうかとか。
> 調べずに教えて君でも気にしなかったと思います。

なるほど。これは結構認識に違いがありました。
かなり調べてからでないと聞くのは申し訳ないと思っていました。

> > (2)井上さんの助けを借りてブラックボックス理解をしようとする場合に
> > どの程度の期間で理解できるものであれば取り組むべきだと思いますか。
> 時間というか、とにかく使わないと意味がないので、
> それを今やっている何かに応用しながら、
> 使わないときに比べて何が利点か考える（帰納的推測）ようなイメージです。
> それが完全に無駄になって外してしまうかもしれませんが、
> そういう試行錯誤の経験も無駄にはならないと思います。

なるほど。理解できました。

> このように知識を単体で切り離さないので時間と言われると難しいですが、
> 外部から何も影響がなかった時間の一割〜二割増しくらいでしょうか。

具体的な数字をありがとうございます。
その程度なら余裕で許容範囲内なので、このあたりの意識をあわせられたのは大きいと思います。
例えば5割増しなってしまうのであれば、私が井上さんにアラートをあげれば良いという感じでしょうか。

> 言い換えると外からの影響で軌道修正を試みるということですが、
> そのようなことは生理的に受け付けないということであれば、
> 無理な干渉は諦めます。
> 一応、私は時期を見てそのときに応用できそうなことを突付いているつもりです。

外部干渉は前述の通り、一割〜二割増の時間であれば有益なことの方が多いと思うので積極的に受け付けたいと考えています。

> その辺の構想はどこかにまとめておられますでしょうか？
> それともまだ胸の中で育てておられる段階でしょうか？

多分どこにも書いていないと思います。
基本的には、もうすこしSchemeインタプリタをいじってから計画を建てるつもりでした。
いまは実現可能性を探っています。
今回は議論の流れ上、書いた方が良さそうだったので書きました。

> 基本的に開発過程は要旨を常にアップする方法でやりますが、
> ユーザーの視点で開発を追い掛けて頂けると
> （開発者として参加してくださいということではありません）
> 使い方やPERT図の概念を説明する手間が省けて良いと思います。
> その際に疑問点などあればどんどん突付いてください。

ありがとうございます。了解しました。

> ○子さんに感謝してくださいねっ！

○子さん。ありがとうございます！

> 「北斗神拳は戦場の拳！千変万化する闘い中にこそ、その奥義を見出した」

大体分かったような気がします。

> Wikiを設置しました。
> PERTに関するやり取りは以後こちらに移行します。
> ttp://wikki.sakura.ne.jp/pert/

早速ありがとうございます。
後ほどコメントさせていただきます。

起動直後のGUI選択画面をなくし、いきなりデスクトップに移行する

って機能の実装予定はあるんですか？？

http://www.monaos.org/
このサイトほど、人が閲覧することを度返しにした
サイトはないモナー

御指摘ありがとうございます。
確かにそろそろリニューアルの時期かも知れませんね。
オープンソースのプロジェクトのトップページはある程度の共通したページレイアウトになっている事が多くて、それにあわせた方が良いかもと思っています。
例えば http://www.ruby-lang.org/en/ とか。
いまはfile_server＆PERT図あたりに集中したいのでどうしても優先度は低めになってしまうのが難点です。

ひげぽんさんも、そう考えているんですね。。

サイト自体がユーザーサイドと開発者サイドに別れている点は、
いいと思います。
開発者のページ構成＆モジュール構成の表現がツリーになっていると
スポット的に参加しやすいかなと。。
あと、各モジュールと、それに対するアップデートが判る形に
なっていると、よいかなと。。。

リニューアルしました。
http://www.monaos.org


しばらく様子を見つつ手直しをしていく予定です。

>>196　デザインはいいと思います
しかし、入った瞬間どこの国のHP？？
って思ってしまいました；
このくらいでｓ

>196
betaでなくてalphaだろ!!

>>196
betaのメニューですが、
「Wiki」はProjectPageの一部って気がしました。。
「Project Wiki」ってのはどうですか。

>>197
ありがとうございます。
落ち着いたら日本語バージョンも作ります。

>>198
あのロゴは半分ネタなのでBetaレベルを目指しますということでひとつご勘弁を。

>>199
その方が分かりやすいと思うのですが、メニューが横にひろがってしまいちょっと美しくないんですよね。
迷っています。

何も分からん俺にできることは応援だけだ、ガムバレ

あれ？荒れてる？
俺もOS作ってみようかな

OS板は自作自演の遊び場だし、
こっちは別にほとんど誰も居ない。

OSを作るってどのくらい知識があるん？
道のりは長いぜ。
OS自作入門でも買ってみたら？まぁ無くても作れるけど

OSが作りたいんです!!
http://pc8.2ch.net/test/read.cgi/os/1159072674/
WarOSってOSつくろうぜｗｗｗｗｗｗｗｗｗｗｗｗｗ
http://pc8.2ch.net/test/read.cgi/os/1158766636/
OSを作ろうpart12
http://pc8.2ch.net/test/read.cgi/os/1153133384/

【公開ハックのお知らせ】

この度、以下の日程で公開ハックを開催する運びとなりました。
時間中の出入りは自由で、事前登録や参加費は不要です。
ご都合の良い時間にお立ち寄り頂ければ幸いです。

日時：10月15日(日) 10:00〜18:00
場所：株式会社びぎねっと会議室（最寄駅：渋谷）
※場所は以下の地図をご覧ください。
http://begi.net/modules/xfsection/article.php?articleid=1

BayGCを1日で作り上げることを目標にTinoとbaysideが開発に励みます。
その状況をウォッチしたり突込みを入れたりと、
自由な雰囲気で進めることを目標に、
実験的に「公開」というスタイルを採用いたしました。

お越しいただいた方のご要望には可能な限りお答えしますので、
お気軽にお声をお掛けください。

【例】
・Monaでのプログラミングを体験（Tino持参マシンにて）
・Monaの開発環境構築サービス（希望者はノートパソコン持参）
・合宿気分で一緒に開発（Monaと無関係でも可）

開発終了後には懇親会を予定していますが、
どのような人数等になるのか予測が付かないため、
その場の状況に応じてケースバイケースで決めさせて頂きます。

会場をご提供いただいたびぎねっとさんには、
この場を借りて改めて御礼申し上げます。

本日、Mona OSプロジェクトは Mona 0.3.0alpha8 をリリースしました。
大きな変更点は以下の通りです。

・ネットワーク対応の一環として簡易ブラウザが追加されました
・VFSに対応したファイルサーバの完全書き換えをしました
・ソースツリーがSubversionに移行しました
・LinuxでのMona OSのビルドが可能になりました
・libcの更なる整備が行われました
・APMによる電源管理のサポートが開始されました
・起動時にGUIを選択できるようになりました

ダウンロードはこちらから
http://sourceforge.net/project/showfiles.php?group_id=164970&package_id=205274

mona-0.3.0alpha8-fd-bootable.zip
Mona のブート可能な FD イメージです。

mona-0.3.0alpha8-iso-bootable.zip
Mona のブート可能な ISO イメージです。

mona-0.3.0alpha8-qemu-0.8.2-tap-windows.zip
Mona の CDブート を qemu で簡単に実行できるパックです。
TAP 対応版ですので設定をすればネットワーク機能も使用可能です。

mona-0.3.0alpha8.tar.gz
trunk/mona と trunk/contrib が収録されています。

変更の詳細は以下の通りです。
(1)APM による電源管理のサポート
主担当:Yume
CUI シェルで "shutdown -h" または "halt" とタイプすると電源が切れます。
CUI シェルで "shutdown -r" または "reboot" とタイプするとリセットします。

(2)VFSに対応したファイルサーバの完全書き換え
主担当:ひげぽん
VFS/Vnodeに対応したフレームワークを導入しました。
現時点でFAT12/ISO9660に対応しています。
CDブート時にFDにアクセスも可能になっています。
正式にファイル書き込みを完全サポート開始しました

(3)libcの整備
主担当:shadow/Yume
Yumeさんのnidalibcが取り込まれました。
多くの関数が追加されています。

(4)ネットワーク関連
主担当:ひげぽん
新バージョンのQemu-0.8.0に対応しました
簡易ブラウザ giko が追加されました

(5)アプリケーションの追加
GUI版 MPEG プレーヤ by bayside
テトリス by sou
ENTER でスタートです。
z で左回転です。
x で右回転です。
↓ で高速落下です。
→で右にブロックを移動します。
←で左にブロックを移動します。
エディタ(gnote) by hetappi

(6)GUI セレクタ
主担当:bayside
起動時に GUI セレクタが起動するようになりました。
左を選択すると CUI シェルが起動します。
真中を選択すると BayGUI が起動します。
右を選択すると MonaForms が起動します。

(7)カーネルの細かい改善
主担当:ひげぽん
500KBを上限に任意のサイズの DMA バッファを取得できるようになりました。
Vmwareでの表示速度改善を行いました。
メッセージAPIで利用するヘッダ用の補助ツールを追加しました。
PCI デバイスの割り込み処理が改善されました。

(8)Linuxでのビルドが可能に
主担当:hiratch/shadow
mingw32クロスコンパイラを利用することでLinuxでのMona OSのビルドが可能になりました。
Mac OSXでのビルドも確認されています。
configureスクリプトなどビルドプロセスにおいて多くの改善が行われました。
いままでどおり cygwin でもコンパイル可能です。

(9)Subversionへの移行
主担当:ひげぽん
ソースツリーをSubversionで管理するようになりました。
これに伴い sourceforge.jp から sourceforge.netに完全移行しました。
http://sourceforge.net/projects/monaos
trunk/mona と trunk/contrib がHEADのソースコードとなります。

なお上記の主担当以外にも以下の強力なメンバ（敬称略）のアドバイスによってMona OSプロジェクトは支えられています。
.mjt/EDS1275/Gaku/Yamami/Yas/junjunn/nikq/名無し/350N

またMona OSプロジェクト外部の数多くの方々にアドバイスをいただきました。
この場を借りてお礼を申し上げます。

乙

トラックバック:http://pc8.2ch.net/test/read.cgi/os/1160883506/

公開ハック題１回は滞りなく無事終了いたしました。
一般の方を含め、多数のご参加ありがとうございました。
また、関係者の皆様お疲れ様でした！！！

おっ、結構進んでるんだな。お疲れ様でした。

期待age

オープンソースカンファレンス２００６秋が無事終了しました。
非常に多くの方がいらしてくれました。
MonaOSを知っている方も増えてきているようで、
次第に認知度があがっているのを実感できます。
「継続は力なり」という言葉を再確認しました。
これからも着々と進歩を重ねて行きたいと思いますので、
みなさんどうぞよろしくお願いします。

つか、どこ行こうとしてるの？

つ ttp://wiki.monaos.org/index.php?%B5%C4%CF%C0%2F%BC%C2%CD%D1%B2%BD%A4%CB%C9%AC%CD%D7%A4%CA%BB%F6

monaでplaggerってできますか？

monaOSをARMとかのマイコンにポーティングしようというのはバカですか？
カーネルだけ

いや天才の類ですね。
出来たらうｐって下さいｗ

>>221さん
期待!

221です.
222さんひげぽんさんありがとうございます.

はあ.
wってくらいたいへんなことなんですね.
私は携帯の中の人ですが,やり遂げる自信はありません.
軽々しく言ってすみません.
携帯電話でmonaOSが動いたらどんなに楽しいだろうと思っただけなんです.

自分でみろと言われたらそれまでなんですが聞かせてください.
カーネルのどのくらいがCPU依存のコードですか?

お返事が遅れてすみません。（社員旅行にいっていました）

＞カーネルのどのくらいがCPU依存のコードですか?
思いつくのは
-ブート部分
-タスクスイッチ部分
-MMU(メモリ保護部分)
-割り込みハンドラ系

でしょうか。
量は算出が難しいですね。1-2割くらい?

回答ありがとうございました.
量を聞いてもあまり意味ないですね.変な質問でした.
ブートストラップもタスクスイッチもどれも
RTOSのそれのイメージしか持っていないのですがトライしたいと思いました.

そこで適当なターゲットボードを探してみたんですが
ホビーユースにほいほいと買えるようなMMUありCPUのものは
見つからなかったので残念です.

今のところこれが第一候補ですが,4万円もするので悩んでいます.
http://armadillo.atmark-techno.com/armadillo

ARMといえばゲームボーイアドバンスですよ！！
Kタンも最注目のハードみたいですよ。

CPU依存の部分はそれほど多くないけど、
ほとんどC++で書かれているから、そのための互換性で苦労しそう。

これが参考になるかな。
http://prex.sourceforge.net/screen.html

>>228
たしかにC++の互換性ではまったら苦労しますね.
コンパイラはgccを使うことになると思います.
カーネルはプリミティブなC++で書かれているだろうと思って心配していないのですが..

>>229
情報ありがとうございます.参考になります.
組込みLinuxみたいな構成ですかね.

GBAで動いているのはMMU非対応のカーネルだと思いますが
GBAをターゲットにするとMMU非対応のためにカーネルに手を入れないといけないですよね.

突然ですがmonaにgccを載せる予定とかってあるんですか？

>>231
http://pc11.2ch.net/test/read.cgi/os/1172945029/で教えてもらい、質問いただいていることに気付きました。
お返事が遅くなって申し訳ありません。

将来的には載せたいですが、ここ半年以内の予定はありませんです。

MonaOSダウンロードしてみました。
電源切るときブチッて切っちゃってますが大丈夫ですか？

>>233さん
お返事遅くなり申し訳ありません。
CD-ROMやフロッピーが読み書き中でなければ電源ブチッでも良いと思います。
(mona-halt) とやってみていただくともっと安全かもしれません。

Monaのmath.hを自作のOSに使って見たものです。
バグを見付けたので報告します。
double atan2(double x, double y);は間違いだと思います。
正しくは、double atan2(double y, double x);です。
Monaのソースは修正BSDライセンスのようですが、使用する際に注意する点などありますか？

>>235
ええとそうですね。修正しますね

atan2を修正しました。

>>236
酉

ええっと…

まだ製作が行われていたのか。
よく続くよなあ。

続いても続いてもｒｙ

新しくos作ろうと思ったんでスレ作るかなと思ったけど２番煎じもやだな

誰か一緒にV6移植しようよ

あの。
誰かmonaのカーネル解析をまとめられた方かたはおらっしゃるのでしょうか？

いなければまとめて見ようと思うのですが。
余計なお世話でしょうか？

あの。
誰かmonaのカーネル解析をまとめられた方かたはおらっしゃるのでしょうか？

いなければまとめて見ようと思うのですが。
余計なお世話でしょうか？

うーん、あちこちで解析はなされているけど、
まとめ（？）みたいなのは作ってみるのもいいんじゃない？

＞＞２４６

分かりました。
どうもです。

そういやMonaってＣＰＵキャッシュ周りの制御って実装しているの？

このスレ過疎化してるな
開発は大丈夫なのか？
おい、ひげぽんどうしたんだ

ひげぽんは逃げ出しました

OS製作関係の日本語じゃなくて英語の書籍を参考したいのですが
何かいい本はないでせうか？

>>251
THE DESIGN OF THE UNIX OPERATING SYSTEM
Lions' Commentary on UNIX 6th Edition with Source Code
OPERATING SYSTEM DESIGN THE XINU APPROACH

開発してんのかな？

もし、monaosがC言語だったら開発に参加してました。

http://etc7.2ch.net/test/read.cgi/siberia/1214904062/