|
Walh Hara posted:So, I'm an idiot and need help. I don't even know what syntax you're trying to use, but it looks like you're declaring the type of `cells` as a slice of 64 `ChessCell`s. Despite that, you're not declaring the value. Add `= []`.
|
# ? Mar 30, 2018 00:46 |
|
|
# ? May 16, 2024 17:17 |
|
Eela6 posted:You've only declared the identifier, not initialized it. Unlike go, rust doesn't assume a default value for an identifier with a type but no initializer. I already knew this, but this seems extremely dumb to me? Do I really need to fill the array with garbage (when I declare the variable) so I can replace this garbage in the for loop with the correct values? I was assuming there must a be better way. Or should you just never use arrays when working with objects? quote:I don't even know what syntax you're trying to use, but it looks like you're declaring the type of `cells` as a slice of 64 `ChessCell`s. Despite that, you're not declaring the value. Add `= []`. That doesn't work.
|
# ? Mar 30, 2018 01:08 |
Walh Hara posted:I already knew this, but this seems extremely dumb to me? Do I really need to fill the array with garbage (when I declare the variable) so I can replace this garbage in the for loop with the correct values? I was assuming there must a be better way. You're going to do that no matter what, because otherwise your array might use uninitialized memory with arbitrary contents. Generaly speaking, Rust's compiler is smart enough to figure out what you mean, and will skip the 'useless' allocations if your inbetween steps don't affect anything else . You can also use Vec::with_capacity(64) and then convert to an array, as you've mentioned. I've constructed an example of working with arrays of non-primitive types that might help you. I don't know the details of your types, so it's hard to give more detailed help.
|
|
# ? Mar 30, 2018 01:48 |
Walh Hara posted:I already knew this, but this seems extremely dumb to me? Do I really need to fill the array with garbage (when I declare the variable) so I can replace this garbage in the for loop with the correct values? I was assuming there must a be better way. You have a few options. Off the top of my head:
Personally, I'd go with the 3rd option. If you want to see what this looks like in practice, or if you want to play around with it, I wrote up some prototypes on the Rust playground.
|
|
# ? Mar 30, 2018 02:19 |
|
Walh Hara posted:I already knew this, but this seems extremely dumb to me? Do I really need to fill the array with garbage (when I declare the variable) so I can replace this garbage in the for loop with the correct values? I was assuming there must a be better way. tazjin posted:I've spent the last two evenings looking at how to migrate a reasonably complex Rust system from error_chain to the new failure crate. Personally, I'm a fan of using .context(...) heavily because it lets you provide informative error messages; if your program does a bunch of IO, a simple "permission denied" error message can be incredibly unhelpful compared to, say, "couldn't open config file /foo/bar: permission denied". You don't necessarily need to scatter these all over your code, though, just at major boundaries.
|
# ? Mar 30, 2018 02:27 |
|
“What does the profiler say?”
|
# ? Mar 30, 2018 02:31 |
|
Ralith posted:Using failure doesn't mean you need to use failure::Error at all; that's expressly the lazy shortcut approach. Instead, you can define your own Error type, derive Fail for it, and implement From<ForeignError> for whatever errors you want to support. There's been some discussion on whether this exact pattern is actually a good idea, but it is certainly still supported. Something like implementing From<ForeignError> for our error types is probably what we'll do if we end up using failure. May in that case even make a macro implementing error_chain's foreign_links functionality for failure. The fact that failure promotes at least three different ways to use its own error types is also going to be annoying in the future, because crate authors will not do it consistently and suddenly the quality of errors from foreign code will have an additional dimension of "Oh no" to it. Ralith posted:Personally, I'm a fan of using .context(...) heavily because it lets you provide informative error messages; if your program does a bunch of IO, a simple "permission denied" error message can be incredibly unhelpful compared to, say, "couldn't open config file /foo/bar: permission denied". You don't necessarily need to scatter these all over your code, though, just at major boundaries. There's an example somewhere in the docs of failure in which .context(...) is used to add the string "file not found" to an IO-error, but it is in a situation where the error may just as well be something else - like "permission denied". This leads to a similar issue as people encounter in Go: Layers of misleading error messages, concatenated together, because some programmer thought they could enumerate the possible errors at the point where they provided "context" in their head.
|
# ? Mar 30, 2018 09:58 |
|
Thanks for the explanations everyone.
|
# ? Mar 30, 2018 11:05 |
|
tazjin posted:There's an example somewhere in the docs of failure in which .context(...) is used to add the string "file not found" to an IO-error, but it is in a situation where the error may just as well be something else - like "permission denied".
|
# ? Mar 30, 2018 21:47 |
|
Is there a guide anywhere on downloading crates manually? The firewall at work basically makes cargo unusable, it can't even get the index
|
# ? Apr 6, 2018 21:42 |
|
You can just clone the repository or download the zip from crates.io, place it in a folder called "vendor" and use a path dependency. All crates.io really is is a collection of crate zips with some heuristics about which versions are allowed to be used as dependencies. Linear Zoetrope fucked around with this message at 21:50 on Apr 6, 2018 |
# ? Apr 6, 2018 21:47 |
|
Ok between that and the documentation I think I understand. Thanks
|
# ? Apr 7, 2018 00:43 |
|
HappyHippo posted:Ok between that and the documentation I think I understand. Thanks
|
# ? Apr 7, 2018 05:29 |
|
I saw an awesome svg chart today showing graphically what happens to variables when they are borrowed and I think it would be neat to have something that parses your code and shows borrows, moves, copiers and lifetimes graphically.
|
# ? Apr 10, 2018 22:29 |
|
https://hacks.mozilla.org/2018/04/hello-wasm-pack/ Packaging Rust crates as WebAssembly and publishing them to NPM to be consumed by JS. So the future of the web is moving libraries to Wasm and Rust, and keeping a scripting layer on top for UI and business logic? So like a C-Lua kind of setup. I could get behind that.
|
# ? Apr 18, 2018 20:01 |
|
The future of the Web is a garbage can
xtal fucked around with this message at 22:55 on Apr 18, 2018 |
# ? Apr 18, 2018 22:33 |
|
Yo bros. Trying to do some matrix mult; ref the thread's title. Any wisdom from bros on how to make it compile?Rust code:
code:
code:
Dominoes fucked around with this message at 04:48 on Apr 22, 2018 |
# ? Apr 22, 2018 04:39 |
Dominoes posted:Yo bros. Trying to do some matrix mult; ref the thread's title. Any wisdom from bros on how to make it compile? I don't have a lot of experience with the ndarray crate, but it looks like dot() takes its argument by reference. So try putting an & in front of the array![...] in the definition of f? If the borrow checker gives you crap about that value not living long enough, take the argument to dot() and give it its own let binding. Whenever I get errors about the expected type of an argument, I always go and double check exactly what that argument is expecting and the type of what I'm giving it, and usually that solves it.
|
|
# ? Apr 22, 2018 04:52 |
|
Thanks for looking at it dude. getting this now:code:
code:
code:
Dominoes fucked around with this message at 05:03 on Apr 22, 2018 |
# ? Apr 22, 2018 04:57 |
|
Dudes; got it to compile; I'lll post what happened if you like, but I have no idea and don't think it'll be useful since I just moved &s around rando until it worked.
|
# ? Apr 22, 2018 05:08 |
Dominoes posted:I just moved &s around rando until it worked. Now you are programming like a true Rust expert! e: seriously though congrats on getting it to compile! It'll (mostly) click soon, don't worry.
|
|
# ? Apr 22, 2018 05:17 |
|
Also don't feel bad because ndarray is really finnicky and not exactly the most ergonomic crate. Rust's type system isn't really built to handle the sorts of things mathematical crates really need right now, and they're not going to be worked on much until next year (given the roadmap and me asking the Rust team about future goals). They're blocked on a few things like type-level numerics.
|
# ? Apr 22, 2018 10:56 |
|
I got it working with (ignore the type annotations, they're not needed)code:
1) the array! macro in f needs its arguments to NOT be references (it's an array of floats, not an array of references to floats). Note that you copy d's members here for that to be the case. 2) the argument to dot always needs to be a reference (that's how it's defined, so that you don't need to copy or own stuff), 3) the arguments to subtract need to both be references since they both come from the borrowed function parameters. You could instead do "D.dot(&(node.a.clone() - cam.c.clone())) OR make the function own its arguments like "fn project(cam: Camera, node: Node)" if you don't use them again after passing to this function. I think ".map(move |node| project(camera, node)).collect()" would let you make this function take its arguments by value if you don't use the camera anywhere else. In short ndarray wants everything by reference except when constructing an array initially. This is done because ideally you want each float to be allocated once somewhere and then manipulated with read-only references. Doesn't make much difference for f64's but would with bigger types.
|
# ? Apr 22, 2018 17:14 |
|
Thank you - that helps a lot!
|
# ? Apr 23, 2018 02:18 |
|
Any advice on separating dependencies for WASM and binaries? I have a project that both runs locally with main.rs, and can be used as a library for WASM/JS using lib.rs. When I try to compile WASM, one or more of the dependencies that I need to run locally, but not web, prevents the WASM compilation. If I remove the crashing lib from Cargo.TOML temporarily, main.rs can't find it, which then prevents the compile. It appears that renaming main.rs, and commenting out the failing dependency works. Is there a more elegant solution? How would you handle this? Dominoes fucked around with this message at 10:34 on May 21, 2018 |
# ? May 21, 2018 10:20 |
|
You can specify dependencies as optional based on an arbitrary cfg. So in your Cargo.toml code:
|
# ? May 21, 2018 11:35 |
|
Dominoes posted:Any advice on separating dependencies for WASM and binaries? I have a project that both runs locally with main.rs, and can be used as a library for WASM/JS using lib.rs. When I try to compile WASM, one or more of the dependencies that I need to run locally, but not web, prevents the WASM compilation. If I remove the crashing lib from Cargo.TOML temporarily, main.rs can't find it, which then prevents the compile. It appears that renaming main.rs, and commenting out the failing dependency works. Is there a more elegant solution? Another option would be to split the main.rs file into a tiny new crate - you have a library that works with both and a binary that only works locally. If you make one crate that's only the library and one that's only the binary then you stop mixing up your concerns. There are two downsides: more boilerplate since you now have two crates to maintain, and your main now can't access internal stuff from the lib.
|
# ? May 21, 2018 13:11 |
|
Nailed it. Went with the specify-dependencies approach for now; may switch to the separate lib approach later.
|
# ? May 21, 2018 20:58 |
|
Another one: Is there a way to make Rust's wasm-bindgen work with types other than basic numbers/string, and ones you created in your code? Eg, I can make it accept custom structs with the #[wasm_bindgen] macro, but unable to apply it to say, a HashMap from the standard library, or an Array from the ndarray crate.
Dominoes fucked around with this message at 23:43 on May 21, 2018 |
# ? May 21, 2018 23:38 |
|
Yeah, if you enable the "serde-serialize" feature in wasm-bindgen then you can pass anything that serde can serialize to JSON across the WASM boundary. For example you can docode:
|
# ? May 22, 2018 00:08 |
|
Thanks; works!
|
# ? May 23, 2018 20:41 |
|
Blugh, the RLS being borked is killing me right now. Can't use old versions because I migrated to some 1.26 features.
|
# ? May 24, 2018 02:36 |
|
Linear Zoetrope posted:Blugh, the RLS being borked is killing me right now. Can't use old versions because I migrated to some 1.26 features. Use intellij with its builtin rust support, the RLS was never good. Maybe in the future it will be.
|
# ? May 24, 2018 20:57 |
|
Just started learning rust and making crappy little programs to test things. The scala in me wanted to write the following and I wanted to check my understanding of the problem is correct:code:
|
# ? May 31, 2018 13:02 |
|
I think in this case it doesn't matter that it's in the heap, just that you have references with a lifetime bound to a local in the closure, so they aren't allowed to escape the closure.
|
# ? May 31, 2018 13:10 |
|
yeah, what you want in this case is split_off, which returns owned strings
|
# ? May 31, 2018 20:02 |
This is a fun bit of obfuscated rust from reddit:code:
|
|
# ? Jun 7, 2018 03:05 |
|
VikingofRock posted:This is a fun bit of obfuscated rust from reddit: As with most code like this, it's easier if you add some whitespace, in which case you can start picking at pieces very easily. I wrote an explanation/my notes while deciphering here. Turns out I got it right!: https://gist.github.com/LinearZoetrope/7e1cf85c74ef4ce813331336fc628593 The part that was surprising to me was that __ is a valid variable name, I knew The Range variants were a structs, but not that they had no restrictions on their input.
|
# ? Jun 7, 2018 05:34 |
|
Where can I easily figure out the current status for hyper/tokio/reqwest/async/await and best practices? I just want to make an asynchronous HTTP call to something and unstable features / allowing warnings for this simple use case seem kind of annoying: https://github.com/seanmonstar/reqwest/blob/f48ec85b3c84d24235233875d66a76e3419338a8/examples/async.rs The Rust Cookbook also uses reqwest for its examples, and I see mention that reqwest provides a simple abstraction on top of hyper, but the examples look identical. Why should I be using reqwest? At this point it almost feels like I should just use some synchronous hyper and move on, since this isn't a super performance critical application.
|
# ? Sep 9, 2018 18:00 |
|
|
# ? May 16, 2024 17:17 |
|
Helicity posted:Where can I easily figure out the current status for hyper/tokio/reqwest/async/await and best practices? I just want to make an asynchronous HTTP call to something and unstable features / allowing warnings for this simple use case seem kind of annoying: I think all of those things are just on the cusp of being usable. You probably want to wait a while or just use sync hyper for now.
|
# ? Sep 9, 2018 18:12 |