次世代BTRONをものすごい勢いで妄想するスレ
ヲチ板の”【コップの中の】TRON Fan Watch【あらし】”
http://kaba.2ch.net/test/read.cgi/net/1017059553/l50
スレで話題が技術的なものに流れた時の避難用スレとして立てますた。
BTRONの話題以外は極力禁止。
いわゆる初心者発言禁止。
話題に関する突っ込みは歓迎。
さあ使え。 漏れ的には BTRON よりも CHU-TRON のほうがいいな。
化身実身ってなんでOSレベルでサポートしてるんですか?
あんなもんアプリケーションレベルで十分だと思うんですが。 やっぱ、次世代BTRONは、実身数の撤廃とJPEG対応じゃないすか(w
>>2,>>4,>>6,>>7
とりあえずお前らは氏んどけ。
>>8
イキナリ核心に迫るんじゃない。
>>5
リング切れについて何も考えていない罠。
なんて詰まらんスレのスタート。と言ってもオレ自身ネタなんて無いしな。
寝るか。
と、その前にやっぱ言語マシソじゃないのとか書いてみるテスト。 >>8
それは一番難しい。
>リング切れについて何も考えていない罠。
超感じも中途半端で適当ですが、何か?
俺的にはTACLが一番欲しいというか、
これができるのはいつになるのだろうか?
ところで、画用紙のサイズ、ウインドウパーツ、キャビネット、マイクロカードその他
基本機能の限界は実身数と同じレベルの難易度なの?
実身数増加と同時にできる性質なのか詳細きぼーん。 >>10
1つのボリューム内でリンクを完結させている場合には特に問題は無かろう?
大体B-righit/Vのリリース当時の状況を思い出してみろ。他はどうだったよ。
確かに今となってはちっとばかしスケーラビリティーに欠けるがな。
って言うかだ。その中途半端で適当などというそれこそ中途半端な認識は、
どうせMのサイトの受け売りだろうがよ。
おのれMめえぇぇ。やはり奴は早いとこ…。 >>11
実身数増加は仕様の変更を伴うのでほかの問題にくらべて
解決がはるかに難しいと思われ。その他の基本機能の限界は
アプリケーションの実装方法からきているはずだから、
あとはPMC次第。でもかなりめんどくさいとおもふ。
TACL、俺もほしいなあ… アプリがみんなこれでかけたらいいよなあ。
っていうかしっかりとした開発環境がほしいぞ。言語マシンも可。
あとはBTRON2だったらいうことなし。 >>12
たしかに未来氏は技術的な面で頼りないけど、彼がいなくなったら
雑誌でBTRONの宣伝してくれる人がいなくなっちゃうよ、
といってみるテスト。 開発環境やライブラリを充実してくれ。
漏れはプロジェクトリーダーの言う職人ではないので。
>>13
ありがとう。
とりあえず、最大実身数だけを意識すればいいわけだね。
あとは、それが5なのか6なのか、PMC次第なわけか。
冷静に考えて、最大実身拡張の混乱のリスクを考えると
最悪、最大実身だけが増えて、なおかつアプリ等の混乱がある5に
ユーザはどれだけの魅力を感じて、その混乱を受け入れられるのか?
そこを考えないと5での採用は難しいのだろうね。
PMCが即答を避けるのは当然だろうね。
バグは残ってサポートは大変、ユーザは買わないなんて事になったら
最悪、PMCはあぼーんしかねない。
未来氏はそこまで考えて発言しているのか疑問なんだけど。
それを理解した上で、どうやって条件をそろえて
周囲を説得するかという視点が欲しかった気がする。
実身名の制限(最大20文字以下)を緩和するのは技術的に難しいのだろうか? 間違えた。
>>13
>アプリケーションの実装方法からきているはずだから、
は
>OSとアプリケーションの実装方法からきているはずだから、
と読みかえてくれ。
殴(や)れ! 刺(や)れ!
犯(や)れ! 殺(や)れ!
壊(や)っちまえ―――――――!!!
WIn? Mac? linux? unix?
そんなもの…クソ喰らえだ!
そんなものは見えやしね―――――――!!
「PSYCLOPS(サイクロプス)」の目にうつるものは
ただ一つ!!
|
--―――-- 、
/::::::::::::::::::::::::::::::::::::\
/:::::::::::::::::::::::::::::::::::::::::::::::\
|::::厂 ̄'''ー――一'' ̄ ̄|:::::|
|:::| |::::|
|:/ ____ /______ヽ:|
/^''Yニ -=ニ・ニ>卅彡ナナナ ニY''ヘ
| 久|ニ ー'´| `ー ニ|/ヘ| v V v V v V v V v V v
!.イ|ニ l| ニ|ヽ | > | _ / <
ヽ_|彡/ l|、_l 〕 ヽミ|_ノ > |ヽ |_| /| <
|`<// v======v ヽヾ>| < 二〃 フ <
|:::::`<// ヽ___/ ヾ>'::::| > ノ ー―― へ <
| :l:::::::`< `――‐'′>'::::|:: | > <
| l ::::::::::\__/::::::: l | ハ 八 ハ 八 ハ 八 ハ 八 ハ
/ l ::::::::::::::::::::::::::::::: l \ >>17
基本的には実身名の長さの制限は実身数の制限と同じくらい緩和が難しい。
いまあるBTRONのアプリケーションはすべて実身名が20文字以下である、
ということを前提として作られているので、もし実身名を長く出来るようにしたら
すべてのアプリケーションはつくりなおし、ということになる。
が、個人的には別の解決方法もあるように思う。実身名が長くなった場合には、
拡張した実身名を独立したレコードにTAD形式で格納するのだ。そうすれば
多少速度は犠牲になるかもしれないが、互換性を損なわずに無限に長い名前を
つけられて、表現力もあがると思うけどどうよ? >>20 昔のアプリケーションが20字までの実身名を見てなにかしている可能性 を考えると、VFATみたいな形にすることになるんでしょうか? 実身名で何かを記録すること自体が問題なのかも うだうだしゃべっている暇があったらフリーソフトのベータテスターを
やれ〜。ちんこついてるんだろ〜。 >>22
どのソフト?
某BBSに出せばみんなやってくれそうだけど。 >>23
某プリンタドライバ系のつもりだったのだが、よく考えたら
最近ソフトのリリースがとても多かったんだなぁ。
スタティックリンク版モジラ、手帳、タスクバー、プリンタ
ドライバ、それにベクターにもたくさん登録されているし。 >某プリンタドライバ系
あれはプリンターを持ってないので、俺は無理。
kさんがやってくれそうじゃないのかな?と頼ってみる。 人違いする人もいるかもしれないので断っておくが
おれ自身は作者でもないし、テストもしないよ(w つかの間の幻のプログラマでした。
ちゃん、ちゃん。 5はファイル構造の内部について真剣に考えたことないんでしょう。。
まぁ仕方ないよね。 >20
説明ありがd。
既存のファイルや実身とのコンバートに支障がなければ、
別レコードに格納するのが2Bっぽくてスマートかも。 とりあえず、ウィンドウの切り替えや、ダイアログボックスの
ボタン操作がマウス無しでもできる様になりますように。
ついでにトロンキーボードが再生産されます様に。 アプリケーションを終了させずにウインドウを小さくしたい。
Macintoshみたいなのでいいから実現してほしい。
窓開きすぎるとうざ過ぎます。 上位レイヤのTADを定義してくれ。
XMLへきれいに変換できるようなのを希望。 >30 ウィンドウの切り替え ctrl+wじゃダメ? ダイアログの[[取り消し][廃棄して終了][更新して終了]]って
カンジのやつを鍵盤から選択したいぞなもし。 そういや、某お絵かきソフトで、描画可能領域が基本図形エディタより
拡張されてた気がするなぁ。 >>31
最近出たタスクバーは最小化が実装されています。
初期ウインドウさえできるよ。 >>21
>VFATみたいな形にすることになるんでしょうか?
そういうのが一番混乱が少なくていいと思う。
>実身名で何かを記録すること自体が問題なのかも*
実身名もデータの一部だから、問題が起こること自体
おかしいんだけどねえ。
実身名の制限は個人的には実身数の制限よりはるかに深刻なので、
現在TAD補助レコードを表示・編集できるような仮身一覧を構想中。
期待しる。 妄想にエネルギーを使っているうちは、次世代BTRONなんて出ない罠 >>39
正論なんだけど。
BTRONは妄想エネルギーによって支持されています罠
って事で少々大目に見てくなさい。 換気ファンがなくて、まず壊れる可能性のない安価な家庭用サーバー希望
T-ENGINEに,GNU/LINUX,GNU/HURD,GNU/CTRON,を載せることは現実的に可能ですか?
と問うて妄想に入る >>1
全然ものすごい勢いじゃないと思うのは
漏れだけですか? >>42よ>1の本文をよく読みたまえ。確信犯でこのスレタイは
「看板に偽りあり」「羊頭を掲げて狗肉を売る」
なのだよ。
さて、
http://kaba.2ch.net/test/read.cgi/net/1017059553/259
なんだが、アプリIDに制限なんてあったっけ?
実は目の前にプロハンが転がっているのだが、探すのめんどくせー、
眠いー。なので、後は任せた。>憶えてる頭のいい人
まぁ気になったんで明日調べるけどね。誰も書いてなかったら書くよ。 アプリケーションIDはすでに予約で一杯です。 という冗談はさておき、アプリケーションIDをいちいち申請 しなくちゃいけない手間が、超漢字フリーソフトの普及を 妨げてるのではないか&T00007D;&T000091;} C/C++でのフリーソフト作成の障害になっているのを、思いつくまま
挙げてみると、
1. BTRON(超漢字)のプログラミング自体が難度が高い。
2. プログラミングの情報が少ない。
3. 開発環境が古典的で、馴染のない人には難しい。
4. 入門のサポートをしてくれる場所がない(なくなった)。
5. ドキュメントを代筆してくれる人も少ない(いることはいる)。
6. プロトタイプ段階のソフトをテストできる人が極めて少ない。
7. ID申請がうざい。
ところで、マイクロスクリプトアプリケーションの場合は
IDってどうなっているのかな?
※マイクロスクリプトとは、超漢字、1B、TiPOでシームレス
に動作することも可能なアプリケーションを作ることもでき
るスクリプト言語です。少し前に流行っていたTcl/Tkにポジ
ションは似ています。