Jo posted:

Speaking of traits, I've defined this type 'Skeleton' which I'm using as the "parent".

I'd like to define a 'load' method which takes a filename, since each different skeleton format (BVH, C3D, Blend, etc) will probably have its own skeleton struct.

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.

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.

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.

Redmark posted:

Also holy poo poo emscripten/LLVM took forever to build. Is that typical for large C++ projects?

MALE SHOEGAZE posted:

Do you have any good examples of command line tools written in rust?

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.

Protobuf types:

So, basically, I want to parse the protobuf message, and then match over the result, performing a dispatch depending on the type. But I'm clearly going about it the wrong way. Any clues?

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.

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.

And yeah, I'm still getting used to error handling, but I recognize that by just calling unwrap, I'm failing to handle errors.

gonadic io posted:

I'm pretty sure all Rust I've ever written contains ".unwrap() // TODO" and all haskell "fromJust x -- TODO"

Asymmetrikon posted:

Filter is parameterized over a P: FnMut, which the compiler just represents as an anonymous closure, though. How do you express that kind of type concretely?

xtal posted:

Is there such a thing as a function composition or pipelining operator in Rust?

xtal posted:

I'm also interested in a macro to combine `fn` and `match` since all of my functions match anyway. Yes I come from Haskell and be glad you don't work with me.

gonadic io posted:

Is there a way to generate an identifier inside a macro?

gonadic io posted:

I'm still not sure how this would affect how that block actually executes at run-time. Would all the type definitions and impls happen at compile-time so at run-time that's identical to just having the "Foo::new()" on its own?

gonadic io posted:

I think impl trait is my favourite of the new features, just because it makes working with unboxed closures and iterators so much easier.

TheCog posted:

I keep meaning to poke at rust but I don't have a good idea of what kinds of projects its well suited to. I've mostly only done webapps and web design like things, (ok and some automation scripts), are there any cool ideas for projects to build? I followed the tutorial in the docs a while back and built the guess checker, but that didn't really give me a good idea of what kinds of cool projects rust enables. Are there any really recommended tutorials or even just suggestions for things to build that people could recommend?

xtal posted:

I made a web app with Rocket and tbh it almost put me off Rust entirely. Probably 90% of it happens in macros, and Rust has one of the worst macro systems ever. Rust is going to need to address this at some point because the rigidity of the language makes you use macros and macros are worthless without homoiconicity

MALE SHOEGAZE posted:

I'm playing with Rocket and Diesel -- they're the first real frameworks I've tried in rust (tokio is probably the largest library I've dealt with).

CodeGen and Macros are going to ruin this language.

http://docs.diesel.rs/diesel/macro.infer_table_from_schema.html

I'm flabbergasted that the compiler even makes this possible. I'm doubly flabbergasted that Diesel presents this in their tutorial as the way to generate their schema.

MALE SHOEGAZE posted:

