X

Rust part8

レス数が900を超えています。1000を超えると表示できなくなるよ。
0828デフォルトの名無しさん
垢版 |
2020/07/02(木) 00:00:35.12ID:53deMRLD
Result<T,E> を要素とするイテレータを Result<Vec<T>,E> にしたくて、
よくありそうなパターンだと思うんだけどさらっと上手くやる方法ってないもんかな？
0830デフォルトの名無しさん
垢版 |
2020/07/02(木) 01:46:12.20ID:T8l/o3UF
collect::<Result<Vec<_>, _>>()
0831デフォルトの名無しさん
垢版 |
2020/07/02(木) 10:10:47.16ID:O6Sxhm4J
毎回乱数使ってるなら画面更新するたびにハッシュ変わるはずだよね？
https://play.rust-lang.org/?code=%23!%5Ballow(unused)%5D%0Afn%20main()%20%7B%0Ause%20std%3A%3Acollections%3A%3Ahash_map%3A%3ADefaultHasher%3B%0Ause%20std%3A%3Ahash%3A%3AHasher%3B%0A%0Alet%20mut%20hasher%20%3D%20DefaultHasher%3A%3Anew()%3B%0Alet%20data%20%3D%20%5B0x01%2C%200x23%2C%200x45%2C%200x67%2C%200x89%2C%200xab%2C%200xcd%2C%200xef%5D%3B%0A%0Ahasher.write(%26data)%3B%0A%0Aprintln!(%22Hash%20is%20%7B%3Ax%7D!%22%2C%20hasher.finish())%3B%0A%7D&edition=2018
変わらないよ？
0832デフォルトの名無しさん
垢版 |
2020/07/02(木) 10:42:54.83ID:NJoiTLER
>>831
HashMapと同じことをしたいなら、RandomStateからbuild_hasherでhasherを得ればよい。別に画面更新しなくてもRUN押す度に変わるよ。
0833デフォルトの名無しさん
垢版 |
2020/07/02(木) 10:47:40.50ID:NJoiTLER
ちなみにDefaultHasher::newで変わらないのは、単に内部的にSipHasher13::new_with_keys(0,0)を呼んでるから。
RandomStateがその0,0をランダムに変えている。
0834デフォルトの名無しさん
垢版 |
2020/07/02(木) 12:36:00.56ID:2uT/XA4a
Hash値の計算そのものも、本当はかなり速度が求められるものなので、それを
自在に変えるというのはどうやっているのか興味が有る。
Hash値そのものの計算は、遅いわけではないが、それでも膨大なデータを処理する
場合には、その問題になることがある。
0835デフォルトの名無しさん
垢版 |
2020/07/02(木) 14:34:38.77ID:O6Sxhm4J
SipHasher13::new_with_keys(0,0)はソルト？シード？
0840デフォルトの名無しさん
垢版 |
2020/07/03(金) 01:32:48.51ID:A3vf6ary
>>839
FromIterator::from_iter呼んでる
From呼ばれるかどうかはFromIteratorの実相次第だけど
普通はIterator::Itemがそのままコレクションのデータ型になるから呼ばれないと思う
0841デフォルトの名無しさん
垢版 |
2020/07/04(土) 01:28:15.59ID:MbDjr1Zt
これがコンパイルエラーになる（sum::<i64>()としないといけない）のってなんでですか？
let s: i64 = (0i64..10).sum() + 10i64;

推論できる材料は十分に見えるんですけども

ちなみにこれなら通ります
let s: i64 = (0..10).sum();
0842デフォルトの名無しさん
垢版 |
2020/07/04(土) 07:36:29.64ID:mye4TJ7/
rangeはusizeだから
0845デフォルトの名無しさん
垢版 |
2020/07/05(日) 01:30:45.53ID:SD7XkwQZ
今までターボフィッシュで型指定しなくても動いてたものが
新しいimpl追加によって型指定がないと動かなくなるケースがあるというのは理解できる

ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね

//iter::Iterator::sum
fn sum<S>(self) -> S where Self: Sized, S: Sum<Self::Item>
{
Sum::sum(self)
}

