Might as well add this

I might as well add the fact that on my 2012 MBP when having iTunes RP open it now won't show my Discord status and my song currently playing at the same time. So when I have iTunes RP displaying what song I'm listening to my Discord status disappears, and when I stop iTunes RP my status comes back.

Are you able to circumvent this issue by disabling App Nap for this particular application?

well uhh the issue is gone now idk what happened
all ik is that it displays the song im listening to and shows my status again


Different than thoughtbot/laptop?

In the similar vein of sprout-wrap, I wonder how workstation-setup compares to Thoughtbot's laptop? I'm interested in trying it because it's bash only, with a clear customization path.
My biggest pain point with sprout, which both workstation-setup and laptop solve, is that it's written in Ruby, and so many of our clients aren't using Ruby at all. Highlighting that workstation-setup is all bash is probably a win.

Aside from differences of opinion/preference, I notice that they
specifically promise that it's ok to run multiple times on the same
machine. workstation-setup doesn't guarantee that but I don't think it's
grossly non-idempotent -- it's probably pretty close.
I like the language-flavor customizations that workstation-setup allows
On Fri, Apr 6, 2018, 9:39 AM Will Read<EMAIL_ADDRESS>wrote:

In the similar vein of sprout-wrap, I wonder how workstation-setup
compares to Thoughtbot's laptop https://github.com/thoughtbot/laptop?
I'm interested in trying it because it's bash only, with a clear
customization path.
My biggest pain point with sprout, which both workstation-setup and laptop
solve, is that it's written in Ruby, and so many of our clients aren't
using Ruby at all. Highlighting that workstation-setup is all bash is
probably a win.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pivotal/workstation-setup/issues/198, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AGkSAZan24A6L0GfVwl5LZ3vrJKAOpLtks5tl5ozgaJpZM4TKXUg
.

We do strive for it to be safe to re-run workstation-setup. We should probably call that out better in the README.


Video cut shorter than audio

I am able to generate video voiceover from an audio, however, the final video version is only a portion of the complete audio. Is there a way to fix this issue? For example the audio is 40s while video is 4 sec long.

I think the text in the audio was tokenized and its generating video only for the last token.


Can't use opencv in Windows: C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found

I followed the instructions described in INSTALLATION.md but I am getting the following error:
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: calib3d
stack backtrace:
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:118:36:
Generator process panicked: Any { .. }
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: core::result::unwrap_failed
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\result.rs:1654
3: core::result::Result<T,E>::expect
4: build_script_build::generator::BindingGenerator::run::{{closure}}
5: std::thread::scoped::scope::{{closure}}
6: <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
7: std::panicking::try
8: build_script_build::docs::transfer_bindings_to_docs::{{closure}}
9: std::panicking::try
10: std::thread::scoped::scope
11: build_script_build::generator::BindingGenerator::generate_wrapper::{{closure}}::{{closure}}
12: build_script_build::generator::BindingGenerator::generate_wrapper
13: build_script_build::setup_rerun::{{closure}}::{{closure}}
14: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: dnn
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: features2d
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: flann
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: core
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: gapi
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: stitching
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: imgcodecs
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: imgproc
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: ml
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: objdetect
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: photo
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: highgui
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
=== WARNING: 1 diagnostic messages
===    C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\src_cpp\ocvrs_common.hpp:16:10: fatal error: 'memory' file not found
thread 'main' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-binding-generator-0.90.0\src\generator.rs:402:17:
=== Errors during header parsing
stack backtrace:
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: video
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: opencv_binding_generator::generator::Generator::handle_diags
3: opencv_binding_generator::generator::OpenCvWalker::process_typedef::{{closure}}
4: opencv_binding_generator::generator::Generator::generate
5: build_script_build::binding_generator::handle_running_binding_generator
6: build_script_build::binding_generator::handle_running_binding_generator
7: build_script_build::setup_rerun::{{closure}}::{{closure}}
8: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread '' panicked at C:\Users\Admin.cargo\registry\src\index.crates.io-6f17d22bba15001f\opencv-0.92.0\build\generator.rs:109:33:
Failed to run the bindings generator for module: videoio
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
2: build_script_build::generator::BindingGenerator::run::{{closure}}::{{closure}}::{{closure}}
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

I encountered the same problem

Having the same issue when compiling in a docker image

@alexisgaziello Can you please share the Dockerfile that was causing the issue?

I encountered the same problem
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
use the installl.sh  Unable to compile successfully my opencv-rust project

I got the same issue on PopOS 22.04

I found a solution, at least for me. The missing memory was due to "CPLUS_INCLUDE_PATH" not being set. Adding this gave me the a new error telling me that some other headers were missing related to C++20 features. I realized my default llvm installation did not give me C++20 clang. The following worked for me:

Install the pacakges mentioned in install.md: apt install libopencv-dev clang libclang-dev
Also install libc++-dev and libstdc++-12-abd-dev. Note that the 12 is there to match the GCC 12 version I had. If it does not work, verify that you have a c++config.h where GCC 12 is installed.


Terminal quick fix results in @vscode /explain in panel chat

run a command that yields an error in the terminal
use the quick fix, Explain Using Copilot in the terminal, cmd+. -> `
See @vscode /explain #terminalLastCommand in panel chat

I'm unable to repro this. However I do see an issue with additional unnecessary contexts being invoked

I cannot reproduce this behavior when coming from the terminal quick fix @meganrogge:

But the very first time I attempt submitting the query, I see that @terminal is not picked up by VS Code, cc @roblourens:

Actually, I now repro @terminal not being picked up 100% of the time. We have two @terminals and we're picking the first one, then dropping it because it's not available in panel chat https://github.com/microsoft/vscode-copilot/blob/be960dbb84447b100951e51c1257e509eac8064a/package.json#L280-L314. https://github.com/microsoft/vscode/pull/224220

Today, I'm not seeing the copilot quick fix in the terminal at all 🤷♀

Works for me on Windows with Powershell, latest Insiders + prerelease :shrug:


Fix obj loader tests

The PG test had a BABYLON.OBJFileLoader.USE_LEGACY_BEHAVIOR = true which was bleeding into other PG tests.

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/14926/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14926/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14926/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/14926/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14926/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14926/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14926/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/14926/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
Important - these might fail sporadically. This is an optional test.
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14926/merge/testResults/webgpuplaywright/index.html


Rrefresh intermediary accounts test

Closes: #XXX
Description

For contributor use:

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

Codecov Report

Merging #1098 (8910ca6) into main (956e553) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1098   +/-   ##
=======================================
  Coverage   20.94%   20.95%
=======================================
  Files         199      199
  Lines       25429    25432    +3
=======================================
+ Hits         5326     5329    +3
  Misses      19140    19140
  Partials      963      963

Impacted Files
Coverage Δ

x/superfluid/keeper/stake.go
58.85% <100.00%> (+0.71%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 956e553...8910ca6. Read the comment docs.


Fix typos in README.md

Fix typos in README.md. Also my markdown add-on automatically reformatted the index page.

Thanks for the quick PR max. We have not been open source for even 12 hours lol. We use this script to take the markdown and render it to pdf via pandoc https://github.com/GusSand/Anubis/blob/master/docs/render.sh. I just need to check that the pdf that is generated from the readme is working ok.

Well it's Sunday. I got nothing interesting to do. And I saw you guys open source it. So why not :-)

So I pushed two things. There is apparently an indentation limit with vanilla pandoc (4 levels) so I removed one level of indentation at the top of the readme. The second is just re-running pandoc to get a new pdf from your fixes.
btw, what is currently in the readme is probably going to moved to be under docs soon. We have an open issue on the project board to make the readme more user friendly https://github.com/GusSand/Anubis/issues/117
Will merge now, thanks for the contribution.


Auto Suggest not Working on Android/Chrome devices

The auto suggest feature doesn't work on android devices using chrome. Tested this with the latest chrome for android browser on a Samsung Tablet as well as on a nexus 4 mobile phone.
A quick remote debugging didn't show any errors in the console, so it's apparently not some obvious issue. Didn't check further though.

@matthias-ebner: It makes not much sense to just report that something doesn't work while not saying what the expected behavior was and how it differed from that.
As you're reporting from your point of view, this is necessary for a good issue report and also for other users - like me - to find out if they have the same issue or not.

@matthias-ebner: Maybe if you still remember what the case was, please update the ticket.

@matthias-ebner in case the issue is not updated until the 14th od December, it will be closed


Replace use of deprecated componentWillReceiveProps

Summary & motivation
This PR replaces usage of the deprecated componentWillReceiveProps method with componentDidUpdate to ensure React 16.9 compatibility.
It is a rebased version of #255 from @rynobax (thank you!).
I plan on releasing a new major version after this is merged.
Testing & documentation
Covered by existing tests and tested manually.

lgtm


modeld: adding checks for sm.updated

Does this actually have any impact on performance? Both should be updated every time anyway.

You are right, it really doesn't make sense.
another question: can we move them into live_thread?

I don't really see the point of that. It just creates more globals


Add a dev container for easy development setup

[ ] Add .devcontainer files
[ ] Update the Dockerfile to install the needed dependencies
[ ] Test it out by developing in it
[ ] Update documentation

See Issue 41 on the my-model project


Add TeraSky to the TCE Adopters file

What this PR does / why we need it

Add TeraSky to the TCE ADOPTERS.md
Details for the Release Notes (PLEASE PROVIDE)

NONE

Which issue(s) this PR fixes

Fixes: #
Describe testing done for PR

Special notes for your reviewer

Thanks for submitting this Scott.
Could we get this more like the Carvel format of logo at the top and description at the bottom?
https://github.com/vmware-tanzu/carvel/blob/develop/ADOPTERS.md

there seems to be an issue with the URL Linter accepting the Certificate of the Link to the terasky website. also @pnbrown, i made the changes to be like the Carvel ADOPTERS.md but now the mdlinter is complaining as it doesnt allow embedded HTML so not sure what to do about this

There seems to be an issue with the URL Linter accepting the Certificate of the Link to the terasky website

We are looking at that now. Shouldn't be a blocker, we are considering setting the skip insecure verification since we the URL linter shouldn't really care about if the cert is valid, just that it at least goes somewhere. Stay tuned!


Adding JDK matrix for integration tests

Description
Adding JDK 8, 14, 15 and 17 in the matrix for integration tests. Also updating the developer guide with docker-compose commands added in PR #122.
Issues Resolved
Closes #124
Check List

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

👏


SingleColumnTransformers don't work with ColumnTransformer

Describe the bug
On the dev version, both GapEncoder and MinHashEncoder work well with the TableVectorizer, but fail with the ColumnTransformer from scikit-learn.
Steps/Code to Reproduce
from sklearn.compose import make_column_transformer
from skrub.datasets import fetch_employee_salaries
from skrub import GapEncoder

bunch = fetch_employee_salaries()

transformer = make_column_transformer(
    (GapEncoder(), bunch.X.select_dtypes("object").columns)
)
transformer.fit(bunch.X)

Expected Results
No error is thrown
Actual Results
ValueError: GapEncoder.fit should be passed a single column, not a dataframe. GapEncoder is a type of single-column transformer. Unlike most scikit-learn estimators, its fit, transform and fit_transform methods expect a single column (a pandas or polars Series) rather than a full dataframe. To apply this transformer to one or more columns in a dataframe, use it as a parameter in a skrub.TableVectorizer or sklearn.compose.ColumnTransformer.
Versions
System:
    python: 3.12.3 | packaged by conda-forge | (main, Apr 15 2024, 18:35:20) [Clang 16.0.6 ]
executable: /Users/vincentmaladiere/miniforge3/envs/sandbox/bin/python3.12
   machine: macOS-14.0-arm64-arm-64bit

Python dependencies:
      sklearn: 1.5.0
          pip: 24.0
   setuptools: 70.0.0
        numpy: 1.26.4
        scipy: 1.13.1
       Cython: None
       pandas: 2.2.2
   matplotlib: 3.9.0
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /Users/vincentmaladiere/miniforge3/envs/sandbox/lib/python3.12/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: armv8

       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /Users/vincentmaladiere/miniforge3/envs/sandbox/lib/python3.12/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.27
threading_layer: pthreads
   architecture: neoversen1

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /Users/vincentmaladiere/miniforge3/envs/sandbox/lib/python3.12/site-packages/sklearn/.dylibs/libomp.dylib
        version: None
0.2.0.dev0

that's expected if you pass them a dataframe (several columns in the ColumnTransformer). They will work if you pass a singlecolumn (GapEncoder(), "column_name") -- as scikit-learn's TfidfVectorizer for example.
that was a deliberate decision we made with @GaelVaroquaux . our reasoning is that with the TableVectorizer and the upcoming pipeline builder, skrub users are not expected to need the ColumnTransformer anymore.
the equivalent pipeline would look something like
from skrub.datasets import fetch_employee_salaries
from skrub import GapEncoder
from skrub import PipeBuilder
from skrub import selectors as s

bunch = fetch_employee_salaries()

transformer = PipeBuilder().apply(GapEncoder(), cols=s.string()).get_pipeline()
transformer.fit_transform(bunch.X)

or for this dataset you may want the TableVectorizer because the GapEncoder with default parameters might not work on the "gender" column I think so the cardinality threshold could be useful. With the skrub pipeline you could also do somehting like cols=s.string() - 'gender'

Maybe we should improve our error behavior to help the user understand that this is expected and the skrub tools should be used

I can expand the error message to say that when used in the ColumnTransformer, the corresponding columns should be a single column

Yes, right now the error message is plain wrong, as you can't use the GapEncoder with multiple columns in the ColumnTransformer.


Typo "** must not include **"→"must not include"

https://docs.microsoft.com/en-us/microsoftteams/phone-number-calling-plans/port-order-overview
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/blob/live/Teams/phone-number-calling-plans/port-order-overview.md
#PingMSFTDocs

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@SerdarSoysal Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@SerdarSoysal Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@SerdarSoysal Thank you for submitting feedback and contributing to the docs. We are currently investigating this.


add guess_next_move tactic

This uses stockfish to find a suitable next for "self"  move when proving a ForcedWin.  It assumes that a binary called stockfish is in your path.
I modeled it after the polyrith tactic, so you can click on try this: move "foo" and it will insert the suggestions. Right now it let's stockfish think for 0.1s, but we could make that adjustable of course.

This prompted me to finally move the chess stuff to its own repo: https://github.com/dwrensha/Chess.lean
Please reopen this PR over there.


fix(Item): actually make content a shorthand prop for ItemContent

It says it is in the docs, but actually Item currently just forwards the content prop to ItemContent like a typical content prop.
With this PR nothing changes for people who were using a primitive value, but it might be a breaking change if people were supplying an element or array, they would need to change it to content={ content: <element /> } or similar to match previous behaviour.
Also with this change ItemContent will no longer unconditionally render, at least one of the shorthands has to be present.

Codecov Report

Merging #4118 (a8a317c) into master (c828368) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #4118   +/-   ##
=======================================
  Coverage   99.75%   99.75%
=======================================
  Files         180      180
  Lines        3241     3246    +5
=======================================
+ Hits         3233     3238    +5
  Misses          8        8

Impacted Files
Coverage Δ

src/views/Item/Item.js
100.00% <100.00%> (ø)

src/views/Item/ItemContent.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c828368...a8a317c. Read the comment docs.


pcat.search(...).to_dataset_dict() sometimes slower than it should

Setup Information

xscen version: 0.6.12-beta
Python version: 3.11.4
Operating System: CentOs 7 (Doris)

Context
I store my files on "jarre", which is considered a slow disk AFAIK.
Sometimes, pcat.search(...).to_dataset_dict() will take forever to access my files (bad behaviour), while this homemade function:
def my_search(kwargs):
    paths = list(pcat.search(**kwargs).df.path)
    return {p:xr.open_zarr(p) for p in paths}

has a speed which is similar to the good expected behaviour  of pcat.search(...).to_dataset_dict() .
I can't tell what conditions on the server could be related to this problem. The problem sometimes comes, stays for a bit, and then stops.
Is this issue known?

to_dataset_dict() does more than just open the files. It groups together the files associated to a given dataset based on aggregation controls specified in the JSON (by default: id, processing_level, domain, frequency). There's also a semi-custom call to open_dataset --> combine_by_coords, instead of open_mfdatasets, although I don't quite remember the reasoning behind it.
For very big catalogs, I could see a substantial difference in speed compared to simply opening the files.
That being said, we could see if there are speedups to be accomplished.

@coxipi Is your catalog supposed to have aggregation, or is it indeed just a list of independent datasets ?
The aggregation can often be sped up with passing there to to_dataset_dict:
xarray_combine_by_coords_kwargs={'data_vars': 'minimal', 'coords': 'minimal', 'compat': 'override'}

assuming all the elements to be aggregated are well behaved (no overlap between files, all variables of the same name have the same dimensions and the exact same coordinates on the non-appended dims, etc).

Not sure what you mean by "independent datasets". Each key in the dataset dict represents a different simulation (each with its own single path to a zarr) as created in previous steps of the xscen workflow.

I meant that they are not meant to be unified into a single dataset in the same way a open_mfdataset would act.
In that case, I'm not sure why to_dataset_dict would be dramatically slower than your function...

There's also a semi-custom call to open_dataset --> combine_by_coords, instead of open_mfdatasets, although I don't quite remember their reasoning behind it.

@RondeauG, in  to_dataset_dict the aggregation is entirely driven by the catalog columns and configuration. In open_mfdataset, the aggregation is guessed by xarray by analyzing the coordinates.
Note: if the path column contains a *, open_mfdataset will be used, so one can combine both methods.


PostgreSQL autocomplete with schema name not working

I'm using the latest version of dbeaver community and/or enterprise, but the autocomplete for PostgreSQL doesn't seem to be working for me. By autocomplete, if I drag and drop a table to the sql editor, or right click and select "read data in sql console", the schema doesn't automatically complete. One of my co-workers is using dbeaver and the autocomplete in the above mentioned fashion works for them.
This becomes an issue when trying to import or export data, because schema selection for the target isn't an option (co-worker has schemas)

Is there some setting that has to be applied?
Thanks!

Can't reproduce that. And there is no special option to enable/disable schemas.

Do you and your coworker use the same PostgreSQL database?
What PostgreSQL driver do you use?
Do you see schemas in database navigator?

Seems like it was a driver issue, I was taking the default given. Once specifying a newer driver and restarting the application it worked. I can try to provide more detail if that would be useful.
Thanks for the response!

Ok. I'll close this as non-reproducible.


No IAdaptiveCardConfig

The documentation for Typescript says the following:

npm install microsoft-adaptivecards
There are interface definitions in schema.d.ts which describe the shape of the schema.

let card :IAdaptiveCard = {
    "type": "AdaptiveCard",
    "version": "0.5",
    "body": [
        {
            "type": "Container",
            "items": [
                {
                    "type": "TextBlock",
                    "text": "Meow!"
                },
                {
                    "type": "Image",
                    "url": "http://adaptivecards.io/api/cat"
                }
            ]
        }
    ]
};

There is also an object model for creating cards.

let card :IAdaptiveCard =  new AdaptiveCard();
card.body.add(new TextBlock()
{
    text = "hello world"
});

I do not see an IAdaptiveCard anywhere in the Typescript files.  Is this something that has changed and the documentation needs to be updated?

Hi @ncipollina, the interface definitions are not up to date. There is a work item for this, I just haven't had a chance to do it yet. Sorry about that.

@dclaux are you saying that the documentation is more current than the code?  This would make sense because the part of the documentation that uses the AdaptiveCard is incorrect.  The new card object has no body property and the syntax for property initialization on the new TexBlock is incorrect.  It should be:
card.body.add(new TextBlock() {      text: "hello world" });
The syntax in the documentation looks like C# to me.

No, actually the code is more current than the documentation. The reference is the AdaptiveCard object model. Interfaces now have to be defined according to the object model - the ones that currently exist are not up to date. And yes, the example in the doc is wrong (it's not proper JS/TS.)

It would be this:
var textBlock = new TextBlock();
textBlock.text = "Hello world";

var card = new AdaptiveCard();
card.addItem(textBlock);

var renderedCard = card.render();

And what if I want to add this AdaptiveCard as an attachment in a bot?  Assuming I have the following code:
let msg = new builder.Message(session)
     .addAttachment(card.render());
session.send(msg);

card.render() returns and HTMLElement and addAttachment() is expecting an IAttachment to be passed in.

In its current state, the TypeScript HTML library offers an object model that can render to an HTML element. It does not provide serialization to a string, which is what you seem to want. At some point in the past few months, interfaces matching the object model were introduced for serialization purposes, but these interfaces have not been maintained as the object model evolved. I will need to update them. In addition to that, a toString() method will likely be added to the AdaptiveCard object to do the same. I hope to get these done soon.
For now, I would say your best bet is to just write your card as an object without using the library, and do a JSON.stringify() on it.
Does that make sense?

Yes, it makes sense.

I would actually like to completely remove the schema interfaces. They are not very useful and are redundant with the OM. We should discuss.

The Typescript renderer now supports serialization via the OM using the toJSON method. Here is how to use it:
let myCard = new AdaptiveCard();
// populate the card one way or another (either parse() a payload or dynamically add elements in code)

let serializedCard = JSON.stringify(myCard.toJSON());

Closing this issue - please reopen if necessary.


Updated bubble_sort file

initialised the item outside the loop to prevent any unintended error.
updated the if block within the nested loop to cause a break in the loop.
Printed the sorted array with a message.

@Shreya23-tech contribute here https://github.com/Ishaan28malik/Get-Dev-Resources instead


env.mode: "entry" removes core-js import even though it's

Describe the bug
Imports of specific core-js parts are removed with a mode: usage.
Babel doesn't remove them: https://babeljs.io/repl#?browsers=Chrome 40&build=&builtIns=entry&corejs=3.21&spec=false&loose=false&code_lz=JYWwDg9gTgLgBAIgMbQKYFoBWBnA9CCAEwFcAbVPCgOmximADsBzKgQxnVdJlSgfeAA3VAgDcAKHFA&debug=false&forceAllTransforms=false&shippedProposals=true&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=unambiguous&lineWrap=false&presets=env&prettier=false&targets=&version=7.18.7&externalPlugins=&assumptions={}
Input code
import "core-js/modules/es.string.at-alternative";

Config
{
  "env": {
    "mode": "entry",
    "targets": "Chrome 40"
  },
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false
    },
    "target": "es5",
    "loose": false,
    "minify": {
      "compress": false,
      "mangle": false
    }
  },
  "module": {
    "type": "es6"
  },
  "minify": false,
  "isModule": true
}

Playground link
https://play.swc.rs/?version=1.2.210&code=H4sIAAAAAAAAA8vMLcgvKlFQSs4vStXNKtbPzU8pzUkt1k8t1isuKcrMS9dLLNFNzClJLcpLLMksS1Wy5gIApRxsVzMAAAA%3D&config=H4sIAAAAAAAAA0WOvQ7CMAyEXwV57sAADF2ZeYgouCUof7JdRBTl3RujRmz23Xenq4DxA3OFkJ4Ic%2F%2BECkwghlYU7sr9RSng6XKGNsGbrcLZECPpxSWK%2BWrQBsOWXBZQrEuL8YxtVCnC1%2B75lBgPd4LgoluKNtkUMiHz3zJx9YNsvahP3FSoICX%2FxvJNR42OI%2Bf4cYBCG7YdCn3HAOIAAAA%3D
Expected behavior
Don't remove the import
Actual behavior
Import is removed
Version
1.2.210
Additional context
No response

This is expected. You need to specify coreJs version -- String#at is introduced in a later version of core-js, and swc default coreJs version to 3.0, thus remove the import.
If you use same config for babel,
{
    presets: [["@babel/preset-env", { useBuiltIns: "entry", corejs: "3" }]];
}

same output would be generated

@Austaras But I have the latest core-js version installed in my repo. As I understand it babel/swc can import their own core-js version but I want to import only what I need myself. Why would importing work differently for the latest version of core-js than for all other packages? Is this really intended?

So should Parcel be detecting the version of core-js that's installed, and then pass that version (e.g. "3.23.3") to swc as preset_env_config.core_js?
(currently we use this preset env swc config: https://github.com/parcel-bundler/parcel/blob/99cf50510995112722f76f115dc7f2fd21587f34/packages/transformers/js/core/src/lib.rs#L278-L295)

So should Parcel be detecting the version of core-js that's installed, and then pass that version (e.g. "3.23.3") to swc as preset_env_config.core_js?
(currently we use this preset env swc config: https://github.com/parcel-bundler/parcel/blob/99cf50510995112722f76f115dc7f2fd21587f34/packages/transformers/js/core/src/lib.rs#L278-L295)

That sounds good, although 3.22 would be enough, as parcel is the bundler. It's a bit wired to build this feature into swc.

@Austaras But I have the latest core-js version installed in my repo. As I understand it babel/swc can import their own core-js version but I want to import only what I need myself. Why would importing work differently for the latest version of core-js than for all other packages? Is this really intended?

Babel didn't do auto core js version detection.


Request PR review

Folks - please consider: https://github.com/aws/aws-nitro-enclaves-sdk-c/pull/98
Thanks.

Taking a look.


Maven Dependency

Just a quick info: The Version .37 is not in the maven repository yet.

I have verified that it has been pushed, but sometimes it takes a day or so to propagate to the central repositories.  If it is not there in the next 24 hours I will look into it.


Replace KMS key module

Is your feature request related to a problem? Please describe

Replace the local implementation of KMS key module with the implementation provided by the terraform-aws-eks and terraform-aws-kms modules

Describe the solution you'd like

The local KMS key module is removed
The EKS module used in this project is updated to use the KMS key configurations provided by it for creating cluster keys
The aws-for-fluentbit module is updated to use the terraform-aws-kms

Additional context

Changes that users need to make when upgrading from v4.x to v5.x need to be added to the upgrade guide

closed in #857


Invalid Lookup Error in Snowfakery Recipes

Describe the bug
As of release 2.84.2 we are seeing this error when trying to load Snowfakery recipes "The lookup Account is not a valid lookup for ep01__Organization__c in sf_object: npsp__General_Accounting_Unit__c. Exception in task snowfakery"
This is happening in all the lookup fields.
Here's an error gist from a load that was importing from a csv: https://gist.github.com/apretorius/e1e1cddc0937dcbbb934adbecaf683bd
Reproduction steps

Select a snowfakery recipe that is populating a lookup field with a namespace token
Try to load it into an org
Get the lookup error.

Your CumulusCI and Python versions
Cumulus CI version: 2.84.2
Python version: 3.12
Operating System
macOS Monterey Version 12.6.2
Windows environment
No response
CumulusCI installation method
brew
Error Gist
https://gist.github.com/apretorius/e1e1cddc0937dcbbb934adbecaf683bd
Additional information
This is blocking our development work because we can't load in test data, so it's a pretty urgent item.

Hey @apretorius, the error is happening at the load_dataset step of the flow. There is a validation that ensures that the lookup tables specified are in the refereceTo of the lookup field. This is where it is failing in your case (returning an error like The lookup <lookup_sobject> is not a valid lookup for <lookup_field> in sf_object: <sobject>)
To reproduce the error, I tried creating a custom namespaced sobject (since it looks like it is failing in custom objects only), adding a lookup field and running extract and load. Unfortunately I was not able to reproduce the error you encountered.
I would need your recipe.yml, the mapping and sql file generated and the org setup details to see why this error is occurring

We are seeing the same errors loading data in v3.84.3, v3.84.1 is working with no error.
Here is the CCI load_data command:
cci task run load_dataset --mapping datasets/mapping.yml --sql_path datasets/data.sql --drop_missing_schema True
Here is a sample of the errors: (This is happening on all Lookup fields)
The lookup Contact is not a valid lookup for Signator__c in sf_object: AQB__Transaction__c
The lookup Account is not a valid lookup for MatchedAccount__c in sf_object: AQB__MatchLink__c
The lookup AQB__QuidSpecification__c is not a valid lookup for QuidSpecificationNumber__c in sf_object: AQB__QuidProQuo__c

We are seeing the same behavior! with version 3.84.3 Upvoting this one !

@apretorius and I work together, and chiming in here to say we have a blanket recommendation out to our entire organization to refrain from upgrading past 3.84.1 until this is fixed.
We've had issues with namespaces in our data in prior versions and were finally on track to eliminate the need for maintaining two different datasets (one namespaced, one not) after https://github.com/SFDO-Tooling/CumulusCI/pull/3713 . Is it possible that namespaces aren't being correctly identified and dealt with in this new lookup validation behavior?

We have developers on 3.84.1 who can load the dataset successfully, while only those on 3.84.3 are facing the issue. Is it possible to revert to 3.84.1?

@mikechayes
YES, you can fortunately downgrade pretty simply:
pipx uninstall cumulusci
pipx install cumulusci==2.84.1

@aditya-balachander Here is the sql file we're loading along with the mapping file.
blanked-data.zip
The task is this:

Thanks!  After the downgrade to 3.84.1, we can load data again.

We had the same problem here. load_dataset would fail on lookups with 3.84.3. Rolled back 3.84.1 for the win!

issues with v3.84.3 :
load_dataset failing when :

Lookup field to itself on a custom object without namespace fails to parse mapping with invalid reference error.
Workaround - specify complete namespace and double underscore __ before the custom lookup field name.
lookup to another custom object with after: insert in the mapping . It failing with cumulusci.core.exceptions.BulkDataException: Error on record with id 1: MISSING_ARGUMENT: Id not specified in an update call

@aditya-balachander requesting a follow up here since more folks are reporting this same error with the only work around being to not upgrade cumulusci

Let me know if someone from the CCI team wants to pair-program on this.

Hey @apretorius thank you providing the mapping and sql file. The issue was due to the way that our validation was handling namespaces. I have raised a PR #3759. This should fix the issue


we should better throw the error msg of  sysrepo to the client, when commit data failed .

we should better throw the error msg of  sysrepo to the client rather than a msg  ourselves define when commit data failed .as we know the more clear of the error msg the better for the client to modify the errors.

can you be more specific? From your description I don't know what you suggest to change.


chore: update all dependencies

Updates all dependencies (except @types/node) to the latest version, as you can't build the library with a recent version of TypeScript. It will build now.

@dilame please merge these changes

@dilame


Add multiarch support (again) and update to 17.06.0-ce-rc2

See also https://github.com/docker-library/buildpack-deps/pull/59 and https://github.com/docker-library/golang/pull/163.

Unfortunately, library/alpine doesn't have anything except amd64 at the moment, so the generated Architectures field isn't very exciting, but it will be! :sweat_smile:

LGTM


Include a custom configuration/scheme pair

Configuration/scheme pairs for ad-hoc releases and app store submissions would be nice.

I have done some work on this on #225 and #226

I think this is actually done thanks to @marcelofabri. I'm going to close this. If we need more here we can open a new issue.


Privacy policy link doesn't do anything

Not actually sure it should be there at all, but it currently doesn't go anywhere

@myleshorton should we just make a link to our FAQ instead?

I would probably just take it out. I don't really think it's worth cluttering up the screen with it. If we include it at all, it should definitely go somewhere, and I believe the only online privacy policy we have is on the wiki in GitHub.

Thanks, @myleshorton. I removed it!


Typo "accesss"→"access"

https://docs.microsoft.com/en-us/azure/data-factory/create-azure-ssis-integration-runtime-powershell
#PingMSFTDocs

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Taking a screenshot of an element that is bigger than the window width (horizontal scrolling)

What is your Scenario?
I want to take a screenshot of an element using the takeElementScreenshot API. My element is bigger in width than the window size. Think of the cards layout of Trello, it spans horizontally indefinitely.
I tried using the other takeScreenshot method and provided the fullPage: true option, but it didn't work too.
What is the Current behavior?
The screenshot is limited to the window size. TestCafe doesn't produce a screenshot where the whole element is visible.
What is the Expected behavior?
The screenshot should include the whole element.
What is your public website URL? (or attach your complete example)
Any Trello board would be sufficient, let's take this one as an example: https://trello.com/b/AwYSWOyt/ultimate-to-do-list
What is your TestCafe test code?
test("Generate screenshot", async (t) => {
  await t.takeElementScreenshot(
    Selector("#board"),
    "preview.png"
  );
});

OR
test("Generate screenshot", async (t) => {
  await t.takeScreenshot({
    path: "preview.png",
    fullPage: true,
  });
});

Your complete configuration file
No response
Your complete test report
No response
Screenshots
No response
Steps to Reproduce

TestCafe version
1.14.0
Node.js version
No response
Command-line arguments
none
Browser name(s) and version(s)
No response
Platform(s) and version(s)
No response
Other
No response

The takeElementScreenshot method does not currently have a full-page mode, so it can only capture elements that can fit on the screen entirely. Note that takeElementScreenshot scrolls the page to show the center of the target element if it's not visible due to overflow.
I will mark this issue as a feature request for full-page mode support in takeElementScreenshot. We will take it into account during our future planning.


License not found

Observed behaviour
Sometimes I get a "license not found" error. I couldn't reproduce this bug, so I don't know what's causing it. When this happens I have to quit everything and restart Clairus App before I start my app.
Steps to reproduce
I know that one of the reasons that causes this issue is when the probe enters "sleep mode". But it also happens in other occasions.
Expected behaviour
The license verification should not fail arbitrarily

The Mobile API license is linked to individual scanners, as opposed to user accounts, and is active only when a scanner is currently connected to the app. When your scanner goes to sleep, it disconnects and the license is removed. This is the expected behaviour as described in the README's licensing section  https://github.com/clariusdev/mobileapi#licensing.
The license is automatically re-activated as soon at the scanner re-connects and a notification message is sent to the Mobile API.


Updated Netty version (current is buggy)

Updated netty-codec-http version to current.
Removed meaningless whitespace.

Version 4.0.24 is buggy and silents Traceback errors that includes errors giving clue why jawampa is not working on some devices -  https://github.com/Matthias247/jawampa/issues/105
It is needed at least version 4.0.26 to properly show Tracebacks.
It is safe to update to version 4.0.40 without any other code changes.
I've updated to the latest 4.1.11.Final with single incompatible change - see line 112

Thanks. I think moving to Netty 4.1 is totally reasonable. There was just no stable release when this project was started.

Oh I totally forget to update version number? Would it be possible to update the version number and put it in maven so I can link this lib directly via gradle please? Thank you beforehand.

There's a 0.5.0 release which contains everything. Btw: The changes in the pull request were not sufficient for Netty 4.1. I also needed to add another dependency (netty-handler?) to get it building on my machine. I then also decided to fix the deprecation warnings that the change introduced. You can see that in the commit history.

Well, I also had to include netty-handler, but I thought that this is because I'm downloading it by hand. There is netty-handler included in netty-codec-http pom file: https://github.com/netty/netty/blob/4.1/codec-http/pom.xml So I'm a bit confused.
Anyway, thank you very much :)


Syntax highlighting

Installing this plugin disables all syntax highlighting in a .cake file. Is that by design?

@Leon99 well, the answer is yes, that is currently by design.
Rider, in it's default, somehow assumes some language for Cake files. (I've not found out which, currently.)
When installing Cake for Rider, we define a language for Cake files (this is needed for most of the things the plugin does) and this definition in it's current state does not include syntax highlighting, sadly.

Sad indeed, editing C# code without syntax highlighting is not nice at all.

Agreed. Sadly "extending" on existing languages is not possible in Rider. So we can't re-use what's available for c# and have to re-implement everything. Currently the only IDE supporting auto-complete and highlighting is the Cake extension for VS Code.
(There, that's done via OmniSharp which sadly is not an option for Rider)

So we can't re-use what's available for c# and have to re-implement everything

That completely defeats the point of a rider plugin imo. If you want to use omnisharp, just use vscode.

Sadly "extending" on existing languages is not possible in Rider

Are you sure? Don't know hacky it will be yet, but I'm pretty sure all we have to do is to just "fake" our own C# project to resharper.

Are you sure? Don't know hacky it will be yet, but I'm pretty sure all we have to do is to just "fake" our own C# project to resharper.

This is, in essence, what O# does when processing Cake. I've never tried it that way.. You're very welcome to give it a try.

@garywoodfine The best resource I know is the Custom Language part of the SDK. You'd best start with Implementing a lexer and then continue over the following two chapters.
However, there is also (a bit undocumented, though) the Embedded Language feature. I've always wanted to test if that could be utilized to "overlay" the cake features over any existing language.
On a sidenote: Learning Kotlin was very straight forward for me. In part it's very similar to C# and Java and it is simply a brilliant language. (You can use the IntelliJ in the community edition to work on the plugin.)

Thanks I will take a look and set myself onto a new learning adventure!!