What concerns me is that rust made this incredibly easy. Yes, I was importing a crate called `_codegen`, which should have tipped me off, but beyond that it's just a macro. If this were enabled as part of a plugin, it would be a different story. Macros should not be able to do this, and now I'm going to have to be incredibly suspicious of every single macro I encounter because it could be doing network insanity at compile time. (I could be mistaken about some of this, I haven't actually figured out how this macro works yet).

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.

Or should you just never use arrays when working with objects?

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.

The system uses a bunch of external libraries (e.g. r2d2_postgres, rouille, serde of course, ...) and previously we used error_chain's foreign_links functionality to explicitly declare how all the possible errors that could occur would be converted into our error representations.

I considered that one of the major selling points of error handling in Rust: The compiler would be able to point out which foreign errors have not yet been "acknowledged" in the error handling strategy. It was still possible to then proceed to drop the errors on the floor, but dispatching different handling strategies on foreign & internal errors in the same way was trivial to do.

Now with failure everything gets shoved into a single, shared Error-type. Keeping information about what kind of error occured either requires littering the code with verbose .context(...) calls or using runtime reflection () and - since almost every error is implicitly convertable to a failure - using ? now feels like working with a method that has throws Exception in its signature in Java.

To make things worse, errors from error_chain can actually not be converted to failures because they aren't Sync. This makes using libraries that have switched to failure somewhat painful from an error_chain based application.

This kind of "lets throw the types away!" dynlang bullshit should stay out of my Rust ecosystem

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".

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.

HappyHippo posted:

Ok between that and the documentation I think I understand. Thanks

Dominoes posted:

Hey dudes. How do you enter values in scientific notation?

Rust code:

const ELECTRON_MASS: f64 = 9.109390 * (10.).powi(-31);

Linear Zoetrope posted:

Basically, Rust does untyped infinite-precision arithmetic on literals, but this is limited to the built in operators (+, -, *, /, and for ints, %, |, ^, &, <<, >>).

code:

let mut x = 5;
x = x + 12;

let y: () = x;

Will tell you x is of type {integer} which is an infinite-precision int. The variable will remain this pseudo-type until x is coerced into a type implicitly by assigning it, calling a function, etc. All of these operations on these pseudo-types are done at compile time, hence why they're limited to built-in operators. You're not allowed to call functions like powi until the exact runtime sized type is known (f64). There's an argument that since you're assigning to an f64, the compiler's type inference should be able to work out you mean f64, but there's also an argument for explicitness that fits with Rust's general philosophy (such as requiring you to manually type convert from an f32 to an f64 if you're doing let result: f64 = my_f64 + (my_f32 as f64)).

It's on the roadmap for Rust to eventually allow compile time functions, const fn which signals a function contains an algorithm that may (but not must) be run at compile/startup time. These are usually basic math and initialization functions (such as building a new global Mutex), but there hasn't been agreement on exactly how it should work and what the restrictions should be. See the tracking issue here.

Until then, the lazy_static crate provides a macro that sorta does that. Instead of a const it declares a static wrapped in a function that's called automatically the first time the variable is read. This theoretically has some minor runtime overhead, but it works in most cases. There may be an argument against using a number declared in lazy_static in a hot loop, but I'd need to see benchmarks before saying that. The compiler may be able to optimize around call_once properly since I think it's a core intrinsic of FnOnce.

Linear Zoetrope posted:

I think I got it confused with Go, which does do infinite precision arithmetic on literals.

Dylan16807 posted:

No, "integer constant" and "floating-point constant" are their own types.

Dylan16807 posted:

It actually makes things more consistent, because you know that (5 << 40) >> 40 is always 5.

Dylan16807 posted:

Is it really that much weirder than getting different results when x is uint8?

Sheep posted:

Anyone familiar with the openssl crate? I spent about four hours today trying to get a simple server going with very little luck. Complicating matters is the fact that all of the documentation I could find for the crate is entirely incorrect regarding SslAcceptor/etc. so I had to do a ton of source diving just to get things building (and then failing with no ciphers available).

Trying to keep dependencies light so not really interested in using tokio/native-tls/whatever else. I've got the client side written in Rust using openssl with no issues talking to a Python-based server so halfway there, in some sense.

Dylan16807 posted:

Does that mean you're agreeing with me now?

LookingGodIntheEye posted:

Progressive JPEG posted:

Is there a way to update the README content included on crates.io without cutting a whole new release? I added some README content in the repo but there hasn't been any need to change the code. The sole image link in the crate README has stopped rendering as well, because they apparently just link back to the repo master for images rather than importing them. "Immutable" my rear end.

Hadlock posted:

Trying to figure out how to create a nested struct that has an array at the top level struct. Stuggling. I am trying to do one of those 2D rendered spinning cube things, which involves three primary structs,

Position: xyz coordinates as f64
Wire: start and end positions

Cube: An array of 12 Wires

I can't figure out the struct declaration syntax to do this. I'm sure it's relatively straightforward and simple. As a test, I have tried creating a zero-ed out array of u8 and then would implement it with specific values after the fact, but, yeah. For this example I've sucked out most of the irrelevant bits. I've got a simple cube struct as a placeholder for now. Thoughts? ha;lp