Rust Part6
■ このスレッドは過去ログ倉庫に格納されています
ありがとう
>>239-241
尼のマケプレの値段ヤバイですね。原書?のPDFは入手できたので見てみます
>今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう
うへぇ。ファイルシステムドライバの仕様がどうなっているのかを理解した上で、ジャーナリングや
スナップショットなどの付加機能を分離しつつ読む必要がありそう
オープンソースといえどもこの辺の情報はお世辞にも豊富ではないのもつらいところです まあ読むならext3ぐらいからじゃないかな?
losetupやbrdで小規模なデバイス上にmkfsしてhexdump使って媒体構造見るとか
system tapやblktraceで処理やアクセス箇所見るとか
crashでカレントプロセス覗くとか
printk仕込んで処理フロー確認するとか
昔勉強したけど他に何やったかもう覚えてないや まさかこんなところで共立出版というガチな名前を聞くとは思わなかった。
ねねっちがいるのかこのスレには。最近Rと統計ばっかだよねあそこ。
ところでファイル構造の古書店の通販見つけたけど長すぎてurl貼れない。 共立出版って大学数学やら物理やらの教科書としてはまあまあ使われてるんじゃない? テキストとワインバーグ本とすべての人のためのJavaプログラミングのところだね。 >>247
共立出版で情報系の教科書としては次の2つのシリーズは好著が多い良いシリーズだ
・情報数学講座
・アルゴリズムサイエンスシリーズ
あと、共立出版でプログラミングの本と言えばとっくに時代遅れになっているが
カーニハン&リッチーの『プログラミング言語C』は外せない
恐らくこの訳書は初版と第2版とを合わせると、共立出版の情報系の書籍の中で圧倒的な部数を稼いだはず
それ以外にもカーニハン本の翻訳を日本で最初に出したのは共立出版だ
『プログラム書法』、『ソフトウェア作法』、『プログラミング作法』とね
今の若い人たちは存在していたことすら知らないだろうけど、共立出版は bit という月刊誌を出していた
これはB5版のころはソフトウェア技術者にとっての教養雑誌で、理論的な話題の記事も載せていたし
チューリング賞の受賞記念講演の翻訳も毎年載せていた
上に名前が出てた『ファイル構造』は元は bit誌の別冊か臨時増刊として出版されたものが
需要が多かったので増刷を機に単行本化されたものだ
だが部数が徐々に減ってきたのをテコ入れとばかりに編集長が変わって、版型をB5版からA4版に変え
記事も教養的なのから実用的なもの中心に変えてしまったら、昔からの読者の多くが離れて
急激に廃刊(建前上は休刊)に追い込まれた
bit誌の廃刊以降、共立出版の情報科学系の書籍の出版点数はかなり減少したような印象がある
現在の共立出版は数学書の出版に特に力を入れているみたいだね bit本誌、いまだに捨てられなくて本棚1段占領している。
ユニマガは引っ越しの時に全部捨てちゃったが。 ここで質問しても許されるのでしょうか?ダメそうなら、申し訳ないです。
S式を使って遊ぼうとしてRustで見様見真似で書こうとしたんですが、コンパイルすらできません…。
ヘッタクソなコードで恐縮ですが、以下の52行目で「`s` does not live long enough」と怒られます。
https://pastebin.com/94ZPh2dL
まず、's'がスタックに確保されていて、parseから返った先で(つまり、スタックが解放されたあとで)
sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
また、どのように対処すればよろしいでしょうか。
たぶん、根本的なところから理解できていないのだと思いますが、ご教授お願いいたします。 Nodeがsへの参照を持っているのにsが解放されちゃうからじゃないかなあ みたかんじsymbolを&strじゃなくてStringにしてsをmoveさせればよいと思うけど >>253
>sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
合ってる。
sはparse関数の中で確保されてる。
そのsの借用(as_strしてるから借用することになる)をparse関数の外に出そうとしてるから
sの借用がsより長命になるのでrustではエラーになる。
sはparse関数の呼び出しが終わると解放されるからこれはダングリングポインタだよね。
>また、どのように対処すればよろしいでしょうか。
この場合、Node<'a>は文字列のsymbolフィールドを所有する側だから&strじゃなくてStringにすればいい。
apiの設計の時点でownd valueとborrowed valueを意識すればいい。
あとleftとrightが借用になってて、これはこれで設計的に間違いじゃないんだけど問題出るかも。 コピーのコストが嫌だからとりあえず参照にしとこう、の精神は早々に破綻するよね
似たようなパーサ書いてて同じようにコンパイラにボロクソに言われたことがある
それ以来、このデータは誰が持っているべきなのか?を意識して書くようにして、
コンパイラに怒られたら「何か抜け道がきっとある」って思うようになれたし、リファレンス探すと大体解決するようになったよ 皆さん、お返事ありがとうございます。
とても参考になります。
もう少し、頑張ってみます。
# ピンポイントで質問できるのは、本当にありがたいです。 ありがとう。File Structuresを眺めていますが英語なのであまりはかどらないです
二分木およびその発展系の説明は十中八九キーとして数字が使われているけど
ファイルシステムの入力はファイルパスであり可変長の文字列。この部分はどう埋めればいいのだろうか
ハッシュテーブルでも使えという話なのか?しかしそれならハッシュテーブルを使ってファイルのメタデータを
探索してしまった方が早そうだけどそういう問題ではないんだろうな 最近でたオライリーの本って
Rust公式ドキュメントの2018でもSecond Editionでもなく
明らかに初版が元になってるよね時期的に >>260
ブロック管理に使うからキーは数字で問題ない Second Edition出てるんだっけ?
ググってみても First Edition, Third Release が 2018-6-22 としか見つからないんだけど。 目次の構成はSecondに近いか?
サンプルプログラムの発行時期は10ヶ月前だからそんなに古くはないのかもな
オライリー原書
http://shop.oreilly.com/product/0636920040385.do
公式ドキュメント日本語訳
https://doc.rust-jp.rs/
ちな最新の2018版ってGithubみた感じリアルタイムに更新されてるっぽいな
https://doc.rust-lang.org/book/index.html >>262
ありがとう。あれ?自分が勘違いしているのかな
B+木やB*木をファイルのメタデータの探索に使っていると思っていたけどそうではなくデータを格納しているブロックの探索に使っているということ? 翻訳元のISBNと原書3rd releaseのISBNが違うことは確認したけど、たぶんこのerrataに載ってる修正くらいだろう。
https://www.oreilly.com/catalog/errata.csp?isbn=9781491927212 >>261,265
オライリーのカニ本の初版一版は1.17.0。TRPLの日本語訳は相当古い。
2018はverでいうと1.31.0に相当する。いまのstabuleは1.29.0。
それにTRPLでもまだ文書化されてない機能あるしな。
非初学者向けならStep Ahead with Rustもある。 6週間で0.1バージョン上がるから一年半前のバージョンか
進化はえーな >>266
> ファイルシステムの入力はファイルパスであり可変長の文字列
ファイルシステムへの入力は inode、dir、dentry がほとんどじゃないか?
create:dir と dentry をキーにinode作成
readdir:dir をキーに dirent を作成
open:inode をキーに open
ext4 を少し読んだ感じこうだった
inode 番号をキーに管理すればよいのでは? >>271
これってたぶん自己参照構造体(self-referential struct)の話だよね?
自己参照構造体は未定義動作の危険性があるので現状のRustでは表現できない
詳しくは↓の「自己参照構造体」のところを読んで
ttps://qiita.com/ubnt_intrepid/items/df70da960b21b222d0ad >>273
>>271の場合だとRc使っても無理な気がするんだけど…
ソースコード見せて >>271
>>272と同意見だけど27行目でどうやっても自分の参照を関数外に出すから無理だな。
借用じゃなくてBoxでもってクローンすればよくね? タプルにFromStrトレイトを実装するのって無理なんですか?
https://ideone.com/iNMuPL implしたい型か、traitのどっちかが自分のものでないと駄目って制約があるから駄目です
何でこんな制約があるかは理解してないけど open等させるものか!っていう強い意志。new type patterns使え。 Rustに関しての発信の多い日本人のツイッターアカウントを何人か教えて
フォローしてRustの情報集めたい rustlang の Discord に Rust(Steam) をクレクレしてるのが出現してる
さすがにベタすぎるのでネタかと思ったけど
「Rust言語は誰にでもフリーだよ!」と住人にやさしく説明されててちょっと笑った
そういう仕込みのフリとオチだったのかもしれないが Rust信者ってブロッキングにも賛成なんだろうなあ
邪悪だ async/awaitのあたりがきれいに書けないなら、ブロッキング+スレッドの方が実用的でしょ いやいやがんばってノンブロッキング対応してるでしょ モジラがバックにいてカワンゴが布教してる技術なんてよく使う気になるよなお前ら >>295
やだよ放射性廃棄物の後処理すんの
世に出して広めた奴が責任もって片付けろよ rustのポジションは他に居ないからありがたく使ってますけど >>294
じゃあ、かの有名なMicrosoftがRustを使っていれば貴方も使う気になるってわけですね
ttps://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of/
はい。これでめでたしめでたし
ところで、ドワンゴが例のRust製分散システムをオープンソースにしてた。
ttps://dwango.github.io/articles/frugalos/ >>296
じゃあ君は最初はバックがどうこう言ってたけど実はそんなこととは無関係に嫌ということかな? ただの廃棄物じゃなくて放射性廃棄物ってどういう比喩なのか
阿片みたいに観戦力があり周囲に広がるということ?
それとも単に処分に困るというだけ? 暗号通貨関連でよくRustが使われてるってホントなの? >>304
残念ながらC++, Java, Goと比べたらゴミカスや 家の非力なデスクトップにgentooを入れたんですが
firefoxをコンパイルしたらrustもコンパイルしてくれました
rustも含めて都合14時間かけてコンパイルしたfirefoxを使うだけじゃ勿体無いので
rustを勉強してみようと思ったのですが
スクリプト言語とjavaを触った程度の人が始めるには
ハードルが高い言語なんでしょうか?
何かとっかかりになる良いサイトとか本がありましたら
教えてくれると嬉しいです
Python歴7年Java歴2年の趣味プログラマです
rustでgtkアプリを作ってみたいです ヤル気はマンマンなんですが
まだgentooのインストール途中でxfceにfirefoxが入ってるだけなんですよね
帰宅したらvscodeも入ってるはずなので今夜からコンパイル流しながら勉強する予定です
ただ、あんまり初心者向けの日本語情報が見当たらない気がするので
いいサイトがあれば知りたいな、と思った次第です Azulとかどうよ
とりあえずサンプルビルドしたら普通に起動した 皆さんいろいろとありがとうございます
とりあえずプログラミング言語Rustの日本語訳pdfを見つけたので
それ見て勉強してみたいと思います
これ凄いですね
無料で配布しちゃって良いんでしょうか
下手なwebの情報探すより公式見たほうが良さそうですね Gitとは何かの説明まであって驚くよな
さすがにそのレベルの人は門前払いしたほうがその人のためにもいいと思うが >>316
あれはRust初心者だけでなくプログラミング初心者も対象としてるんじゃないの?
だから初歩的なところから教えてるんだろうと思っていたが
まぁ、プログラミング初心者がいきなりRustから始めるってどうなのよ?とは思うけど Cとかでメモリの扱いミスってしかも落ちずにおかしな動作する、みたいなのの経験がないとイマイチRustの有り難みは感じられないようなとも思いつつ
かといってRustのためにC勉強するってのもなんか本末転倒なきもするし なまじ他言語を知ってるから難しいという点もあるんじゃない
初心者がベテランが作るようなものをrustで書くのは辛いだろうけど、初心者が作るようなものを書く分にはむしろ易しい気がする
セットアップ楽だし Mozillaはドキュメント書くの得意だよな
オワコンブラウザには勿体無さすぎる才能 なぁに、まだまだこれから。
などという言葉が出始めたら終わりは近い。 書店でオライリーのRust本をパラパラと読んでみたけど
式の可読性の面ではC++の悪いところを引きずってるように思える try!(try!(try!(foo).bar()).baz()) とか? try!(try!(try!(try!(foo).bar()).baz()) とか) え?前なの?
手元の蟹本だと、
7.2.4節 エラーの伝搬に"?演算子"のこと書かれてるんだけど muslでビルドすると普通にlinuxでビルドしたときよりメモリ食うんだけどなんで? >>331
標準のライブラリだと、メモリ上にロード済みのコードを共有するからじゃないの? libcとかがダイナミックリンクじゃない分てことだよな
色々検証していたんだがそれだけじゃなくリークしてるように見える >>318
だがそれが一番の近道だよ。
結局 c -> c++ -> rust の順で学ばないと意味わからんだろう。 >>334
いやCはともかく少なくともC++は要らんだろ >>335
見てみたらリークはしてなかった
100mbくらいあるヒープに確保された値を1分に1度入れ替えているんだけど、ヒープに確保された領域って即解放されるわけではない? まだjemllocがデフォルトだけどナイトリーでは既に外されていて近々デフォルトではなくなる
それとは別の話で、俺がビルドしたのがmuslビルド用のdockerイメージで、それにはjemalloc入ってないからシステムアロケータで動いてたんだよね ■ このスレッドは過去ログ倉庫に格納されています