Rust Part6

**デフォルトの名無しさん** · 2018/07/28(土) 03:04:38.63

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part5
http://mevius.5ch.net/test/read.cgi/tech/1518347244/

**デフォルトの名無しさん** · 2019/06/18(火) 23:05:26.62

>>923
実行環境以外はcrates.ioのAPIから取れるみたいだから可能は可能。
ツールになってるものはぱっとは見つからなかったけど
jsonパースしながら依存関係辿るだけだし適当に作ればいいのでは。

**デフォルトの名無しさん** · 2019/06/19(水) 04:55:23.37

【出資】松本卓朗人工知能詐欺【注意】
https://rio2016.5ch.net/test/read.cgi/rikei/1560859403/

**デフォルトの名無しさん** · 2019/06/19(水) 11:14:57.11

考えてみれば当たり前なんだがcargoはrust周辺しか面倒を見てくれない。他に依存するライブラリがあっても関与しない
つまりビルドは出来るが実行出来ないということが起きる。コード次第ではpanicして何が足りないかすら出力されない
ドキュメントに何を用意すべきなのかちゃんと書いていないcrateも少なからずあって不完全なメッセージ片手に探し回る羽目になる

**デフォルトの名無しさん** · 2019/06/19(水) 18:09:17.84

だいたいリンクでエラーにならない？

**デフォルトの名無しさん** · 2019/06/19(水) 18:26:18.08

Firefoxに重大なセキュリティ欠陥
Rust安全神話崩壊

**デフォルトの名無しさん** · 2019/06/19(水) 18:55:19.96

馬鹿に説明って難しいよな

**デフォルトの名無しさん** · 2019/06/19(水) 19:33:39.71

動的リンク

**デフォルトの名無しさん** · 2019/06/20(木) 06:07:04.22

https://www.itmedia.co.jp/news/articles/1906/19/news060.html

2019年06月19日 07時19分公開
Firefoxに危険度最高の脆弱性、既に攻撃を確認

Array.popの問題により、JavaScriptを操作する際に脆弱性が発生する可能性がある

これ本当にRustのせいじゃないの？

**デフォルトの名無しさん** · 2019/06/20(木) 07:18:41.60

https://developer.mozilla.org/ja/docs/Mozilla/Projects/SpiderMonkey
SpiderMonkey は、C / C++ で書かれた JavaScript エンジンです。Firefoxを含む、Mozillaの複数の製品で使用されており、MPL2 ライセンスの下で利用できます。

**デフォルトの名無しさん** · 2019/06/20(木) 08:04:12.96

GPL or LGPLコードに依存せずにSVGをレンダリングできるライブラリってないかな？
resvgが使えるかと思ったら
>librsvg is heavily tied to GNOME, which makes it painful to distribute outside the Linux ecosystem
とか書いてあるくせにgdkやglibを要求してくるようだ

**デフォルトの名無しさん** · 2019/06/20(木) 08:11:37.69

>>931
リポジトリ上で見る限り、今回のバグで修正されたのはC++のコードみたいだけど。

**デフォルトの名無しさん** · 2019/06/20(木) 10:58:34.09

>>933
https://mevius.5ch.net/test/read.cgi/tech/1443092077/

**デフォルトの名無しさん** · 2019/06/20(木) 17:17:30.44

おい！なんだかバズってるfacebookのlibraのmoveはrustで書かれてるらしいぞ！！

**デフォルトの名無しさん** · 2019/06/20(木) 18:35:24.47

すまん別にバズってはなかった

**デフォルトの名無しさん** · 2019/06/20(木) 19:48:51.60

Rustが脆弱性の原因になると宣伝がパーになるから
あっちこっちでC++のせいにする小細工が行われております

**デフォルトの名無しさん** · 2019/06/20(木) 19:59:14.55

え？MozillaがRustの宣伝の為にFirefoxに脆弱性を！？

**デフォルトの名無しさん** · 2019/06/20(木) 20:23:47.90

ものごとの原因は人間の主観

**デフォルトの名無しさん** · 2019/06/20(木) 20:28:40.92

https://hg.mozilla.org/releases/mozilla-release/rev/99a829d2a2a7859b10508b6f05e99780c5e2dc68
http://imgur.com/2cTynR3.jpg
確かにC++のせいではないな…どちらかといえばRustか…

**デフォルトの名無しさん** · 2019/06/20(木) 20:35:29.73

さっぱりわからん
範囲チェックがどうとかって書いてあるけど
バッファオーバーフロー起こしてたってこと？

