Speaking of traits, I've defined this type 'Skeleton' which I'm using as the "parent". code:
code:
Problem is the load() method should be returning a physical item, and I think for a trait object to be instanced it needs &self in all the methods. As a workaround, I'll probably get rid of the trait and just have a single skeleton type with a bunch of loaders. Still, it would be nice in future development to know how to do this.
|
|
# ? Nov 2, 2016 06:00 |
|
|
# ? Jun 3, 2024 22:28 |
|
Jo posted:Speaking of traits, I've defined this type 'Skeleton' which I'm using as the "parent". code:
Ralith fucked around with this message at 06:05 on Nov 2, 2016 |
# ? Nov 2, 2016 06:02 |
Ralith posted:I think you want Aha! Yes! That seems to have done it! Thanks!
|
|
# ? Nov 2, 2016 06:24 |
|
There's also work being done (still pre nightly afaik) on a new feature impl Trait so you can have a function return specifying any type with the trait. I hadn't heard of it until I read this but it seems cool and good to me not really applicable to your problem, but it's in the pipeline.
|
# ? Nov 3, 2016 07:17 |
|
impl Trait is awesome, yeah, and a must for doing fancy combinator stuff without heap allocation, the possibility of which is one of the things that makes rust really stand out (although a single allocation per Future created across function boundaries isn't a big deal most of the time). The current implementation has some weird type inference limitations compared to Box<Trait>, but hopefully those will be addressed.
|
# ? Nov 3, 2016 07:47 |
impl Trait looks pretty goddamn good. I could have used that a few months back with my compute graph implementation. Would probably have let me split up my node type a lot.
|
|
# ? Nov 4, 2016 00:50 |
|
Yeah, it would have solved a problem I had before, where something expected a T: FnMut(..), but I had no way to return anything but a Box<FnMut(..)> to pass up to that. (But come to think of it, maybe I could have passed a wrapper of the boxed function?) But now you won't get successively deep wrappers of stuff like that.
|
# ? Nov 11, 2016 19:17 |
|
I haven't played with it yet, but 1.13 for anyone who missed it. the ? operator is pretty slick versus try!s everywhere imo. i also just like bumping this thread cause rust rules
|
# ? Nov 12, 2016 18:08 |
|
In the spirit of thread bumps, lately I've been playing with error-chain. It seems like a real improvement over error handling in other languages. I replaced a bunch of "log a descriptive error message, then return an Err" code with "return an error with the descriptive message chained on to it" and my code became significantly more concise, and now I just have a single ten-line block in my main function that pretty-prints a log message for the entire logical chain of failures of anything that makes it that far unhandled, followed by a (runtime-optional) physical stack trace describing where the error came from. The macro for defining all the usual error boilerplate is pretty nice, too.
|
# ? Nov 12, 2016 19:53 |
|
Hell yeah hkt will come so we don't need these ad-hoc monads cluttering up the language
|
# ? Nov 12, 2016 19:56 |
|
What is everyone using for Rust dev in terms of IDE-like capabilities? I'd like to start looking at Rust more and I develop on both Windows and OSX machines. I see that there are Atom plugins, SublimeText plugins, VS Code plugins, and IntelliJ plugins. Which of these are the most mature and actively developed and supported? Is there any thing I'm missing? I use vim too but primarily on OSX. Thanks.
|
# ? Nov 12, 2016 20:41 |
|
I use the VS Code plugins, which work quite well. The Sublime ones were really buggy when I used them (which wasn't that long ago), they would occasionally save hundreds of temp files in your source directory. There are Eclipse and Visual Studio ones too that support debugger functionality, but I had trouble getting the Eclipse one to work and the Visual Studio one is garbage (doesn't support Cargo, for one).
|
# ? Nov 12, 2016 20:47 |
|
xgalaxy posted:What is everyone using for Rust dev in terms of IDE-like capabilities? I'd like to start looking at Rust more and I develop on both Windows and OSX machines. I see that there are Atom plugins, SublimeText plugins, VS Code plugins, and IntelliJ plugins. Which of these are the most mature and actively developed and supported? Is there any thing I'm missing? I use vim too but primarily on OSX. The IntelliJ plugin is very good. Also Rust Language Server (https://internals.rust-lang.org/t/introducing-rust-language-server-source-release/4209) is promising.
|
# ? Nov 12, 2016 20:53 |
|
xgalaxy posted:What is everyone using for Rust dev in terms of IDE-like capabilities? I'd like to start looking at Rust more and I develop on both Windows and OSX machines. I see that there are Atom plugins, SublimeText plugins, VS Code plugins, and IntelliJ plugins. Which of these are the most mature and actively developed and supported? Is there any thing I'm missing? I use vim too but primarily on OSX. From what I've heard, the plugins for VS Code or IntelliJ are probably the best out there in terms of currently-stable IDE-like experiences. The Rust Language Server (linked above) is currently being worked on and from what I can tell it can allow a really nice IDE experience. If you're willing to put your code at the mercy of alpha-level software, it already looks promising. As far as what to avoid, I've seen multiple people on IRC come in where some Atom plugin messes with their target directory and makes them rebuild all their dependencies all the time. The basic syntax-highlighting one is probably fine, but if you go into the more IDE-like ones you might run into that issue. (I personally just use vim without even auto-complete and haven't run a debugger over my code so I wouldn't know from personal experience. I'm just relaying what I've heard about on IRC and around the community.) bobthenameless posted:I haven't played with it yet, but 1.13 for anyone who missed it. the ? operator is pretty slick versus try!s everywhere imo. 1.13 gave my library a notable compile-time improvement; whatever they're doing with the compiler optimizations is doing something right.
|
# ? Nov 13, 2016 01:20 |
|
The ? thing is pretty cool and in general I'm a fan of the explicit Result<> returning, but actually creating a ~good~ error enum or w/e still seems like a lot of pain. Maybe I should just use Strings as errors.
|
# ? Nov 13, 2016 02:35 |
|
Vanadium posted:The ? thing is pretty cool and in general I'm a fan of the explicit Result<> returning, but actually creating a ~good~ error enum or w/e still seems like a lot of pain. Maybe I should just use Strings as errors. Ralith posted:In the spirit of thread bumps, lately I've been playing with error-chain. It seems like a real improvement over error handling in other languages. I replaced a bunch of "log a descriptive error message, then return an Err" code with "return an error with the descriptive message chained on to it" and my code became significantly more concise, and now I just have a single ten-line block in my main function that pretty-prints a log message for the entire logical chain of failures of anything that makes it that far unhandled, followed by a (runtime-optional) physical stack trace describing where the error came from. The macro for defining all the usual error boilerplate is pretty nice, too.
|
# ? Nov 13, 2016 07:55 |
|
Do you wanna post your code? I mean I've looked at a few of that sorta crate and I still end up getting a bit of a headache each time I think about what type of error I should return and how to structure them.
|
# ? Nov 13, 2016 13:38 |
|
Here's what I use:code:
|
# ? Nov 13, 2016 13:47 |
|
Vanadium posted:Do you wanna post your code? I mean I've looked at a few of that sorta crate and I still end up getting a bit of a headache each time I think about what type of error I should return and how to structure them. Sure. Here's an error module that just wraps multiple other error types: Rust code:
Rust code:
Ralith fucked around with this message at 19:41 on Nov 13, 2016 |
# ? Nov 13, 2016 19:39 |
|
Has anyone tried compiling into Web Assembly from Rust? I tried a Hello World, but the compile time was quite long. I guess there's just too many stages in the pipeline right now? Also holy poo poo emscripten/LLVM took forever to build. Is that typical for large C++ projects?
|
# ? Nov 20, 2016 23:07 |
|
Redmark posted:Also holy poo poo emscripten/LLVM took forever to build. Is that typical for large C++ projects?
|
# ? Nov 21, 2016 01:29 |
|
The author of error-chain has posted a nice introduction to the newest release which reveals that my use of foreign_links above was somewhat less than idiomatic and makes a better case for why it's worth using beyond saving boilerplate.
|
# ? Dec 1, 2016 23:13 |
|
Ralith posted:The author of error-chain has posted a nice introduction to the newest release which reveals that my use of foreign_links above was somewhat less than idiomatic and makes a better case for why it's worth using beyond saving boilerplate. Oh wow, this is so cool.
|
# ? Dec 2, 2016 03:05 |
|
I love that post, brson owns.
|
# ? Dec 3, 2016 13:23 |
|
Speaking of error-chain, I started using the rust SDL 2 library, which returns some errors as Result<_, String>. What's the most idiomatic way of dealing with those? They work fine by themselves, but I'd like to chain_err them.
|
# ? Dec 6, 2016 05:25 |
|
You can chain_err any Result type if you have the symbols from a module containing an error_chain! invocation in scope. The method comes from a macro-generated ResultExt trait, and it returns the type of Result defined by that macro. For simple command-line tools, I often just have "error_chain! {}" at the top of the file so I can provide nice detailed information-preserving textual error messages everywhere.
|
# ? Dec 9, 2016 02:22 |
|
It's saying that the Err type of Result needs to implement error::Error, though. I have an error module available, and I can chain_err on other Results as long as their Err implements error::Error. It's just the ones that return Strings instead of real errors that are causing problems. e: For reference, just in case I'm being real stupid, here's some code that runs into this: code:
code:
Asymmetrikon fucked around with this message at 02:38 on Dec 9, 2016 |
# ? Dec 9, 2016 02:29 |
|
Ah, right. An easy solution would be to define a struct SDLError(String), impl Error for it, and map_err SDL results into that. Then go smack the SDL crate maintainers for unidiomatic error handling.
|
# ? Dec 9, 2016 02:37 |
|
Mapping errors sounds good, thanks. They not only use Strings for some errors (errors in init() and Sdl::video), they have an error type UpdateTextureError that doesn't implement Error? It's real weird. Probably going to see if they've done something about that and try to patch it otherwise.
|
# ? Dec 9, 2016 02:41 |
|
Ralith posted:You can chain_err any Result type if you have the symbols from a module containing an error_chain! invocation in scope. The method comes from a macro-generated ResultExt trait, and it returns the type of Result defined by that macro. For simple command-line tools, I often just have "error_chain! {}" at the top of the file so I can provide nice detailed information-preserving textual error messages everywhere. Do you have any good examples of command line tools written in rust?
|
# ? Dec 9, 2016 20:38 |
|
MALE SHOEGAZE posted:Do you have any good examples of command line tools written in rust?
|
# ? Dec 10, 2016 02:08 |
|
Ralith posted:The tools I've been writing recently wouldn't make much sense to share, but I hear ripgrep is pretty neat. If you're looking for examples of error-chain use specifically, the best I can do is suggest you page through the reverse dependency list. Maybe Xargo? Thanks for reminding me of rip grep. I'd been meaning to check out this code review of ripgrep, and it is indeed pretty fantastic for language learners. (Thanks for the other links too, I'll check them out).
|
# ? Dec 10, 2016 16:36 |
|
MALE SHOEGAZE posted:Thanks for reminding me of rip grep. I'd been meaning to check out this code review of ripgrep, and it is indeed pretty fantastic for language learners. (Thanks for the other links too, I'll check them out). "stealer" instead of "thief" is a real nails-on-the-chalkboard thing for me. Neat otherwise, though.
|
# ? Dec 12, 2016 21:01 |
|
So, I want to parse a protobuf result and then match over the possible return types, but I've got no idea how to to do it. Protobuf types: code:
code:
I understand that it cant `parse_from_bytes` without a concrete type to return. I think I'm just using the protobuf library wrong but it has very little documentation so I'm just trying to follow the compiler to victory. DONT THREAD ON ME fucked around with this message at 23:05 on Dec 18, 2016 |
# ? Dec 18, 2016 23:01 |
|
MALE SHOEGAZE posted:So, I want to parse a protobuf result and then match over the possible return types, but I've got no idea how to to do it. You can explicitly specify type parameters by calling a function with syntax like "parse_from_bytes::<MyMessageType>(m)". You may also get better results from inference once you've actually entered some cases that entail a specific concrete discriminant type. Alternatively, you could switch to cap'n proto! I assume you're aware that in real code you shouldn't call unwrap like that, and should instead define an error type which can clearly express/embed the cause of a failure, for example using error-chain.
|
# ? Dec 18, 2016 23:19 |
|
Ralith posted:You can explicitly specify type parameters by calling a function with syntax like "parse_from_bytes::<MyMessageType>(m)". You may also get better results from inference once you've actually entered some cases that entail a specific concrete discriminant type. boo! I tried that but I was doing parse_from_bytes<MyMessageType>(m). The parse errors probably should have clued me in. And yeah, I'm still getting used to error handling, but I recognize that by just calling unwrap, I'm failing to handle errors.
|
# ? Dec 18, 2016 23:30 |
|
MALE SHOEGAZE posted:boo! I tried that but I was doing parse_from_bytes<MyMessageType>(m). The parse errors probably should have clued me in. I'm pretty sure all Rust I've ever written contains ".unwrap() // TODO" and all haskell "fromJust x -- TODO"
|
# ? Dec 18, 2016 23:43 |
|
MALE SHOEGAZE posted:boo! I tried that but I was doing parse_from_bytes<MyMessageType>(m). The parse errors probably should have clued me in. gonadic io posted:I'm pretty sure all Rust I've ever written contains ".unwrap() // TODO" and all haskell "fromJust x -- TODO"
|
# ? Dec 19, 2016 04:42 |
|
double edit: Thought I had it figured out. I'm using stable-msvc on windows. What's the recommended setup for debugging? I understand visual debugging is possible with VS2015, but I can't figure out how the setup is supposed to work. I can't get symbols to load for my executable, which I built with cargo run. Do I have an alternative to VS2015? Tooling has definitely been my major issue working with Rust so far, but my project is still only about ~200 LoC. I haven't had to write specialized data structures or anything. Fergus Mac Roich fucked around with this message at 10:25 on Jan 1, 2017 |
# ? Jan 1, 2017 08:03 |
|
|
# ? Jun 3, 2024 22:28 |
|
Yeah, refactoring can be super annoying, especially if you're adding or removing a lifetime or something. Fortunately, there's nothing stopping rust from having very powerful tooling, so I think it's just a matter of time.
|
# ? Jan 3, 2017 19:37 |