//iter::Sum
pub trait Sum<A = Self>: Sized {
fn sum<I: Iterator<Item = A>>(iter: I) -> Self;
}
0846デフォルトの名無しさん
垢版 |
2020/07/05(日) 23:04:09.03ID:HzchPVMd
>>845
まず、

1) inference type（推論された型）と宣言時や実行時の型は別なんで、実行時の型はあくまで推論された型の外延でしかない。
すると、別の型互換のルール（たとえば、部分多相とか）がないと互換の型とみなせない。

2) 公開された部分を推論すると将来の変更で1)から互換性を失う場合がある。
最近型推論導入した言語が公開関数のシグネチャ等を推論しないのはこの問題が理由だと思う。

>ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
>各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね
これは単にメソッド呼び出しの生成規則:　expr0 ". " expr2　[Turbofish] "()"　のexpr0から推論しないルールが既にあるからできないだけじゃないの？
これを拡張すると2)から互換性を失う可能性がある。公開された型と関数のシグネチャに依存してるんで。
0848デフォルトの名無しさん
垢版 |
2020/07/09(木) 06:01:23.92ID:OnQC9Em2
Rustの構文を自分でPython風にしてるんだけど、このwhereのとこの構文がどうも末尾:と相性悪くてどうしたら綺麗になるか教えて欲しい。
問題点
* Self: Sizedの型指定の:と被る(引数の型はかっこに埋まってるからいい)
* 一行目の関数宣言の:があるのに二行目でもwhere使うために:がある(二行続くのは英文法的にもおかしい)
* whereの構文ルールが曖昧(改行入れたりできる) -> だから統一したい
fn sum<S>(self) -> S:
where Self: Sized, S: Sum<Self::Item>:
Sum::sum(self)
0849デフォルトの名無しさん
垢版 |
2020/07/09(木) 19:57:31.40ID:/c0BYhMm
Rust にトランスパイルされる Python 風構文の言語を作っているということかな？

fn sum<S>(self) -> S
where Self(Sized), S(Sum<Self::Item>):
Sum::sum(self)

こんな感じで class の継承っぽく書くのはいかが
0850デフォルトの名無しさん
垢版 |
2020/07/09(木) 20:52:03.73ID:OnQC9Em2
そう、そういう言語作ってる最中。
たしかにその構文もいいね！でもstruct S(i32);に見た目上だけど被るのと、トレイトのfn name<T: Num>とかも構文変える必要でてくるなぁ
個人的にはトレイトベースの言語だからT: Numは変えたくないだよね
こういうのもいいかも
fn sum<S>(self) -> S,
(Self: Sized, S: Sum<Self::Item>):

whereと同じような機能でしっくりくる構文持ってる他言語とかないのかなぁ
0852デフォルトの名無しさん
垢版 |
2020/07/11(土) 19:10:01.60ID:F8ozXmMr
Winrtよく知らないんだけどWindows環境でGUI簡単にいじれるようになったの？
0854デフォルトの名無しさん
垢版 |
2020/07/14(火) 15:40:35.77ID:GDMj7Uve
let delta = input[0] - input[1];
println!("{}{}", if delta == 0 { "" } else if delta > 0 { "-" } else { "+" }, delta.abs());
このif delta == 0 { "" } else if delta > 0 { "-" } else { "+" }の綺麗な順番とかの定石の書き方ってある？
0855デフォルトの名無しさん
垢版 |
2020/07/14(火) 16:21:46.36ID:0FZUPBc1
match delta.cmp(&0) {
std::cmp::Ordering::Equal => "",
std::cmp::Ordering::Greater => "-",
std::cmp::Ordering::Less => "+",
}
0856デフォルトの名無しさん
垢版 |
2020/07/14(火) 18:24:58.52ID:Ott4Q6kl
n == 0の時だけ記号なしにしてそれ以外は{:+}でフォーマット
(n > 0の時だけ{:+}にするのでも結果は同じ)
0857デフォルトの名無しさん
垢版 |
2020/07/14(火) 20:20:46.59ID:GDMj7Uve
>>855
>>856
ありがとう、両方いいね！
0859デフォルトの名無しさん
垢版 |
2020/07/15(水) 20:29:35.32ID:hr2ndtrb
両方有るってことはどっちにでも出来るってこった。
どちらかが良いなんてことはない。
0861デフォルトの名無しさん
垢版 |
2020/07/16(木) 01:35:03.21ID:ky3/glay
以下のコードでクロージャclの引数に型推論が効かないのってなんでですか？
fn main() {
let vv = vec![vec![1, 2, 3]; 4];
let cl = |a, b, c, d| vv[a][b] + vv[c][d];
//error[E0282]: type annotations needed
println!("{}", cl(3usize, 1usize, 2usize, 2usize))

}
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=a49b194930fcdfd894c2be4fc078be80