まんまＣ＋＋のせいじゃないの？

**デフォルトの名無しさん** · 2019/06/20(木) 20:36:09.76

バグフィックスってかいてあるけどこれが脆弱性修正？
なんがんあんだかわからん

**デフォルトの名無しさん** · 2019/06/20(木) 21:32:48.19

>>939
Rustなら安全に書けるとか言っておいてしっかり脆弱性作り込んだから
これはRustではなくC++のせいだからと火消しに回ってるの
日本語わかる？

**デフォルトの名無しさん** · 2019/06/20(木) 21:43:15.30

>>944
だよな。今回は完全に"Rust"が脆弱性作ったわ…

>>942,943
小細工をやめろ

**デフォルトの名無しさん** · 2019/06/20(木) 22:22:06.30

客観的でない陰謀論者が必死ですね

**デフォルトの名無しさん** · 2019/06/20(木) 22:51:37.82

これはJavaScriptが悪いな

**デフォルトの名無しさん** · 2019/06/20(木) 23:48:26.80

もう病気だな

**デフォルトの名無しさん** · 2019/06/21(金) 00:15:54.00

ElementAccessHasExtraIndexedProperty

凄まじく怪しげな物に変更されとるな。

**デフォルトの名無しさん** · 2019/06/21(金) 00:27:20.17

c++ぽくないコードだな

**デフォルトの名無しさん** · 2019/06/21(金) 00:37:27.76

確か何か変なコーティング規約で作ってなかったっけ

**デフォルトの名無しさん** · 2019/06/21(金) 07:05:15.79

Chromiumのソースもそんなん(長い関数クラス名とか)だけど

**デフォルトの名無しさん** · 2019/06/21(金) 08:04:50.41

どういう経緯で何が起こって開発元は原因は何だとしてるのか
ちゃんと説明しろ

**デフォルトの名無しさん** · 2019/06/21(金) 16:17:30.34

>>953
「セキュリティに関わるのでお答えできません。知りたきゃソース見ろ」
だそうです

**デフォルトの名無しさん** · 2019/06/21(金) 17:18:46.69

危険、危険と騒ぐ無知は有害。速やかに排除すべき

**デフォルトの名無しさん** · 2019/06/21(金) 17:40:54.25

C++はRustだった
今すぐモジラのステマ言語C++を使うのをやめろ

**デフォルトの名無しさん** · 2019/06/21(金) 21:47:37.81

別にfirefoxなくても困らんよ？

**デフォルトの名無しさん** · 2019/06/21(金) 22:00:47.70

それでもFireFoxがいい
軽さとセキュリティの誠実さ
ブックマーク回りはころころ変わってひどいけど

**デフォルトの名無しさん** · 2019/06/21(金) 23:52:53.60

GoogleやMicrosoftのWebブラウザは十数枚開いただけでメモリ消費がやばいことになる
Mozillaならそんなことない

**デフォルトの名無しさん** · 2019/06/23(日) 02:43:54.79

実践Rustのソートが全くわからん

**デフォルトの名無しさん** · 2019/06/23(日) 05:52:27.18

何ページ？おっちゃんが教えたる

**デフォルトの名無しさん** · 2019/06/23(日) 09:03:51.96

実践Rustって、電子書籍版を8インチタブレット(iPad mini)でちゃんと読める大きさ？
前に出たRust本は余白カット表示してギリギリって感じだった

**デフォルトの名無しさん** · 2019/06/23(日) 10:09:46.75

ソーティングネットワークのあたり

**デフォルトの名無しさん** · 2019/06/23(日) 13:00:06.41

>>959
逆だろ
火狐はタブ10個も開けばカクツキ起きるしそれからほどなくしてフリーズ
Chromeはもちろんクソクソ言われてるEdgeすらも
動作の安定面では火狐なんぞには負けん
ちなWin10

**デフォルトの名無しさん** · 2019/06/23(日) 14:46:23.23

>>960
本のステップで分ける説明より、2→4→8→... と増えていく図を見たほうが分かりやすいと思った

ttps://www.cs.rutgers.edu/~venugopa/parallel_summer2012/bitonic_overview.html

**デフォルトの名無しさん** · 2019/06/25(火) 23:51:23.60

>>964
FireFoxで１０タブ開いてみたけどなんも変わらんよ？

**デフォルトの名無しさん** · 2019/06/29(土) 22:20:17.93

>>966
20~30くらい同時に開くとビジーになるからビジーとフリーズの区別がついてないんだと思う。

**デフォルトの名無しさん** · 2019/06/30(日) 03:54:59.91

