Linuxは、開発環境が40年前と同レベル
numberと書けばスライダーが出てくるなんて言ってないぞ?
話を整理しようか?
1. type="int" という型情報じゃスライダーと数値用テキストボックスの
どちらを出せばいいかわからない
このことから型情報ではダメであると理解できたはずだ。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
で、numberと書けばスライダーが出てくるかどうかだったな
HTMLを参考にしてると言っただろう?
http://www.htmq.com/html5/input.shtml
2. type="number" だと数値用のテキストボックス(相当のもの)
type="range" だとスライダー(相当のもの)が表示される
typeに書いているのは変数の型ではないことが理解できたかな? >>579
例えばnumberで出てくる数値入力ボックスは
要求が整数か浮動小数点か区別できるの? >>580
まずさ、君が理解しないといけないことは
XMLではない設定ファイルにデータの型情報を
書いてるものなんか無いって事実だよ。
そう。いらない。整数化浮動小数点数か区別する必要がない。
inifileに
[VM]
MemoryGB=1
とかあった時、MemoryGBが整数か浮動小数点数か区別できるの?
区別できないし区別する必要がないよね。
数値どころか文字だって書くことができる >>581
テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの? 彼の目的は >>220 に書かれている。すべて、そのための妄想だ。
妄想だということを本人も >>180 で認めている。
まあ、それが彼のやりたいことだというなら仕方ないじゃないか。 >>582
> テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの?
はい。情報が型しかないとそうなりますよね。
だから型の情報はいらなくて、
「何を入れるか分かる情報」が必要なんですよ >>576
アプリの作者からしたら
スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない
ツール作者やその利用者が好きにしたらいいだけ
>inputはユーザーが入力する項目を示します。
>type属性は入力する値の種類を意味します。
>設置ツールは適切なインターフェースを使用してください
という軟着陸なアイデアは無意味なので無視するとして
アプリ作者の独断で
エディット、スピン、スライダー、ダイヤル…
数有るコントロールの種別の中から一つを決めたとしても
そのチョイスを万人が受け入れるはずがないし
そのチョイス自体負担だし選び直しでリビルドとかやってられない
それなら
int型です、UIはご自由に
と投げたほうがいい
そもそも
int型です
という情報すらも必要ない
それが必要だという人が勝手に調べりゃいいだけ >>585
型情報とは違う「何を入れるかわかる情報」の具体例は何? >>587
> アプリの作者からしたら
> スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない
> ツール作者やその利用者が好きにしたらいいだけ
そう。だから利用者が好きにできるように
汎用のXML設定ファイルがある。
設定ファイルの情報をもとに設定画面を組み立てるから、
設定ファイルを書き換えて使いやすい設定画面を作ることができる
まさに、ツール作者やその利用者が好きにできるということを実現している
アプリの作者からしたら、どのインターフェースでも設定された値を取得できる。
ツール作者やその利用者が好きに使いやすいインターフェースを作ることができる >>588
数値だったら、その範囲等。0〜100とか
文字列だったら、その文字列長さや、正規表現パターンなど
選択項目だったら、設定可能な値、例えばredやblueといった色の名前など ある設定項目αについ設定ツールAが1から100のスライダーで表示したとき
設定ツールBでも同様に1から100のスライダーが出てくると
ユーザは期待して良いのか(y/n)? >>591
NO。ただしどのツールでも設定できる
[VM]
MemoryGB=1
結局の所↑の1の部分を入力するだけだから
スライダーが出てこないでテキストボックスがでてきても
なんてことはない。普通に入力して設定できる。 では設定項目αは整数値で1-100と設定した場合
設定ツールから1000と入力しようとしたら何らかのエラーが
ユーザに通知されるものと期待して良い(yn) >>593
聞いてばかりいないで、少しは自分で考えてみたら?
まずXMLではないよくあるテキストファイルの
設定ファイルのことを考えてみようか?
不正な値も含めどんな値でも書くことができる
その不正な値が書かれた設定ファイルをアプリケーションが
読み込めば普通はエラーを出すだろう。
いいか、汎用のXML設定ファイルの話はまだしてないぞ。
信頼できるチェックはアプリケーション側で行われているこれは大前提である
で、ここからが汎用のXML設定ファイルの話
設定ファイルに書かれた範囲などは、使いやすくするためのガイドに過ぎない
どうせXMLファイルをテキストエディタで開いて書き換えれば好きな値にできる。
不正に値にされた所で、大前提である信頼できるチェックはアプリケーション側で行われてるから問題ない
で、何らかのエラーが出るかって? 設定ツールの実装次第
まあ普通はエラーを通知するようにするだろうね
実際HTML5もそうなってる。対応してるブラウザであればエラーを通知するが
対応してないブラウザではエラーを通知しないし、スライダーの指定をしても
対応してなくてテキストボックスが表示される。でも信頼できるチェックは
サーバー側で行われてるから問題ない
もうね。ここらへんHTMLの世界ですでに通った道なの。
一旦HTML5を勉強したほうが良いよ?
基本的な質問をしてるってことがわかってない。 要するに設定項目の値の範囲の制限などを指定したとしても
設定ツールによる入力の挙動は実装依存だと。
さて「何を入れるかわかる情報」とし0〜100の数値を挙げているが
このようなものはどれだけ記述できるのか?
事前に何があると知らない限り設定XML記述者も設定ツール作成者も困るだろう。
・0から100の整数
・0から1の浮動小数点(閉区間もあれば半開区間もある)
・32ビット長ただし16進記法
・任意長整数
・素数
・42の倍数のみ
等々数値だけでもいくらでもやりたいことは考えられるがこれらは
何でも記述できるのか
数種だけ用意されててあとはあきらめろということなのか? >>594
HTMLのフォームの値チェックはサーバサイドがJavaScriptの話に
なってHTMLやXMLの範疇を超えてるがどういう話になるんだこれ もはや、汎用設定ツールでも何でも無くて、
汎用GUI作成ツールになりつつあるな。ブラウザより大きくなる。 >>595
だからHTML5を勉強しろって
>>596
フォームの値チェックなんか、
フォームコントロールの属性でできるだろ
HTML5の勉強しろって >>597
また何の根拠もなくブラウザより大きくなる(笑)か
何が大きくなるのー?w
ブラウザがどれだけ大きいかしらないのー?w >>598
HTML5で素数だけ入力可とかできるの? お前は設定ファイルで素数だけ設定したことあるのか?
そんなマイナーケースまで対応しようとか考えるから
仕様がぶくぶく太っていくんだぞw xmlはhtmlじゃないと言ったり、htmlを参考にしたり、なにがなんやら。
xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか 設定ツールのvalidationが実装依存は相当まずくね?
ツールで値を入力したときエラーがでなくても
値が妥当なのかエラー処理が手抜きなのかユーザーにはわからない
ことになるけどそれ何もチェックしないより悪いな 不正な値を設定したらアプリがエラーを出す、確かに正しいが
そんなぶっちゃけやるならリッチなUIとかもういらないだろ dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ
しかもなぜxmlじゃなくて独自のバイナリフォーマットなのかってのも、DEの起動時みたいに一遍に色んなアプリケーション起動して大量の設定をロードしてってなるとxmlのgconfだとパフォーマンス的に良くないってんでそうなってるわけだが
そういう現実的な部分をすっ飛ばして実際に作ってすらねぇ妄想でドヤってちゃ話になんねぇわ >>601
素数を設定するなんてかなりマイナーな話だと思うけど
マイナーだからと逃げたら汎用性の謳い文句がすたるぞ >>608
この設定XMLとツールで汎用とはどういう話? >>602
> xmlはhtmlじゃないと言ったり、
XMLはHTMLじゃない。当たり前
> htmlを参考にしたり、なにがなんやら。
著名な論文を参考にして、書いた自分のレポートは
著名な論文になるとでも思ってるのか?
> xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか
汎用のXML設定ファイルの話とは関係ない話ですね。 >>603
> 設定ツールのvalidationが実装依存は相当まずくね?
全然まずくない。何度も大前提と書いた
アプリケーション側のチェックは行われてる。
何度も大前提と言わないと理解できないのか? >>604
> 不正な値を設定したらアプリがエラーを出す、確かに正しいが
> そんなぶっちゃけやるならリッチなUIとかもういらないだろ
アプリがエラーを出すことと、
設定ファイルを簡単に編集できることに何の関係が? >>605
> dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ
画像見せて
ぱっと検索した限りでは、単なる名前と値の羅列しかないですね。
これみてエンドユーザーに設定させろと?
無理でしょ。各アプリが丁寧に作った設定画面と
どれだけ差があると思ってるのさw >>613
何度も言わないと本当に理解できんのなw
大前提としてアプリケーション側でチェックしてあるんだから、
設定を読み込ませれば、エラー出るっていってんの >>612
前提としてツールの実装によっては
滅茶苦茶な値を設定してもスルーされるという話を無視するなよ
簡単に編集出来ても滅茶苦茶な値で喜ぶユーザーいるのか? >>609
> この設定XMLとツールで汎用とはどういう話?
汎用のXML設定ファイルの、汎用とは別のアプリでも同じXMLスキーマを利用できること
(いっとくが利用できるのはスキーマだけだぞw) >>615
アプリで読み込ませるまで滅茶苦茶な値入れても気づかない
ツールが何が嬉しいの? >>616
> 前提としてツールの実装によっては
> 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ
現状だって、テキストエディタで編集したら
メチャクチャな値を設定してもスルーして保存できるじゃん。
アプリケーションに読み込ませたらエラー出るっていってんの >>619
設定ツール使っても何も便利にも改善もされてないけど何か意味あるの? >>618
> アプリで読み込ませるまで滅茶苦茶な値入れても気づかない
> ツールが何が嬉しいの?
ユーザーが簡単に設定変更ができること
メチャクチャな値を入れたらアプリでエラーが出る
メチャクチャな値を入れられない所はエラーが出ない >>620
> 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの?
ユーザーが簡単に設定できるようになるので意味がある。 君の話だと設定項目のウィジェットかどう実装されるかは決まってない
バリデーションもやらなくてもいいしエラーが出るかもわからない。
えーとテキストエディタに比べて嬉しさどこにあるの? >>621
滅茶苦茶な値を入れるのを防ぐ保証ないのに
滅茶苦茶な値を入れるのどうやって防ぐの? >>623
汎用のXML設定ファイルとして仕様が共通化されてるので
設定ツールを含めさまざまなツールやライブラリを作って
共通で利用することができること
またそれらのツールやライブラリを使ってユーザーも開発者も
便利で楽ができること
>>624
テキストエディタで設定ファイルを編集することを考えればわかる。
設定ファイルの編集は可能だが、アプリケーションでチェックが行われる >>625
ツール作ってもツールが何できるかわからないし
期待していたことが期待外れも余裕であるんだろ?
役立たずのツールが作れて何かメリットだって? >>625
いよいよ壊れたレコードのように同じことを繰り返すしか能が無くなってきたな 40年経ってもwindowsレジストリの素晴らしさが理解できないのか。 >>624
結局作る側はユーザーが手で弄ったりする事も考慮して自分でも値のバリデーションをしないといけないもんな
なんつーか本当にものを知らないガキの妄想だよな 汎用ツールの特徴は
・開発者が楽できる(汎用ツールの仕様に合わせて開発すべき)
・ユーザーフレンドリー(直感的?アプリの仕様に関係なく設定はブラウザに似たインターフェース)
・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する)
これだけでもクソ仕様だとわかる。 >>630
これずっと思ってたわ
この人設定と設定の設定の区別がついてないような感じよね 引用忘れた
> ・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する) テキストファイル書いて設定させるなんて昭和末期か平成初期には通用したけど、いまじゃデメリット多くて古くさいってバレバレの手法だよねw >>634
設定が多段のツリー構造になったことで柔軟に構成できる(限度はあるけどフラットなテキストファイルより使い勝手は良い)
パス、キーが判ってれば値の取得と更新はOSにリクエストするだけで済む。
独自ライブラリでR/Wしなくて良いしOSのバージョンが変わってもアプリには影響ない(APIが互換性保つかぎりはw
デメリットとしては「設定を保存するエリアにコメントを書けない」ってのがあるね。 レジストリがテキストより編集しやすいかは習熟度によると思うぞ。慣れたらテキストのほうが見通しが良いし、わかりやすい。 レジストリとかgconfとかって機能してない項目が大量にあるのはなんでなん? >>631
> この人設定と設定の設定の区別がついてないような感じよね
わかった上であえてそうしてるんやで。
なぜなら、設定ファイルをテキストエディタで
修正したいという層が一定数いるから
テキストエディタで修正しないんだったら
設定ファイルにコメント機能なんていらん。
コメントはまさに、設定ファイルにUIが含まれてるってことなんだよ
それみてどんな値を入れるか判断しているわけだから
設定値と設定UIを作り出すタグを分離すれば、
今度はテキストエディタで修正したい人が使いづらくなる UIがどう表示されるか規定されないし
個々のフォームがどういう挙動するかも不明で
使いやすいのかというか実用になるかもわからんけどな > UIがどう表示されるか規定されないし
HTMLだってそうだよ。
そもそもどう表示されるかはデバイスによって異なる
PCで使いやすいUIがスマホでも使いやすいわけじゃない
なんでこうすでに通り過ぎた歴史の話ばかりするだろうか? 現実を否定しているところから始まってる妄想だから現実離れしてて現実的じゃないのは当然やろうな。
こうだったら良かったのにというボヤキなんだろうが、ボヤキにしても無知を晒してるだけだからな。 アイデアとしてはわかるんだよね。
東芝が昔実験的に作ってた。
XMLスタイルシート的なアイデアは大昔から存在するんだが、実用的なものを構築するのはなかなか難しいと思う。 HTMLが規定されてない、という部分を都合よく拡大解釈するし
不味いところは逃げ回るし >>642
なんで現実にある問題点と解決策を言ったら、現実離れになるの?
その理屈だと、効率が悪いと指摘するだけで
効率が悪いのが現実なんだ。現実離れしたことをいうな!ってことになるけど? >>644
拡大解釈だろうがそうでなかろうが、
どちらにしろその解釈に反論できないんでしょ? 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
その規約決定を放棄してお前の頭の中でだけそんなのわかるだろでは話にならない >>648
> 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。
何が言いたいんだかさっぱりわからん。
HTMLの仕様とか見たこと無いのかな?
UIをどうしろとか書いてないよ W3Cは戦場なので、力あるものが勝つし、勝ったものが正しいとは限らない。
裁判と同じだよ。 エンジニアなのに教祖への愛がすべてなのが、ウェブの未熟さを表してるんだよ。 >>645
現実にある問題点はconfig.xmlに独自タグが多いってだけのこと?他にある? ウェブ業界には勉強会と称して毎週ミサがあるだろ。
お互いに啓蒙しあい信仰心を深める。
最後にみんなで歌を歌って解散。
まさにイカ臭い新興宗教じゃないか。 二言目にはHTMLガーであるがこいつが想像してることは
JavaScript・CSS・サーバサイドその他HTTP技術が関わっていのに
XMLの話だけで設定ツールへのその部分の押し込み方が全く不明 >>650
>>648の言いたいことがわからないのは読解能力がないから。お前の妄想をなんとか理解しようとしてるみんなは表現力が乏しい文章に根気よく付き合ってるから。 実際それっぽいのはweb技術に寄生したらelectronですぐ作れるけど、今度はアプリケーション側がhtmlスクレイピング並みに頑張らねばならなくなる。どこに得があるんだって話だよ。 そしてすぐ作れるものを誰も作ってないってことは、もう言わなくてもわかるだろ。
本当に役に立つならすぐ作っちゃえよ。それで飯くっていけるぞ。 Windows 使ってないからレジストリについてググってみた。
Windows を使わない理由が増えた。いや、今更だが…… アホやろ
移植性が段違いじゃんか
それに世界中に使ってる人がいるってことも
無視しとるやんけ、自分が無能なだけや 正直、C89以前のCなんか読めたものじゃないし、
かといってC++11以降の機能使いまくったソースも読めたものじゃない。 >>637
嘘だよ。初心者に優しいのは、テキスト編集だよ。
英語が苦手なだけでしょ。 マウントなんて、大分前からクリックするだけやんけ
それよりディスクの故障チェックもできないとか、そっちのほうが怖いよ >>633
へー、今はむしろナウいんだけどな
取っとけるし 見通しがよいかどうかはシステムのサイズによる。複雑になれば階層構造のレジストリのほうがいいに決まってる。
基本的な型は用意されてるし、細かくセキュリティも設定できるし、読み書き用のAPIも用意されてる。
OS起動時に必ずバックアップを取ってから起動してくれるのもメリット。
なんでもviで作業したいというのが諸悪の根源。開発環境が50年前とい言われても仕方がない。 >>665
英語苦手じゃないけど、ちょっと言ってる意味がわからん。とりあえず、レジストリはめんどくさいぞ。 レジストリより環境変数のほうが使いやすいよな!!!
って人は少ないだろう。 みかんとしいたけだったらみかんのほうが美味しいよな 何も足す必要がないということは究極を極めているということであろうか。 xmlの優位性はテキストだということだけれども、実際テキストエディタでxmlを閲覧すると醜悪そのものだよね。 >>4
Windowsのビルドって、どれぐらいかかるか知ってる? >>669
そういう意味なんだけどね
テキスト編集の方が楽だけど、設定ファイルの雛型に
書いてある説明が英語なのは、日本人にとって辛いかなと
慣れればなんてことないけど。 ちなみに勘違いしてるみたいだけど
autotools 作ったのはGnuではないよ。
自動的にMakefile作るシェルスクリプトが回覧されていく
うちに、みんなで改良加えて、なんとなく出来上がったのを
Gnuが採用しただけだよ。移植性を重視してたからね。
別に好きな奴使えばいいんだよ。気に入るのが無ければ
自分で作ればいい。それが自由であることの尊さなんだから。 autotools使うのは、それだけ多くのライブラリに依存
しているからで、その分のコードを書く手間を
省けるのだから、大したことでは無いね。移植性も
高まるし。でも、それが必要ないなら、別にMakefile添付でも
全然問題ないし、そういうプロジェクトも少なくない。
他のビルドツール利用でも良いし。なんか
勘違いしてない?これらはあらかじめ与えられてるん
じゃなくて、享受するものだよ。嫌なら自分でやるんだ。
近所の落ち葉をかたずけるのと同じさ。君のために
誰かのためにやるんだよ。そう思うなら、自分で
どうにかするんだよ。 良いこと言うね、全くそのとおりだわ
読んでねーけど INIのように書式とデータ構造とAPIが共通化されてるテキストベースの多層構造の設定を保持するメカニズムがあればよいんだよ、Linuxに。 ハイ論破厨ってたまに5chで見るけどいつも論破できてないよな。同一人物? 「ハイ論破」はダサいという風潮はとうにご存知だが必要不可欠な機能
C/C++やPerlのセミコロンみたいなもの 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
平 和は、勝ち取るものです。拡散も含め、お願い致します。 >>684
あなたは、日本人じゃない気がする。
日本人なら絶対しない「ご存知」「機能」の使い方してるから。 へー、LinuxにはJSON読み書きする「共通化されたAPI」ってあるのかぁ。
知らなかったな。
Cで使おうと持ったらインクルードファイルは何をしてして、どんな関数呼べばいいんだろう?
定番のunistd.hかな? JSONってそんないいもんじゃないよね、コメント書けないのは致命的 jsonが爆発的に普及したきっかけはバイナリ保存はしたくないけど、オブジェクトをそのまま保存したいって需要だから
設定に使うとしても開発者よりなんだよな。linuxは開発者フレンドリーだから開発者マインド無いときついってのは理解できるけども。 階層が深くないならiniが見やすくていい
階層が深いならyamlだし、記述性ならxmlだし、どれも一長一短あるけど、テキストエディタで開く設定ファイルならiniは使いやすい 複数行コメントを書けて、日本語も問題ない、Ruby が良い
=begin
複数行
コメント
=end Windows界はいろんな産業ロボットを使ってモノを生産しているのに
Linux界はいまだに手作りでモノを生産しているようなもんだからね。 >>1
Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、
使ってみると使いにくかった、ということはあるかもしれない。
一例として、
$ コマンド名 パラメータ >a
などとして、リダイレクトするとき、stdout と stderr が分かれている
のも、現実的には不便。
$ . スクリプト名
と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない
のも不便。
どちらも、DOS では修正されていた。DOS の方が後発だから。 資本制企業はいかに人件費を削って量産するかを常に考えている。
少ないプログラマでより多くをと。
ところがオープンソースの世界はコーディングすること自体が楽しい
って人々の集いだからな。効率化へのインセンティブが小さい。 >>697
別の環境変数で処理したいなら別の端末を開けば良いわけだから、
スクリプト内での設定を反映しないという仕様は、今となっては
アリガタ迷惑だと思う。
ただ、行儀の悪いわけの分からんスパゲッティーで解読するのも
時間の無駄なスクリプトも多いが。 >>697
stdout と stderr と時系列的に合わせて出力しないと、解読しにくい
場合があるので、結局、2つの出力を合成したいことが多く、
1&>2 a
だったか、覚えていられないような変な記号を書かなくてはならない。
あと、tee コマンドも覚えにくい。 というか何もかも覚えられない
脳が退化しているのか? &> a
と、
1>&2 a
の両方の書き方があったり、export が必要あったり無かったり、
そんなアホみたいなものは、むしろ高級な脳であるほど覚えられない。
高級な脳は、共通原理や一般法則だけを覚えようとし、単純で無意味な情報は
削除される傾向があるから。 >>1
なんという愚かなOSなんだろう。
DOSと同じことがこんなに長くなる :
[DOS]
$ コマンド名 >a
[Linux]
$ コマンド名 1>a 2>&1 >>703
> [DOS]
> $ コマンド名 >a
↑間違い
> [Linux]
> $ コマンド名 1>a 2>&1
↑1は不要
正しくはこうだよ
[DOS]
$ コマンド名 >a 2>&1
[Linux]
$ コマンド名 >a 2>&1
参考
http://tooljp.com/windows/doc/stdout-stderr/stdout-stderr.html
> (4)標準出力と標準エラー出力を同じファイルにリダイレクト
> mycmd.exe > stdout-stderr.txt 2>&1 >>705
DOS に関しては、そもそも原則として多くのツールが、stderr を使わない流儀
だったので、stdout だけをリダイレクトすれば十分だったんだ。
だから、その意味で、
[DOS]
$ コマンド名 >a
は間違ってない。
要は、トータルの使い勝手で考えた場合だから。 ほらほら、間違いを指摘されて、
焦ってきてるぜwww つまり、DOSコマンドは設計に沿わないアプリが多かったということかな? >>709
いや違う。
最初からそれを前提にしていたので間違ってない。
あなたは、DOSの事知らないからそんなこと言ってるのでは。 >>710
いや、むしろ、stderr を滅多に使わないのがDOSの流儀だった。
少なくとも、コンパイラのエラー表示は100%、stdout に出ていたし、
その他のフリーソフトなんかの表示もほぼ、そうだった。 使いにくくなるだけなのに、stderr を使っているソフトが多いのは、Unix系の
プログラマには、実は真の意味では頭の悪いのがいっぱい混じっているから
ではないか。 明言していない前提
他社を憶測で知らないもの扱い
ごく主観的な流儀
主観的な使いにくさでOSの草分け的な開発者を無能扱い
これだけでまともに取り合う気がなくなる。 元々、stdoutとstderrが分れているのには理由がある。
理由もなしに分けたりしないという想像力があれば憶測でモノを言うと恥ずかしいことぐらいわかりそうなもんだが。
標準出力がUIを兼ねていたのでユーザーへのメッセージがerrで塗りつぶされるのが良くないし、
出力結果を次のコマンドに渡すときなどにerrメッセージが混ざると困るし、
コマンドが入力待ちの状態の時、errなんか出たらなにで止まってるのかわからないからな。
当時は無視するしか無いerrもあって切り分けるしかなかった。
例えば標準出力をファイルを書き込んでる最中にエラーを出力するにはstderrに出すべきだろ。
それを使いにくくなるとは。。。 >>715
コンパイラの出力をパイプで渡していくのは時代遅れだと思う。
今は、ファイルに書いて渡せば良い。 >>714
古い時代とはまた違った、今の時代に合った CUI の流儀がある。
Unix好きの人には、古いものを維持し続けようとする人が多すぎるのか、
または、古いソースを使いまわし続けすぎているためか、古い流儀のまま
になっているために効率が下がっている。 >>716
ファイルに書いて渡すと遅くなる
ディスクが遅いとかいう話じゃなくて
並列処理ができなくなるという話 >>719
実際のコンパイルは、a1.c, a2.c, a3.c, ・・・ などを別のCPUコアに渡して、
マルチコアでコンパイルするので、既にCPUコアが完全に使用しきられている。
なので、それ以上、コアに空きが無いので、パイプを使っても並列度が
上がることはほぼ無い。
一方、いったんファイルに書いてもファイル・バッファにキャッシュされ、
実際のディスクへの書き込みは、全く行われないか、または、ずっと後
になってから行われ、コンパイル作業中にはRAM上でデータの受け渡し
が行われるためディスクの遅さは全く関係しないと言っても過言ではない。 >>720
パイプを使っている今はね。
ファイルを作ると遅くなるって言ってるの
今のやり方が最適なの。だからCPUコアを使い切れている >>721
パイプを使っても、0.000001% 位しか速度差が出ないのに、
gccなどのコマンドラインはめちゃくちゃ使いにくくなる。 コンパイラのエラーメッセージは標準出力に出て問題ないだろ。*nix系でも出るぞ。何いってんだこいつ。 パイプを使わないと動画をリアルタイムにエンコード出来ない >>725
別にパイプを使うなとは言ってない。
そういうケースでは使っていい。 どうやら時代遅れなのはお前の頭だと気づいたようだなw 違うな。
古いものと新しいものを逆さに捕らえる人がいて困る。 そもそもstderrの使い方知らなかっただけじゃないの? >>729
そんなことない。
stderr が有っても敢えて使っていなかった DOS の選択は賢いと思ってる。 >>1
gcc や clang も、include path の設定が無視されることがある。
複雑に複数の言語処理系がインストールされている場合に、
include path が勝手に「コマンドPATHから推定して」 決められて
しまい、それを修正したいために、環境変数などを設定しても
優先順位がおかしくて、なかなか修正されないことがある。
しかも、その状況を確認するには、-v オプションを付けて
出てくる長いメッセージを解読しなくてはならない。
また実は、バイナリになってしまってからは修正すること
が難しいパス設定が存在することもある。
その場合は、ソースから make する際に、./configure
のパラメータで決められてしまっている。
つまり、バイナリレベルでは、動作が変えられるように
出来ていない欠陥品が多い。 $ prog1 | prog2 | prog3 > job1.out
$ # で済むところを
$ prog1 > tmp1
$ prog2 < tmp1 > tmp2
$ prog3 < tmp2 > job1.out
$ rm tmp1 tmp2
$ # ってやるのか? >>732
最初のようなパイプでつなぐような表記を、コマンドラインから打つこと自体、問題なんだよ。
むしろ、ファイル名を指定して、少しずつ進んでいくほうが賢い。コマンドラインからだと。
型のあるプログラムだとコンパイラがエラーを出してくれる確率も高いが、
コマンドラインからだと、わずかな間違いが重大な問題に発展しやすい。
それに、どうせ、打ち間違える確率が高いので、何度も試すことになり、最初から
実行し直しになることが多い。
$apt-cyg show | grep -i nantoka
や
$コマンド名 | less
みたいなことやら無くちゃならない頻度が高すぎ。長すぎて馬鹿だ。
こんな設計思想、ダメだ。 正直期待してなかったけど、初めてまともな返答をしてくれたね。
君は自分が世界の中心ではないということを理解すべきだ。
君のために存在するものなど何もない。
それでも適切な方法で助けを求めることはできるはずだ。
〇〇をうまく使えないという理由で〇〇の作者の頭が悪いなどというなら
誰も助けてくれないし君にとって良いことなど何も起こらない。
まあ、それはそれとして、シェルのヒストリ機能や行編集機能は使ってる?
ターミナルエミュレータの copy&paste は?
これらを使ってもまだ大変だと感じるなら Emacs なんかが助けになるかもしれない。 You! Visual Studio codeをinstallしチャイナyo! #ifdef なんかも設定に応じて認識して、ちゃんとコードの色に反映してくれるからねえ。 バランスが取れておらず、かつ、統一感もない。
それが Linux。
また、安さ以外に売りが無いのに最新のハードと最高の通信環境を要求する。 最新のハードを要求する前に、最新のハードのドライバを用意したまえ。 WINE もバイナリは新しい Linuxを要求するのに、Emulator としては、
64BIT Windows はサポートしていなかったりする。
つまり、新しいハードでしか動かないのに、古いOSしかエミュレートできない。
訳分からん。 あたらしいプログラムはPowerShelも対応するようにして
徐々に移行していったらええのに 貼れと言われた気がした
【田】Windows10のダメな点
・個人情報を勝手にネットに垂れ流す
・診断データと使用状況データをMicrosoftに送信する機能をレジストリでオフにしてもなお8時間で4000回、93つの異なるIPのMicrosoftサーバへデータが送信されている
・エロファイルを持っている場合はそれも全て晒される
・間違ってロリファイルを持っていた場合はネットに繋いでいるだけで警察が来る
・死ぬほどUIがダサく異様に使いづらい
・ダサい上に抑揚のないフラットデザインのため、どのウィンドゥが手前で奥なのかわからない
・かつてあった多くの機能の半分以上をカットし、使わない機能をてんこ盛りにしたデブOS
・起動が超遅い。見かけ上早く起動したように見えるだけでほとんどのソフトを読み込んでいない
・スリープ復帰速度はほとんど変わらず
・ファイル圧縮・解凍速度も遅いまま。フリーウェアの圧縮・解凍ツール使ったほうが200%以上高速化する
・ファイルコピー速度が壊滅的に遅い。フリーウェアの高速コピーツール使ったほうが400%は速い
・メモリ使用量が馬鹿みたいに多い。初期は少なく見えるが使えば使うほど多くなる
・タブレットでも動くように設計されているが、利便性もデザインもiPadの足元にも及ばないゴミ
・標準ブラウザにEdgeとかいうゴミを採用。機能が少なすぎる上におそろしく遅くて使い物にならない
・無料のセキュリティソフトと称する重いウィルスソフトが多数憑依している
・仮想デスクトップと称するゴミを搭載。フリーウェアの仮想デスクトップソフトの半分の利便性もない。
・Win8で削除したスタートボタンを恥を忍んで復活させた
・しかしスタートメニューにまつたくいらんメトロや宣伝がゴチャゴチャついて無駄に肥大化、邪魔。機能性がない
・非アクティブウィンドウもスクロール可とかいう、昔からできるような機能を大げさに宣伝
・タッチパネルとして使いやすいUIとして喧伝しているが、デスクトップPCで画面の汚れるタッチ操作を行うのはよほどの馬鹿だけ
・ダサくて見づらいゴミフォント「游書体」がデフォルト設定
・ほとんど反応しないゴミ丸出しの音声認識アシスタントCortana搭載。画面に向かって話しかけているぼっち野郎の姿はバカそのものw リダイレクトやら、
パスに文句言ってる人がいるが、
OS の問題じゃなくてシェルの仕様の話だろ
シェルを変えればいいだけ パスの書式だけならそれで何とかなるけど、構造だけはどうにもならない事がある
\\PC名\共有名\〜 みたいな表記はCreateFileとかに直接投げてそのまんま動く位、
ファイルシステムの構造とそれを実現する為の実装に密接してっかんな VSCodeが出たから、
「やっと、やっと、まともなIDEがLinuxでも使えるようになった! MSがやってくれた! ありがとうMS!」
ってことなんだろうね。 IDEを使ってるのではなく使われてるレベルなんだろーな
別に自分の好きなようにやりゃいいだけだろ Linuxの開発環境はVSCodeが出る前は vi使え! とか大声でいうやつがマジで居たぐらいに貧弱だったな。
環境改善に尽力してるMicrosoft様々だわ。 >>749
Kateでイイじゃん
VSCodeだと、テレメとってくるから
VSCodium入れてっけど
Kateばっか使ってる >>751
VSCodiumの作者が、そう言ってて
わざわざ毒なしのVSCode提供してくれてるから
フィードバック提供しないって
設定すればイイだけなのかもしれんけど
デフォルトでOnになってるし
Officeもそうだけど、そういのばっかり
熱心にやってきて
なにシレット仕込まれるか分かんないから
VSCodium入れてる >>752
マジか。
MSは中国並みに情報収集熱心だな。
中国は国策でやってるわけだが、アメリカもなんぞ法律でもあって情報集めろってやってんのか? >>753
なんなんだろうね
ほんと
ヨーロッパだと、そいうのわりと敏感で
問題になってるみたいだけど 開発環境云々もUbuntu Japanese Teamによる志賀慶一氏のライセンス違反認定が取り消されないのも、
全部無能な鍋田コピペのせい。
鍋田コピペが悪い。 >>754
ね 国によってフィードバックのデフォルトに変化があったりするのかね GCC使ってる時点で性能をスポイルしてるからね。
40年前と同じで問題ないのさw VSCの中の人じゃないが、テレメがあるとしても基本的にはどの機能がどれだけ使われてる
とか、デバッグ情報とかそんなんじゃないかな。"ユーザーエクスペリエンスの向上"のため。
そういうのも集められるのはイヤ、と言われるとアレだけど。
たまにハックしたバージョン入れててそれがクラッシュして、そういうユーザーに限って
SNS等にキレた書き込みをしたりw そういうのもクラッシュトレースを見れれば安心w
今時のOSって、いろんなことを登録するじゃん。あれとかね...
ま、あからさまに個人情報を集めたりしてそれがバレると今時大変なことになるからなあ。 cmakeとか、masonとかninjaとか良く分からん >>751
VCですらMSアカウント必須になって久しいのにテレメトリ無いとは思えんな
コマンドラインのコンパイラさえMSアカウント無いと使えないよ