enigo::Enigo::key_sequence too fast in release mode about enigo HOT 27 CLOSED

Isn't

from enigo.

i could put one out immediately ... (if ci says ok)

from enigo.

Interesting! Operating system?

EDIT: Confirmed not working on Linux...
EDIT 2: It feels like the problem here is inside unicode_string_to_keycode, as it only affects unicode sequences (which is why your workaround worked. You could also use the parser.)
EDIT 3: That's odd, the LLVM-IR doesn't look very different

EDIT 4: The MIR doesn't look different either, although I'm not sure if that is pre or post optimization.

from enigo.

also, I re-opened the rust bug. Not sure if the rust guys consider this a bug (basically it's a symptom of when the compiler says "temporary value doesn't live long enough" -- except it's an unsafe pointer so the compiler doesn't tell you anything).

This is probably a case where an unsafe linter would be GREAT

from enigo.

Oh that's great it was the fix, I also noticed this line should be fixed too

from enigo.

also, the need for Key::Shift looks like it might be a bug to me.

from enigo.

sorry, operating system is Arch Linux

$ uname -a                                                                       
Linux vitiral 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux

from enigo.

maybe try adding #[inline(never)] on a few functions an experiment? I don't know the best way to avoid these kind of optimizations.

I don't see speed as super crtical to this library :)

from enigo.

also, this might very well be a rust compiler bug. It's pretty weird to see different behavior for different build modes.

from enigo.

also, the two pieces of LLVM you posted look like stuff from the mouse commands? This is a problem with the keyboard (although maybe I'm misunderstanding)

Edit: pretty sure "MIR" is always pre-optimization, since release optimization is all LLVM at this point.

I think we just need to tell LLVM not to optimize some stuff.

from enigo.

The key_sequence function supports unicode, by temporarily mapping an unused keyboard key in unicode_string_to_keycode. In release mode, this appears to be optimized away.

I doubt this is an #[inline(never)] issue, but I am unsure. I know too little about this to answer.

from enigo.

it looks like we might be able to disable optimizations for this crate with:

[profile.dev]
opt-level = 0

[profile.release]
opt-level = 0

In the Cargo.toml file. Here is a reference.

If you are okay with that, I can make the change and test it locally.

It seems to build an unoptimized release when I build locally:

$ cargo build --release       
    Updating registry `https://github.com/rust-lang/crates.io-index`                                     
   Compiling pkg-config v0.3.9                      
   Compiling libc v0.2.30 
   Compiling enigo v0.0.10 (file:///home/garrett/src/ruststuff/enigo)                                    
    Finished release [unoptimized] target(s) in 4.2 secs 

Edit: I'm testing it out with my application now.

from enigo.

hmm... it doesn't seem to have had an effect :(

from enigo.

I've also blanketed all functions in linux_impl with #[no_mangle] and it seems to not have an effect

Edit: also added #[inline(never)]... still no effect

from enigo.

I opened the above ticket, hopefully someone from rust knows how this might be solved.

from enigo.

Shouldn't that be dropped like normal?

from enigo.

I might be mistaken but I was under the impression that the temporary array would be dropped at the end of that that line. You can test if it is the issue by moving the as_ptr call to the function call.

from enigo.

Ooooo yeah that's a good call. However, I think Rust keeps it alive, just like it would with a pointer.

Playground

from enigo.

Try this: playground

from enigo.

Also works?

from enigo.

Use release mode.

from enigo.

Ooooooooooo! Is that supposed to happen or is it a Rust bug?

from enigo.

Doesn't seem like GitHub shows the commit that fixed this... Here it is

from enigo.

Confirmed that this now works for novault. Thanks!

Any idea when a new release will be made?

from enigo.

Does clippy say anything about it? If not, I agree it definitely should, it's easy to do.

from enigo.

we should start using clippy though :/ idk to be honest

from enigo.

@vitiral new version in the wild. Thanks for your help and everybody involved!

from enigo.