IEやChromeで100Tabとか開いたらメモリを食いつぶしてまとも動かないよ

**デフォルトの名無しさん** · 2019/06/30(日) 12:09:57.07

ffモナ

**デフォルトの名無しさん** · 2019/06/30(日) 12:50:53.67

その分今でもメモリ周りでバギーってのは笑わせますね。

**デフォルトの名無しさん** · 2019/07/02(火) 23:13:32.01

Firefoxなら100タブくらい大丈夫だよ。IE、Chromiumでそんな事したら他の作業が出来なくなってしまうけど
実際に比べた上でFirefoxを使っている。開発やっていると開くページがどんどん増える

**デフォルトの名無しさん** · 2019/07/03(水) 13:38:17.25

ffが大丈夫だと思うのは気のせい

**デフォルトの名無しさん** · 2019/07/03(水) 23:03:04.57

Rust→IR→Cが実用出来るようになるのはいつだ
LLVMが対応していないアーキテクチャでRustを使いたいねん
それともトランスパイラを作った方が早いかなぁ

**デフォルトの名無しさん** · 2019/07/03(水) 23:13:41.05

>>973
V言語使えよ

**デフォルトの名無しさん** · 2019/07/03(水) 23:20:25.57

IR to Cは昔できたのにな

**デフォルトの名無しさん** · 2019/07/03(水) 23:20:30.76

524 デフォルトの名無しさん sage 2019/07/02(火) 14:38:03.95 ID:ep8keXko
言語機能の複雑さという代償はあったが
GC無しでリージョン推論を実現したのがRust

記述性のためGCを入れつつも遅延を最小にすべく
GCの性能向上に努めたのがGO

一方vlangの公式によると
https://vlang.io/
> V manages memory at compilation time (like Rust)
https://vlang.io/compare
> - No GC
> That's why the language is so simple

・Rustのようにコンパイル時にメモリ管理される
・Goのように書けるがGC不要
・それでいてRustのような複雑さは無い
・という予定(まだ未実装)

本当にこの通り実現するなら
GoとRustの設計者達にマウント取れるレベル
526 デフォルトの名無しさん sage 2019/07/02(火) 14:59:25.78 ID:ep8keXko
ちなみに自動メモリ管理が未実装なので、以下の記事によると
hello worldやvlangコンパイラ自体もメモリリークしているとのこと
https://christine.website/blog/v-vaporware-2019-06-23
> The compiler itself also leaks memory
531 デフォルトの名無しさん 2019/07/02(火) 18:22:15.31 ID:NqAwj9wC
>>526
ｗｗｗ
532 デフォルトの名無しさん sage 2019/07/02(火) 18:59:24.21 ID:8dHuftNb
>>526
あっ・・・（察し）

**デフォルトの名無しさん** · 2019/07/03(水) 23:31:44.31

>>973
rust2cトランスレータはとっくの昔にあるしとっくの昔にどれも開発止まってる
rust->llvm->c->任意のコンパイラで出来るじゃん。

**デフォルトの名無しさん** · 2019/07/04(木) 07:00:47.22

>>974
生ポインタ使えるの？新しすぎるせいからしい情報が見つからんかった

>>977
今出てくるCバックエンドの話って関数レベルで使えれば御の字みたいなのばっかりに見える
プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい

**デフォルトの名無しさん** · 2019/07/04(木) 11:51:58.94

>>608
横田さん潜伏中に生魚あたってハイタのかな？排他だけに。
なかなかRockだね！Lockだけに。

**デフォルトの名無しさん** · 2019/07/04(木) 23:15:23.31

>>978
>プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい
rustでは見たこと無いね。操作的意味論に基づいて命令列とグルーコードに変換するものばかり。
というかそれ以外は難しいと思う。

**デフォルトの名無しさん** · 2019/07/05(金) 01:27:12.64

>>980
やっぱりそうか、残念。LLVMのバックエンドは作れる気がしないしトランスパイラの方が望みがあるけど
それでもELFのパーサとジェネレータ、変換元機械語のデコーダは最低必要だな
こういうのって処理系やエミュレータ等でしばしば使われるけど、単体のライブラリとなるとx86とかの
有名なアーキテクチャですらなかなかないんだよな

**デフォルトの名無しさん** · 2019/07/05(金) 20:56:59.69

Cと比べたらノウハウ少ないかもしれんけど、LLVMバックエンド作るのってそんなに面倒なの？
LLVM->Cって抽象度上げる方向だし参考になるものがもっと少ない気がする。ecmascriptenくらいじゃない？

