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/

**デフォルトの名無しさん** · 2018/08/20(月) 21:31:16.82

いやだって、なんでわざわざこの題材っていう
リソーススタベーションに対する
Rustならではのスマートな解答があるのかと思えば、ナニコレ
ならなんでこの題材にしたのか不明

**デフォルトの名無しさん** · 2018/08/20(月) 21:38:09.93

Rustにスマートさなんてないただある種の間違いが少なくなると主張している

なにをやるにもつっかかる
Rustだけに

**デフォルトの名無しさん** · 2018/08/20(月) 21:41:58.64

Rustは並列性がどうとか言ってなかったっけ
それで最初の題材でコレもってくるセンスが謎

**デフォルトの名無しさん** · 2018/08/20(月) 22:08:57.88

何が謎か分からん

**デフォルトの名無しさん** · 2018/08/20(月) 22:23:58.46

>>146
ここは書いた本人的にもいまいちだったと思っていたらしく、本家では結構前に削除されてる。
まあチュートリアルならせめてmutexではなくchannelだとは思う。

**デフォルトの名無しさん** · 2018/08/20(月) 22:34:49.09

うーむそうかな
並列処理ではmutexはかなり一般的で本質的だと思うけど
ロックを得ないことに安全に並列処理はできないのだし

**デフォルトの名無しさん** · 2018/08/20(月) 22:35:51.84

結局なんでカニなん？

**デフォルトの名無しさん** · 2018/08/20(月) 22:39:02.32

mutexがスコープ抜けた時点で勝手に解放されるのが恰好いい的な？

**デフォルトの名無しさん** · 2018/08/20(月) 22:47:50.39

>>151
一般的で本質的ってのはその通りだと思うけど、
チュートリアルで一番最初に導入すべきかというと、そうでもないのでは？って感じかな。

**デフォルトの名無しさん** · 2018/08/20(月) 22:49:01.92

カニチャーハン氏はRustに全然関係してないからね

**デフォルトの名無しさん** · 2018/08/20(月) 23:03:39.98

Kernicharhan & Ritchie

**デフォルトの名無しさん** · 2018/08/20(月) 23:17:29.99

>>152
おまいら(rustacean)の先祖がミジンコ、もとい甲殻類(crustacean)だから

**デフォルトの名無しさん** · 2018/08/21(火) 07:16:48.68

rustらしさといえば&と&mutの仕組みがそのままスレッド間でも使えるところとか
RAIIとかmoveも良いけどc++にもあるので

**デフォルトの名無しさん** · 2018/08/21(火) 13:49:43.65

rustらしく書いたコードって、&と&mutが大量に出てきて、なんか見た目ごちゃついてない？
move多用で書きたくなる

**デフォルトの名無しさん** · 2018/08/21(火) 17:52:41.07

clone多用しないならそれで良い

**デフォルトの名無しさん** · 2018/08/21(火) 19:13:44.58

&やmutはまだいいけどライフタイムとジェネリクスが入り乱れると頭抱える
自分じゃ書けないからライブラリのコード読むときだけど

**デフォルトの名無しさん** · 2018/08/21(火) 21:48:12.99

impl traitでちょっと楽になったけど、書きながら試行錯誤しているときに関数にして切り出すのが面倒
ちゃんと設計しろよって言われるかもしれんが、rustの仕様とライブラリ全部きっちり頭に入れるのも非現実的だと思ってる

**デフォルトの名無しさん** · 2018/08/22(水) 04:11:36.67

絶対に必要、ってとこ以外でmoveするとclippyに怒られてくやしい

**デフォルトの名無しさん** · 2018/08/22(水) 19:18:34.56

>>150
バグってるからだぞ。

他人の書いたマクロが拷問だよな。

**164** · 2018/08/22(水) 19:53:16.67

わるい。バグは修正したんだった。削除した理由はこっち。
ttps://github.com/rust-lang/rust/pull/30595

> まあチュートリアルならせめてmutexではなくchannelだとは思う。
これも冒頭二段落に書いてある。

**デフォルトの名無しさん** · 2018/08/23(木) 01:21:36.71

存在型と量化子安定してたのか。
( ﾟ∀ﾟ)o彡ﾟG・A・T!!
( ﾟ∀ﾟ)o彡ﾟG・A・T!!
( ﾟ∀ﾟ)o彡ﾟG・A・T!!

**デフォルトの名無しさん** · 2018/08/23(木) 12:07:00.98

Vecのswap_remove()って賢いやり方だな
どこ発祥の文化？　C++あたり？

**デフォルトの名無しさん** · 2018/08/23(木) 23:27:32.87