クロージャclの引数のところを |a: usize, b, c: usize, d| とすればコンパイルは通るのですが、aとcだけ型注釈が必要になるのも意味がわからないです
0862デフォルトの名無しさん
垢版 |
2020/07/16(木) 23:09:40.63ID:NQlI+enB
jsonをパースして、その中身に対して更に値を追加し
最後にはまたjsonでシリアライズということをやりたいのですが、
serdeだと事前に入力と出力の型を定義していないと難しいですか？

from_stringでValue型に入れて、mapのようにキー名で値を取れることは分かったのですが
そこに新たに値を追加する方法がわからないです
0863デフォルトの名無しさん
垢版 |
2020/07/16(木) 23:23:19.49ID:iYXNZZst
as_object_mut
あたりかな
0866デフォルトの名無しさん
垢版 |
2020/07/18(土) 18:30:51.49ID:XPr1Z8D3
神がついてるから大丈夫
0867デフォルトの名無しさん
垢版 |
2020/07/20(月) 13:18:08.21ID:8IyUCuKf
actix-wevからRocketに移行します
0869デフォルトの名無しさん
垢版 |
2020/07/21(火) 18:35:05.91ID:jydcaLWL
スライスから差集合を作るの際にスライスをそれぞれhashsetにしてdifference呼ぶ以外で良い書き方ありますか？
0871デフォルトの名無しさん
垢版 |
2020/07/22(水) 01:18:16.47ID:EHcGprvb
>>869
シンメトリックじゃない単なる差集合なら
片方だけsetにしてもう片方の要素でループしながらチェックするのでもいい気がする
あと状況によってはBroom filterみたいなのを使うと高速化できるかも
0872デフォルトの名無しさん
垢版 |
2020/07/22(水) 13:33:09.23ID:toRz6DNg
fn aaa(s: &str) {
if s == "aaa" {
compile_error!(r"If s is "aaa", compile error!");

}
}
fn main() {
// compile error!
aaa("aaa");
// can compile
aaa("aaaaaaaa");
}

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
0873デフォルトの名無しさん
垢版 |
2020/07/22(水) 13:33:41.15ID:toRz6DNg
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
↓
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルエラーになるんだけど回避方法ってないかな
0876デフォルトの名無しさん
垢版 |
2020/07/22(水) 15:58:57.61ID:6Pdi74ki
aaa(r#"aaa"iiii"uuuuu"#)
0877デフォルトの名無しさん
垢版 |
2020/07/22(水) 16:04:28.78ID:toRz6DNg
>>875
ごめん。ここに貼る用のデバッグコメ。
そこ直したら本題の条件分岐のコンパイルエラーにならないのがでてくる
compile_error!(r#"If s is "aaa", compile error!"#);
0878デフォルトの名無しさん
垢版 |
2020/07/22(水) 18:44:16.24ID:EHcGprvb
compile_error!は条件付きコンパイルかマクロでしか使えないんじゃ？
compile_error!と記述してる行がコンパイルするコードに含まれることになったらコンパイルエラー

マクロを展開する段階では変数の値を評価できないから
文字列を受け取る関数に対して特定の文字列を渡すコードがあったらコンパイルエラーってのは無理な気がする
0880デフォルトの名無しさん
垢版 |
2020/07/23(木) 01:38:31.65ID:es6swX3J
最近RustのSlackでも出てきた福野泰介ってやつ声でかいよな
こいつどのコミュニティでも何かしら主張して目障りだわ
0881デフォルトの名無しさん
垢版 |
2020/07/23(木) 01:41:56.15ID:5yzO6ql9
Ubuntu Japanese Team に言いつけて潰してもらおうぜ
0882デフォルトの名無しさん
垢版 |
2020/07/23(木) 18:56:28.53ID:Qx3jp5Nz
環境はMacOS Catalina, Rustは1.45.0です
今弄ってる物(https://github.com/Nercury/rust-and-opengl-lessons)で
/lib/gl/src/lib.rs内に
include!(concat!(env!("OUT_DIR"), "/binding.rs"));
というのがあるのですがですがcargo buildすると
this error originates in a macro
error: couldn't read /Users/Path/target/debug/build/gl-71effbf83f5b03a9/out/binding.rs: No such file or directory (os error 2)
と表示されます
https://github.com/rust-analyzer/rust-analyzer/issues/1964
https://github.com/rust-skia/rust-skia/issues/10
などを見たのですが具体的な修正がわかりませんでした。
Rustは最近始めたばかりでincludeマクロやcargoの仕組みなどまだあまり詳しくありません
このinclude!を成功させる方法を教えてください
迷惑をかけてしまうかもしれませんがご教授お願いします
0883デフォルトの名無しさん
垢版 |
2020/07/23(木) 19:05:44.31ID:es6swX3J
福野泰介はたしかにどこでも目立つ。
自己顕示欲もあそこまでいったら面白い、反面教師として役立つ
0884デフォルトの名無しさん
垢版 |
2020/07/23(木) 21:20:06.43ID:DkkvFejZ
>>882
lib/gl/build.rsでOUT_DIRにbinding.rsを作成してる

ビルドスクリプトが意図した通りに動いているのか確認するために
build.rsを変更してbinding.rsのフルパスをprintlnでもするようにして
cargo build -vvしてみるといいと思う

ビルドスクリプトについて詳細知りたければこの辺読んで
https://doc.rust-lang.org/cargo/reference/build-script-examples.html
0885デフォルトの名無しさん
垢版 |
2020/07/24(金) 00:48:59.83ID:j+hLU6yH
>>884
ありがとうございます動きました！
非常に長文だった自覚はあるんですが分かりやすくすっきりした回答ありがとうございますm(_ _)m
0886デフォルトの名無しさん
垢版 |
2020/07/24(金) 10:22:52.41ID:c87Ipt6p
同じサーバー内でポート別にクライアント用サーバー(Nuxt)とAPI用サーバー(Rust)立ち上げるのってどう思う？
クライアント用サーバーは初回しか性能響かないからあれだけど、Rustの方が断然速いし、SPAだからルートの設定も全然しなくていいし、Rustの方でフロントページも返した方がいいんじゃないかと思ってるんだけども
要はRustを実行すればポート別に２つサーバーが立ち上がるようにするってこと
0888デフォルトの名無しさん
垢版 |
2020/07/26(日) 03:19:09.22ID:XCGG5OQ8
diesel使いづらくない？
0889デフォルトの名無しさん
垢版 |
2020/07/26(日) 18:57:03.68ID:uWZribv0
rustcの-C llvm-args=が取り得るオプションの説明ってどこかに書いてある？
clangのttps://clang.llvm.org/docs/ClangCommandLineReference.html#x86
あたりがそれっぽいけど説明が全くないのでデフォルト値も効果もよく判らない
0891デフォルトの名無しさん
垢版 |
2020/07/26(日) 23:02:23.88ID:XCGG5OQ8
あるモジュールクラスを別のモジュールで使いたい場合ってどう宣言するのが正しいの？

正直ドキュメント読んでも分からん
0892デフォルトの名無しさん
垢版 |
2020/07/26(日) 23:58:47.45ID:uWZribv0
>>890
サンキュ。そう使うのかよｗ　うちの環境では
>rustc -C llvm-args=--help　←'を付けると怒られる
でそれっぽいのが得られました。amd64で使用命令を選択するようなオプションは無いのか・・・
0893デフォルトの名無しさん
垢版 |
2020/07/27(月) 00:46:16.95ID:TQCIWmFu
--helpの最後に出てたけど
利用可能なオプションを全部表示するには
llvm-args=--help-hiddenってするみたい
0895デフォルトの名無しさん
垢版 |
2020/07/27(月) 10:10:01.73ID:0SvTsOI7
>>894
そもそもnext_monthに何を期待するかによると思うが。30日後？31日後？翌月の同じ日？それが存在しない場合は？とか。その辺がはっきりすれば、その通りに実装すればいい。
0897デフォルトの名無しさん
垢版 |
2020/07/27(月) 16:16:44.20ID:s6eJseAH
>>896
ありがとう、結局next_month自分で実装したけど、かなり頻繁に使われる類のメソッドだから正直きついな
with_monthもoptionで返すから31 -> 30の次月遷移したとしても安全だから実装しない理由が分かんないな
chronoは変なとこには手回ってるしよくわからん
0899デフォルトの名無しさん
垢版 |
2020/07/28(火) 16:26:39.82ID:0KPYC4VC
>>891
じけつ

main.rsでそれぞれのモジュールをmod宣言
0900デフォルトの名無しさん
垢版 |
2020/07/29(水) 11:56:30.09ID:blHj/j43
ed25519の公開鍵のssh-ed25519 ******の部分が欲しくて、ed25519_dalekっていうクレートで鍵作ってるんだけどPublicKey構造体のas_bytesでとってくるバイト列をstr::from_utf8でしてもエラーが出て秘密鍵の***部分にならないんだけど、どうすればいいか分かる？
https://docs.rs/ed25519-dalek/1.0.0-pre.4/ed25519_dalek/struct.PublicKey.html
0902デフォルトの名無しさん
垢版 |
2020/07/29(水) 21:31:44.28ID:4K5iZ0U7
>>900
str::from_utf8でエラーになるのは
0~127までのUTF-8互換のASCII以外の文字が含まれてるからでは？

pemで見れる公開鍵のssh-ed25519 ******の部分は
keyの種別とDERエンコードしたkeyの値をBase64にしたものらしい
0903デフォルトの名無しさん
垢版 |
2020/07/30(木) 13:54:57.65ID:AECjseqQ
>>901
やってみたらエラーはでないし、ハッシュっぽいものできたけど、大文字ないから >>902の方法っぽいかも
4ef6dcfda191770b64939c5657fc26e631c2caffa18e423c397d761d507ae82a%

>>902
ありがとう、やってみるわ
0904デフォルトの名無しさん
垢版 |
2020/07/31(金) 22:54:06.06ID:Emo7hM/W
bindgenにwindowsはllvmのプリビルドバイナリをインストールしなさいと書いてあるけど、
LIBCLANG_PATH設定し忘れるとwinのプリビルドバイナリには含まれてないllvm-configを使って<LLVM_ROOT>/binまでのパスを探すんで
llvm-configがないって怒られる罠がある。

LIBCLANG_PATHタイポして時間潰してしまった。
0905デフォルトの名無しさん
垢版 |
2020/08/01(土) 14:02:57.08ID:cK8sGWsa
やっぱactixよりrocketだな
0908デフォルトの名無しさん
垢版 |
2020/08/01(土) 15:19:22.53ID:cK8sGWsa
>>906
ドキュメントがしっかりしてそう
0910デフォルトの名無しさん
垢版 |
2020/08/01(土) 22:13:51.53ID:cK8sGWsa
rocketってmultipartサポートしてないのか
0911小石茶輝
垢版 |
2020/08/01(土) 23:31:58.80ID:hdo7vbOv
unsafe という機能があるのは unsafe が必要だからです。
設計方針に対して必要以上に unsafe があるのはダメですが、
少なければ少ないほど良いというわけでもありません。

たとえば C++ を使っているときだって、
グラフィックドライバを書くときとかは
どうしたって (C++ 的には) 行儀の悪い書き方になってしまうでしょう。

行儀の悪い部分はなるべく低レイヤに押し込めて、
ロジック層が綺麗になるようにするのが望ましいなどといった習慣はありますが、
どの程度にするかの程度問題は設計方針によります。

actix は rocket よりも unsafe を多用してはいますが、
意図のはっきりした unsafe です。

あまりにも unsafe が多すぎるならもう Rust 使うのやめろよと思うかもしれませんが、
行儀の悪い書き方 (unsafe) がより明示的であるというだけでも
C++ よりは少しマシでしょう。
0913小石茶輝
垢版 |
2020/08/06(木) 23:35:19.16ID:m6Z7F3X/
出てますよ。
あなたがそれをキャッチする立場にないだけです。
0914デフォルトの名無しさん
垢版 |
2020/08/08(土) 01:19:04.76ID:4kKr75Ow
stdの中でこれは外部ライブラリにした方がいいんじゃないかなって思うやつある？
逆に外部ライブラリからstdにした方がいいんじゃないかってやつとかもある？
0916デフォルトの名無しさん
垢版 |
2020/08/09(日) 00:20:40.65ID:ayHdPpdd
乱数は用途によって必要な性質が色々だからなぁ。
どの分野を優遇すべきかってのは自明ではないでしょ。
全部盛りにするのも Rust 的ではないし。

でも、どの乱数ライブラリを使うにしても同じようなインターフェイスだとありがたいので、
乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
そのサンプル的な位置づけでひとつくらいは乱数ライブラリが入っていてもいいかなとは思う。
0918はちみつ餃子 ◆8X2XSCHEME
垢版 |
2020/08/09(日) 00:43:58.48ID:ayHdPpdd
>>917
メルセンヌツイスタは統計的な性質は良いけど暗号的には使い物にならんしデカい。
常にベストと言えるほど良い選択ではないよ。
0919◆QZaw55cn4c
垢版 |
2020/08/09(日) 01:29:16.04ID:DQUuTCyR
>>918
確かに暗号にMTを使うのはダメですね、暗号用には crypt-MT がありますね
0920デフォルトの名無しさん
垢版 |
2020/08/09(日) 20:40:18.77ID:mU0jSAp3
今はもうMTもそこまで・・・って話じゃないっけ
randクレート見るとそんなこと書いてあったような
0921デフォルトの名無しさん
垢版 |
2020/08/09(日) 20:55:04.69ID:wx6Xp3NP
他の言語だって完璧な乱数だと思ってなくても
利用者の利便性を考えて標準ライブラリに含めてるんだろ
それが無いRustは変
0922デフォルトの名無しさん
垢版 |
2020/08/10(月) 00:22:38.94ID://dLtD59
今どきMT法なんか使わん。

>乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
rand_coreがそれに当たるけどcoreだけだとバイト配列しか取得できんので分布器に生成器渡せん。
未知の生成器の実装すべて含めるのは無理、既知のものに絞っても要求する特性が人によって違うから標準にするのは無理。
結局はこうなるが、俺も標準ライブラリに乱数ほしい。
0923デフォルトの名無しさん
垢版 |
2020/08/10(月) 01:32:59.38ID:5CSXOdci
cargo使ってるから別ライブラリでもあまり困らない
こと乱数に関してはデファクトスタンダードのcraete決まってるし迷うことないしね
標準ライブラリに入ってて欲しいのは初学者がcrate知らないとか探すのが手間だとか、コンパイルタイムが延びるのが嫌だとか、そういう理由？
0924デフォルトの名無しさん
垢版 |
2020/08/10(月) 02:16:28.69ID:PbB9rIkO
stdに入れて欲しいのはrandよりregexだな
標準ライブラリとして責任もってメンテされていくものなのかどうかが重要
0926デフォルトの名無しさん
垢版 |
2020/08/10(月) 04:22:44.62ID:qbs6FNC5
Authors のところが The Rust Project Developers ってなってるやつは
事実上の標準みたいなもんと思ってええんけ？
将来の互換性が保証されるかどうかはともかくとして Rust と足並みがそろっているとは
思っていいよね？
レス数が900を超えています。1000を超えると表示できなくなるよ。