**デフォルトの名無しさん** · 2019/07/05(金) 21:57:46.40

>>982
Rust to Cは自分の手に負えそうにないので他力本願です
ググって出てくる情報を見る限り最適化コンパイラを自作できるくらいの理解がないとLLVMの理解とバックエンドの開発は難しそうに感じます
各言語やアセンブラを使える程度の理解では歯が立ちそうにないです

なので機械語 to 機械語(もしくはアセンブラ to アセンブラ)の方がまだ望みがあるかなと

**デフォルトの名無しさん** · 2019/07/05(金) 23:46:41.28

バイナリ変換ってかなり壮大な研究テーマでは…。
どうしてもLLVMに触れたくないならLLVM-IR to アセンブリを自作するほうがまだましかな。

結局素直に勉強してLLVMバックエンド作るのが一番早いと思うけど。

**デフォルトの名無しさん** · 2019/07/06(土) 00:04:57.41

んなことするならc使った方がマシ

**デフォルトの名無しさん** · 2019/07/06(土) 06:53:43.23

>>984
LLVM IRってレジスタ数が青天井ですしstd付きとはいえHello worldですら十数本使っているようです
何処まで増えるのか判りませんがレジスタを数百本使うIRとか吐かれたら何とかなる気がしません

勉強すると言ってもどこから手を付ければいいのか判らない状態ですし最近は相対的にローレベルな
情報自体が減少しています。運良く自分が理解できる資料や教材に巡り会えない限り難しそうです

**デフォルトの名無しさん** · 2019/07/06(土) 09:55:08.49

オレオレ → LLVM はレジスタ何本あってもOK
LLVM → CPUネイティブは良きに計らえ

オレらの仕事は前者
気にすんな

**デフォルトの名無しさん** · 2019/07/06(土) 12:04:38.86

そこまで部分の最適化って自分でやらにゃならんし
計算と制約を記述するのに適したその手前までの中間言語ってないじゃろか
Ｌｉｓｐとかか

**デフォルトの名無しさん** · 2019/07/06(土) 13:45:06.47

バイナリ変換ってダブルバッファリング的な事しないと整合性とれねー気がした。

**デフォルトの名無しさん** · 2019/07/06(土) 13:49:10.31

いみふめい

**デフォルトの名無しさん** · 2019/07/06(土) 17:36:17.74

>>988
レジスタが1～2本足りないくらいなら使用頻度の低いのからメモリに逃がす方法で何とかなりそうだけど
全然足りない場合全く別の方法が必要そうですが思いつかないです。自分にとっては高度な問題です

Rustと言うかLLVMが吐けてターゲットとの相性が良さそうなアーキテクチャを選ぶ必要があるけどこれも難問かな
IA32/AMD64はメジャーだけど建て増ししすぎでアドレッシングモードとかスーパーカオスだし無駄に命令も多い
ARM7あたりが無難だろうか。分岐処理が特徴的なようだけどRISCの割にレジスタが少なめなのも好条件か
純RISC系は命令セットが単純だけどレジスタが多くてLLVM IRと同じ問題が出てきそう

**デフォルトの名無しさん** · 2019/07/06(土) 17:38:47.90

キューイングしてガンガン処理して節目でプログラムカウンタを1増やす。とか理想を語る俺。

**デフォルトの名無しさん** · 2019/07/07(日) 16:07:05.22

2つのvectorの同じインデックスの要素を比較したいときってどうかくのがスマートなんでしょう

**デフォルトの名無しさん** · 2019/07/07(日) 16:38:57.74

>>993
zip

**デフォルトの名無しさん** · 2019/07/07(日) 23:58:58.81

MISPならツールチェイン揃ってるからPS系ハードで動かないことはない

**デフォルトの名無しさん** · 2019/07/14(日) 21:58:47.03

コンパイラチェッカーについて簡潔にまとまっている資料とかないんだろうか
数ヶ月ぶりに触ったらすっかり記憶の彼方だわ

**デフォルトの名無しさん** · 2019/07/14(日) 23:32:23.74

次スレ立てた
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2019/07/15(月) 16:19:43.86

RustってVisual Studio Codeとかでビルドしたりインテリセンスが利いたりするようにならんの

**デフォルトの名無しさん** · 2019/07/15(月) 19:12:06.92

質問いいですか？∩(　´Α｀)

**デフォルトの名無しさん** · 2019/07/15(月) 19:19:28.82

いいよ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 352日 16時間 14分 50秒