交換を一回しかしない配列の回転の応用だからJon BentleyのProgramming Pearlsだな。

**デフォルトの名無しさん** · 2018/08/24(金) 00:58:26.59

>>168
へー、ピアソンから出てた『珠玉のプログラミング』か
読んでみたい

**デフォルトの名無しさん** · 2018/08/24(金) 12:20:35.42

>>169
つまらんよ

**デフォルトの名無しさん** · 2018/08/25(土) 11:49:09.72

古典ですな。
今読んでもそんな悪くない本だと思う。

**デフォルトの名無しさん** · 2018/08/26(日) 17:59:52.65

rustfmt-nightlyがビルドできないお(´・ω・`)

**デフォルトの名無しさん** · 2018/08/26(日) 23:46:50.01

古めのnightlyじゃないと無理

**デフォルトの名無しさん** · 2018/08/27(月) 17:35:35.62

PR出ててもうマージされてた(｀・ω・´)

**デフォルトの名無しさん** · 2018/09/01(土) 01:39:37.63

VSCodeでRust Tool Missingと出てたからクリックしたらエラーたくさん出た。
ググったらNightlyのコンパイラじゃないとRacer(レイサーってのがRust Toolのこと？)は入れられないと
あったから。とりあえずRust Nightlyを入れた。
その後、また同じように入れようとしてみる。
cargo install racer && cargo install rustfmt && cargo install rustsym Updating registry `https://github.com/rust-lang/crates.io-index`

ダメだった！エラーが5個くらい出る。
どうすれば良いの？

**デフォルトの名無しさん** · 2018/09/01(土) 11:07:28.41

>>175
IntelliJを入れる

**デフォルトの名無しさん** · 2018/09/01(土) 22:51:12.01

>>175
rust関係ないからcodeスレへ。アドオン何使ってるかもちゃんと書けよ。

**デフォルトの名無しさん** · 2018/09/02(日) 05:13:21.00

VSCodeって言っちゃったのがまずかった
VSCodeのターミナル（WSLのzsh）で出たエラーだから、MacでもLinuxでも、このエラー起こると思う！
最近Rustインストールした人で、同じエラー出ている人いないかな？
GithubのRacerに書かれてある方法で試してみる・・

**デフォルトの名無しさん** · 2018/09/02(日) 08:10:44.09

エラーを書かずに同じエラーとわ

**デフォルトの名無しさん** · 2018/09/03(月) 05:33:11.38

これはすごい

https://github.com/EbTech/rust-algorithms

**デフォルトの名無しさん** · 2018/09/03(月) 23:57:51.98

Rustで使いやすいGUIツールキットってどんなのがあるんだろうな
マルチプラットフォームかつネイティブでそこそこのパフォーマンスを得られるのが良い
wxWidgetsは有名だけどwxRustは3年放置されている。使えるのかな

**デフォルトの名無しさん** · 2018/09/04(火) 00:37:25.68

良い塩梅に発酵したときが食べ頃

**デフォルトの名無しさん** · 2018/09/04(火) 02:01:24.43

>>181
gtk-rsは?
前にちょっと触ってみただけだから実用レベルかは知らんが
今でも積極的にコミットされてるから期待はできそう

純Rust製ならPistonが作ってるconrodかな？winitとgliumをベースにしてるっぽい？
こっちは使ったことすら無いんで全く分からん
純Rust製に惹かれたが、なかなか時間が作れなくて放置中…
因みにwinitはイベント管理用でgliumはOpenGLのクレートね

**デフォルトの名無しさん** · 2018/09/04(火) 06:57:27.16

>>183
ggr-ksに見えた

**デフォルトの名無しさん** · 2018/09/04(火) 09:10:47.26

>>178
GithubのRacerに書いてあるとおりにやったらいけた
Rust Nightlyを入れただけではダメで
rustup toolchain add nightly
cargo +nightly install racer
でいけた。Multirustという機能があるからNightlyを使いたければ毎回指定するということを初めて知った

**デフォルトの名無しさん** · 2018/09/04(火) 10:31:00.23

>>184
+1

**デフォルトの名無しさん** · 2018/09/04(火) 21:01:57.03

>>184
ワロタ

**デフォルトの名無しさん** · 2018/09/05(水) 00:23:07.06

rlsじゃなくてracer使うのか

**デフォルトの名無しさん** · 2018/09/05(水) 03:15:12.05

RLSだけでいいの？それならRLSでいきたい
でもNightlyをデフォルトに設定したらRLSがスタートできなかった

**デフォルトの名無しさん** · 2018/09/05(水) 03:15:35.14

Rusty Codeっていうのにした

**181** · 2018/09/05(水) 07:39:35.54

>>183
ありがとう。GTK+が無難ですかね。gtk-rsを試してみます

純Rustは確かに惹かれますがこれってネイティブなのだろうか・・・

**デフォルトの名無しさん** · 2018/09/05(水) 07:46:50.58

Intellij Rustの作者が作ってるlibsyntax2がLSPを提供するようになってる
https://github.com/matklad/libsyntax2/tree/master/crates/server

racerの代わりになる日が来るだろうか？
IDE機能の提供はコンパイラでやるのが一番いいんだろうけど

**デフォルトの名無しさん** · 2018/09/05(水) 07:48:44.63

>>183
>>191
gtkってマルチプラットフォームと言えるの？
Linuxでしかまともに動かないイメージ
まあWindowsでは最低限は動くのかもしれんけどmacOSではダメダメでしょう

**181** · 2018/09/05(水) 08:06:31.33

>>193
そうなの？
まぁ今回の用途はWindowsとLinux/*BSDで動けばよし
たしかGIMPはGTKだったはず

**デフォルトの名無しさん** · 2018/09/05(水) 08:14:42.53

え、エレクトロン

**デフォルトの名無しさん** · 2018/09/05(水) 09:01:55.04

そもそもgimpを作るためにgtk作ったわけで…

**デフォルトの名無しさん** · 2018/09/05(水) 11:38:43.13

GTKは糞

**デフォルトの名無しさん** · 2018/09/05(水) 16:19:07.91

マイナー言語のGUIにはGtkバインディングぐらいしかないのが現実

**181** · 2018/09/05(水) 18:50:23.45

GTKのバインディングがあるならTkのバインディングも・・・と思ったら見あたらない？
Tkも一応ネイティブだったはず。機能面はぱっとしないが今回の用途には足りるかも

>>195
その手のWeb技術ベースのってアプリケーション側からウィジェットを更新する術に乏しい
印象があるけどそうでもないのかな

**デフォルトの名無しさん** · 2018/09/05(水) 20:07:45.33

ウィジェットってこの文脈だとどいう意味？

**デフォルトの名無しさん** · 2018/09/05(水) 21:04:58.50

OS(フレームワーク)ネイティブのGUIコンポーネントって意味だと思う。
というか、こっちの意味での利用のほうがコンピュータ的には一般的だったかと。

**デフォルトの名無しさん** · 2018/09/05(水) 22:08:13.79

Windows向けRustのリンカがlldになるのはいつかな

**デフォルトの名無しさん** · 2018/09/06(木) 00:48:46.68

GIMPはMotif・・・。うん。わかってるよ。

>>191
msvcツールチェーンでビルド面倒くさいから頑張れ。

**デフォルトの名無しさん** · 2018/09/08(土) 20:22:07.67

何かやるのに言語からつくっちゃえって、どうなんだろ。

**デフォルトの名無しさん** · 2018/09/08(土) 21:39:35.66

なにかやるわけでもないのに言語だけ作るほうが珍しい気もするぞ。
で、どの言語のこと言ってるの？

**デフォルトの名無しさん** · 2018/09/08(土) 21:50:01.66

>>205
Rust

**デフォルトの名無しさん** · 2018/09/08(土) 22:35:38.88

Cの事じゃないのか。

**デフォルトの名無しさん** · 2018/09/09(日) 17:19:35.86

GUIといえばlibuiはどうだろう？

というかRustでGUIって面倒くさそう

**デフォルトの名無しさん** · 2018/09/09(日) 18:05:38.77

面倒臭いと思うよ

GUIだと大抵はイベントハンドラ多用する場合が多いから
Rustだと多分クロージャを渡すことになって
キャプチャする変数の所有権が絡んできて面倒なことになる

可能な限りデータを全て不変にして参照カウンタ使うのが一番楽そう
誰かもっと良い方法知ってたら教えて

**デフォルトの名無しさん** · 2018/09/09(日) 18:56:16.25

キャプチャ必要かな。しなけりゃいいんじゃね？
RxやReduxみたいなのならRustでもできるような気がするが。

**デフォルトの名無しさん** · 2018/09/09(日) 20:18:26.49

wasm来たらhtmlでいいじゃん

**デフォルトの名無しさん** · 2018/09/09(日) 23:57:56.69

>>209
相互/循環参照があり得るから参照カウンタじゃ無理だよ。
メモリ管理面の煩わしさを考慮するならjavaみたい
にイベントハンドラをtraitにしてユーザーデータ自身に
実装させればいいけど、今ではこのアプローチ自体が煩わしいと思う。

あと参照カウンタの場合一度に多すぎる解放処理が発生して
UIがもたつく可能性があるね。
トレーシングGCなら必要ないなら遅らせるからこういう事は起きない。

rustでトレーシングGC使う場合rootingはプログラマが行う必要があるから
自前でメモリ管理するのと同じだし、それ以外にGUIのシーングラフ自体にトレーシングGCがいるね。
ffiで既存のgui利用してrustからはデータ渡すだけにするのが簡単だと思う。

**デフォルトの名無しさん** · 2018/09/10(月) 14:20:14.67

yewとrelmが気になる

**デフォルトの名無しさん** · 2018/09/10(月) 19:39:57.20

ちなみにWEB開発のサーバーサイドでRustって現実味あるの？
Goがたまに使われてるから、Rustにもチャンスあるのかなと思ったけど

**デフォルトの名無しさん** · 2018/09/10(月) 20:02:06.79

君が作ればチャンスは無限大

**デフォルトの名無しさん** · 2018/09/10(月) 20:44:31.47

Goは手軽さと性能のバランスが丁度いいから

**デフォルトの名無しさん** · 2018/09/10(月) 21:33:40.66

現実味の程度による

**デフォルトの名無しさん** · 2018/09/10(月) 21:58:39.88

予算と工数的に競技志向のFPSのバトルサーバならRustも現実的だけどマッチングサーバなら現実的じゃないとかありそうよね

**デフォルトの名無しさん** · 2018/09/10(月) 22:17:46.90

現実になるかどうかは言語じゃなくでプログラマ次第でしょ
俺は現実に使ってるけど

**デフォルトの名無しさん** · 2018/09/10(月) 23:11:54.52

それ言い出したらアセンブラでもcでもプログラマ次第だわな。

**デフォルトの名無しさん** · 2018/09/10(月) 23:16:12.14

言語の決定権が

**デフォルトの名無しさん** · 2018/09/11(火) 00:22:51.64

適材適所で言語を選べるか？って事でしょ

**デフォルトの名無しさん** · 2018/09/11(火) 00:59:46.27

Rubyでいう

v = [1, 2, 3].map(){|e| e.to_f }

をrustで書きたくて、以下のように書いたんだけど、

let v = [1, 2, 3].iter().map(|x| *x as f32).collect();

vの型が推論できなくてコンパイルが通らない。助けて！

**デフォルトの名無しさん** · 2018/09/11(火) 08:51:05.30

let v = [1, 2, 3].iter().map(|x| *x as f32).collect::<Vec<_>>();
とか
let v:Vec<_> = [1, 2, 3].iter().map(|x| *x as f32).collect();

collectをジェネリックにする代わりに型推論できなくするのは良いアイデアだったのか

**デフォルトの名無しさん** · 2018/09/11(火) 22:15:57.71

rust的にはturbofish使うもんだけど型注釈をよく見かけるね。

**デフォルトの名無しさん** · 2018/09/11(火) 22:25:10.48

>>224
参考になりました！
これどちらも vec<f32> になるんですよね？
ヒープ確保じゃなくてスタックの配列への変換は無理ですかね？

**デフォルトの名無しさん** · 2018/09/11(火) 23:40:31.29

>>226
ttps://stackoverflow.com/questions/26441916/dynamic-array-allocation-on-stack-in-c
Cでも駄目で、C++ならオッケーだったけな。Rustはできなかった。

もしできるようになっても、その関数の下にどれくらいコールスタックが積まれているのか、
この関数の上にどれくらい呼び出しが控えているかを熟慮しないとすぐstack overflow起こすんで、よっぽどクリティカルでなければやらんほうがええんじゃないか

**デフォルトの名無しさん** · 2018/09/12(水) 00:27:32.15

>>227
逆やー。
Cではオプション扱い、C++では不可

**デフォルトの名無しさん** · 2018/09/12(水) 01:54:03.48

>>228
追いかけきれてるわけではないけど、
allocaについても言及されているrfc#1909の第一段階が、8/19にマージされてるっぽい。

近い将来にallocaが完全サポートされる感じなんですかねぇ？

**226** · 2018/09/12(水) 03:38:36.44

んーん、なるほど。
Rustには現状、スタックを伸長するalloca相当がないから件の場合、固定配列を求める事は出来ないってことですかね。

**デフォルトの名無しさん** · 2018/09/12(水) 19:11:41.82

cloneていつ付けてる？
不用意にcloneするのを避けたくて最小限にしていたんだけどテスト書くとき辛い
derefでcloneされるのはcopyついているやつだけ？

**デフォルトの名無しさん** · 2018/09/12(水) 20:48:13.21

テストの時辛いってのは
↓のアトリビュートじゃ解決できないの？

#[cfg_attr(test, derive(Clone))]

**デフォルトの名無しさん** · 2018/09/12(水) 20:56:43.30

omg
それでいきますわ！ありがとう！

**デフォルトの名無しさん** · 2018/09/12(水) 22:49:53.02

>>224
> 型推論できなくする
できるよ。
rust by exampleを例にすると
ttps://play.rust-lang.org/?gist=3cbef33631cbed2a2f0dce6439da4942&version=stable&mode=debug&edition=2015

上記の`i32::from_str`や`<i32 as std::str::FromStr>::from_str`のi32を見て推論してる。
ただのstd::str::FromStrでは推論できないってエラーになる。

**デフォルトの名無しさん** · 2018/09/13(木) 18:02:19.58

低コストで探索できるらしいB+木ってなんぞや。ググるといっぱい出てくるがどいつもこいつも抽象的
「で、それがどう活用できるのか？」と言う疑問が解決しない
もちろんRustでコーディングする予定

**デフォルトの名無しさん** · 2018/09/13(木) 20:57:57.27

>>235
てけとーにググってきたやつ
https://christina04.hatenablog.com/entry/2017/05/17/190000

で、B+ツリーはリーフノード間にリンクがある構造。

リンクがあると何が嬉しいかというと、
データベースで値の範囲で検索する際、先頭が見つかればリンクをたどってレコードが抽出できる。一例として。

**デフォルトの名無しさん** · 2018/09/13(木) 21:29:20.76

B木とそのバリエーションは、ディスクのように一定の大きさを持ったブロック単位で読み書きする
記憶装置上に置くのに適した木構造。
そういう使い方をしないんだったら効率が悪い木構造でしかない。

**235** · 2018/09/13(木) 22:11:03.43

ありがとう

>>236
そのような説明はいっぱい出てくるんですがそれを実用へ落とし込むのに必要なピースがわかりません
データベースやファイルシステムを作れる人ならその説明で十分なのだろうと思いますが
自分はそのような経験がないので「ファイルシステム」や「B+木」等のキーワードからその不足分にたどり
着けないでいます

>>237
まさしくその用途を考えています
・大容量のボリュームを扱う (数百GB～TB)
・ファイルをたくさん入れる (万～)
・ファイルの中身へのアクセスコストが低い
・充填率に優れる
・フラッシュメモリベースのメディアで使用する
みたいなファイルシステムを作れないかなーと。個人が扱うファイルシステムだとFAT32あたりがよく使われると思いますが
そろそろ最大ボリュームの上限を突破しそうだし、ディレクトリの探索が容易じゃないし(特にLFN使用時)
充填率も良いとは言えないしと、いろいろ課題が多いのでいっそ俺ファイルシステムを作ろうかと

**デフォルトの名無しさん** · 2018/09/13(木) 22:24:39.91

B木の実装は、共立出版の「ファイル構造」という本が詳細に分かりやすく説明されていてよかった。
残念ながらもう絶版らしいが。

**デフォルトの名無しさん** · 2018/09/13(木) 23:23:13.30

bit別冊は大部処分したけど似た本はもう無いと判断して捨てなかった一冊

今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう

**デフォルトの名無しさん** · 2018/09/14(金) 00:34:41.33

>>239
英語版ならまだあるようだし、pdfでも見れるな。

**デフォルトの名無しさん** · 2018/09/14(金) 11:13:17.17

1.29.0来たね

**デフォルトの名無しさん** · 2018/09/14(金) 17:04:14.02

来たー

**235** · 2018/09/14(金) 22:55:36.33

ありがとう

>>239-241
尼のマケプレの値段ヤバイですね。原書？のPDFは入手できたので見てみます

>今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう
うへぇ。ファイルシステムドライバの仕様がどうなっているのかを理解した上で、ジャーナリングや
スナップショットなどの付加機能を分離しつつ読む必要がありそう
オープンソースといえどもこの辺の情報はお世辞にも豊富ではないのもつらいところです

**デフォルトの名無しさん** · 2018/09/14(金) 23:38:15.74

まあ読むならext3ぐらいからじゃないかな？
losetupやbrdで小規模なデバイス上にmkfsしてhexdump使って媒体構造見るとか
system tapやblktraceで処理やアクセス箇所見るとか
crashでカレントプロセス覗くとか
printk仕込んで処理フロー確認するとか

昔勉強したけど他に何やったかもう覚えてないや