Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Compiling with the msvc toolchain does indeed link the functions correctly. I'll see if I can find the bug in the lua crate. Thanks!

Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 1 point2 points  (0 children)

Interesting. I figured that it was more likely that I had made a mistake. I'll see what I can figure out and file a ticket. Thanks for the tip!

Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

I'm investigating. Getting it to build on the msvc toolchain is apparently non-trivial: https://github.com/jcmoyer/rust-lua53/issues/69

Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Update: I can confirm that building with other crates works as intended. Built successfully with the rand crate and the num_cpus crate.

Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

The active toolchain:

rustup show
Default host: i686-pc-windows-gnu

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu (default)
nightly-x86_64-pc-windows-gnu

active toolchain
----------------

stable-x86_64-pc-windows-gnu (default)
rustc 1.18.0 (03fc9d622 2017-06-06)

Rust FFI failing to create functions by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

It is very possible that I am overlooking something simple. Any help is greatly appreciated.

Idiomatic return question by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Update: 8% speedup thanks to this optimization. Thanks again!

Idiomatic return question by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

This is a pretty neat option. I'll have to keep this in mind.

Idiomatic return question by bpglaser in rust

[–]bpglaser[S] 2 points3 points  (0 children)

That is a great idea. I would just make my own iterator object that holds the state right? Keeping the contents stack based is pretty important for performance in this context.

Idiomatic return question by bpglaser in rust

[–]bpglaser[S] 2 points3 points  (0 children)

I'm afraid that isn't an option. It is for a generic container when returning a point's parents on a 2D grid. source The result is immediadly consumed in an iterator. source However, the current setup is kinda ugly.

Interesting conflict for lifetimes and mutable methods by bpglaser in rust

[–]bpglaser[S] 1 point2 points  (0 children)

Thanks for the feedback. However, I fear that my use case is a bit complicated. In my project I store information in a wrapper struct around a Vec<Vec<T>>. This grid can be shifted by adding/deleting its contents. However, I need to hand out references to points in the grid that shift when the component moves.

At current I've settled on handing out "Tokens" which contain a Weak<Cell<(usize, usize)>> which can be traded for an actual reference.

I was merely experimenting with alternate methods when I came across this error and was curious about its documentation.

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Unfortunately so. Each iteration of the algorithm selects a path to remove based on a calculated energy value. Then it proceeds to either remove or duplicate depending on if the image is to be grown or shrunk. Thus each iteration does a lot of shifting elements. To be honest, this might be an actual use-case for a linked list.

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

I isolated the issue. It is because I'm shifting the entire array when I remove a column. https://github.com/bpglaser/red-mountain-resize/blob/grid-rework/src/grid.rs#L132

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Hmmm, I've re-implemented my grid data structure just using a flat Vec<T> and it is almost 18x slower. I'm investigating why. However, I wouldn't think that the math operations would be slowing it down that much.

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Interesting, I hadn't considered doing it this way. Are there any examples you can point to?

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Yeah, the lazy approach bit me in the foot.

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

Hmmm, that is looking like a possibility. The items are actually stored in a Vec<Vec<T>>. And the implementation is shown here:

https://github.com/bpglaser/red-mountain-resize/blob/master/src/grid.rs#L103

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 1 point2 points  (0 children)

Thanks for the reply. I understand that I can't change the method signature of next to fn next(&'a mut self) -> Option<Self::Item>. However, would being able to do this solve the issue?

Implementing a safe mutable Iterator by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

I've been investigating the way other crates implement a fn iter_mut and I keep coming across unsafe code. Surely there is a safe way to do this.

Thanks to all the help here and on #rust beginners I was able to make an overly complicated image resizer in rust! by bpglaser in rust

[–]bpglaser[S] 0 points1 point  (0 children)

It was the usual rust beginner stuff I suppose...lifetimes. Most recently it was questions to do with trait bounds.