bogus filesizes?

Something is strange with the size using chamelon:
$ sshfs mirage@<IP_ADDRESS>:/ ~/sshfs -p 22022 -o IdentityFile=/home/user/mirage/mirage-sshfs/username && mkdir -p ~/sshfs/test && echo ok > ~/sshfs/test/bla && ls -l ~/sshfs/test && cp ~/sshfs/test/bla ~/sshfs/test/bla2 && ls -l ~/sshfs/test && cat ~/sshfs/test/bla
total 4
-rwxrwxrwx 1 root root 3 Feb 25 12:13 bla
total 8
-rwxrwxrwx 1 root root 3 Feb 25 12:13 bla
-rwxrwxrwx 1 root root 6 Feb 25 12:13 bla2
ok
$ ls -l ~/sshfs/test
total 8
-rwxrwxrwx 1 root root 6 Feb 25 12:13 bla
-rwxrwxrwx 1 root root 6 Feb 25 12:13 bla2

Fixed in chamelon "Update to Mirag_kv 6.0.1" PR.

There still an issue with directory size if computed with the size of all its elements. As we add a fictive '.' file to create an empty directory, we always have a size increased by 1 byte (except '/' where '.' isn't added).
As the directory size is not really defined by Mirage_kv maybe this is not really an issue?


Adjust Uninstallation methods to use a targeted terraform destroy

Problem
The current unity-management-console's uninstallation procedures cause issues when uninstalling marketplace applications whose terraform code involves the use of providers.
When installing/uninstalling the unity-sps suite (unity-sps-eks, unity-sps-karpenter, unity-sps), the management console should be able to handle the following without issues:

install unity-sps-eks
install unity-sps-karpenter
install unity-sps
uninstall unity-sps
uninstall unity-sps-karpenter
uninstall unity-sps-eks

Or, alternatively:

install unity-sps-eks
uninstall unity-sps-eks

Here is an additional link to specifics that we discussed together:
https://developer.hashicorp.com/terraform/cli/commands/plan#planning-options
specifically, the -target=ADDRESS option that can be used with terraform destroy


Reset fields or close the sidebar after adding a new item in a group

Hi,
Not a bug, more like an UX "issue".
Is there a way to reset the fields or close the sidebar after adding a new item in a group?
What I'm expecting is:

Go to groups, create a new one or select an existing group.
Add a new item (App or Link, I haven't tested with a dashboard but I think the behaviour is the same)
Input/Select your fields (App name, Link URL, etc)
Click save. The item is now added to the group.
Reset the fields so the user can start fresh or let the user click outside of the right sidebar to close the sidebar, or autoclose the sidebar.

What happens:

Go to groups, create a new one or select an existing group.
Add a new item (App or Link, I haven't tested with a dashboard but I think the behaviour is the same)
Input/Select/Edit your fields (App name, Link URL, Title, etc)
Click save. The item is now added to the group.
If you select a Link, the fields remain the same after clicking the save button. If you select a (new) app, the fields reset, which is fine (sort of), but when you click the save button the newly added item is overwritten with the new fields that you inputed.

Added to version 0.4.1
When Adding new items (not when editing existing items) there is now a switch to keep the editor open.


UI wont open due to javascript security error

Describe the bug
After installing and running on both local and Docker i get the same behavior of a blank white screen, my browser refuses to run the javascript of the site. I tried changing the permissions in my browser to specifically allow this address but nothing helped.
Browser and Version

Browser Chrome
Version 114.0.5735.134 (Official Build) (64-bit)

To Reproduce
Steps to reproduce the behavior:

I run langflow as per the instructions
Open the browser to http://<IP_ADDRESS>:7860/
All I see is a blank white screen
Open the dev console and see the following error:
" Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec. "

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Same problem.

This problem still exists.
https://github.com/logspace-ai/langflow/issues/353 seems related.
https://github.com/logspace-ai/langflow/issues/353#issuecomment-1809473376 and https://github.com/logspace-ai/langflow/issues/353#issuecomment-1775552569 mention possible solutions, however both haven't worked for me.
Fresh install via pip in a conda environment on windows x64, python 3.10.13.
The blank UI appears in Firefox 120.0.1 (various installed extensions), Microsoft Edge Version 112.0.1722.64 (no extensions) and Google Chrome Version 120.0.6099.71(no extensions).


Support facebook 2factor auth

It would be nice to support facebook's 2 factor authentification.
It currently results to this:
info login Logging in...
ERR! login Couldn't login. Facebook might have blocked this account. Please login with a browser or enable the option 'forceLogin' and try again.

 We need this. See #16 for more


Module compiled with Swift 4.0 can not be imported in swift 3.2.3

I'm unable to import the AcceptSDK in my project.

Hi @Mandeep-vichara, We have updated our SDK. Please update the pod and try again (make sure you run pod repo update first). If you still face the problem please get back to us.

We have updated the code to support Swift 4.2. Please try updating the repository.

Hello, i have updated the pod but it is still showing error.
help me out

i have used this git
https://github.com/hatboysoftware/accept-sdk-ios.git'
is it safe to use ? because i am not able to run my project after updating Pod with your solution.


Unable to find a specification for 'boost-for-react-native' depended upon by Folly

I get the error: Unable to find a specification for 'boost-for-react-native' depended upon by 'Folly' when running pod install
I am creating a Podfile that is identical to the one specified in the docs here
I can see that boost-for-react-native was introduced because of this issue here.
This is the commit that is adding boost-react-native and most-likely causing this error for me. I am not that familiar with podspecs and the specifics of the dependencies of boost vs boost-for-react native, but I'm pretty sure this is the cause.
Is this a bug report?
Yes
Have you read the Contributing Guidelines?
Yes
Environment
Environment:
OS: macOS High Sierra 10.13.3
Node: 8.9.3
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.7.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.2.0 => 16.2.0
react-native: 0.53.3 => 0.53.3
CocaPods version 1.3.1
React Native CLI: 2.0.1
Steps to Reproduce

From CLI: react-native init Temp
Create a new file: ios/Podfile with the following contents:

platform :ios, '9.0'

# Remove this line to see the warnings that happen when calling 'pod install'.
# Refer to this issue: https://github.com/CocoaPods/CocoaPods/issues/4370
install! 'cocoapods', :deterministic_uuids => false

target 'Temp' do

  # Dependencies for react native firebase. Refer to this documentation:
  # https://rnfirebase.io/docs/v2.2.*/installation-ios#2.1)-Add-the-required-pods
  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'Core',
    'CxxBridge', # Include this for RN >= 0.47
    'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
    'RCTText',
    'RCTNetwork',
    'RCTWebSocket', # needed for debugging
    # Add any other subspecs you want to use in your project
  ]

  pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

  # Third party deps podspec link
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'GLog', :podspec => '../node_modules/react-native/third-party-podspecs/GLog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'

  target 'TempTests' do
    inherit! :search_paths
  end

end

cd /path/to/repo/ios && pod install

Expected Behavior
Cocoa pods installs all the dependencies without any errors.
Actual Behavior

Reproducible Demo
Here is the repo with the bug.

same error

I got the same error too.

add  " pod 'boost-for-react-native' " into Podfile , It fix my problem

do a pod update first

same error

Run pod update first, it will update the podspecs so that it will include boost-for-react-native.

I solved it by running pod update, removing the build folder and rebuild the project with yarn/npm.

same error

The pod update solution worked for me. I'm closing this task since it seems to be resolved. Thanks for the help!

not working for me

seems like after running pod update does installation automatically, anyone can confirm?

I'm stuck with version 1.56.0 in my pods folder after clearing build, usual React Native clean of everything and  pod update. Really frustrating.

I had the same error until I added the following line to my projects Podfile:
pod 'boost-for-react-native', :podspec => 'https://raw.githubusercontent.com/react-native-community/boost-for-react-native/master/boost-for-react-native.podspec'

But that smells a bit.


Added default cache rule for assets

Currently, we don't cache assets OOTB, adding a config to start caching images.

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X ] I have signed the Adobe Open Source CLA.
[ X] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@vladbailescu I added this PR to start the conversation about adding a default asset caching rule to the OOTB dispatcher configurations for Cloud Service. I copied the configuration from the Odin files. @gknobloch do you mind reviewing please. @keepthebyte @n-zimmermann FYI

Based on email conversation, closing this PR


json.hpp compilation issue with other typedefs with same name

The issue is similar to #606 and #1530: a compilation error involving json.hpp, with < being interpreted as a template instead of "less than"

Essentially, other typedefs with the same name as the ones used by the library are taken as reference when templating, which happens often under using namespace
This is confirmed to happen with GCC 7.4.0 on Ubuntu and GCC 9.1.0 on macOS Mojave, compiling against the version from apt-get and brew respectively.
A fix would be wrapping the comparisons with parentheses.
Also discovered by @edo9300 and @DyXEL

Thanks for reporting the issue!
This is a reoccurring issue (e.g. https://github.com/nlohmann/json/issues/590, https://github.com/nlohmann/json/issues/606, https://github.com/nlohmann/json/issues/1530) which  strangely, current CI builds haven't detected. For instance, the library are being built with GCC 4 through GCC 9 in Travis CI yet this error remains uncaught.
Can you give more details on the build environment so the error can be reproduced and prevented in the future by setting up a regression build? It would be kind of you if you could reproduce the error on https://godbolt.org (you can set compiler version and build flags there).

@nickaein i made a sample scenario where this happens https://godbolt.org/z/iHJVjA
template <typename T>
class string {
};
#include <nlohmann/json.hpp>
int main() {
	return 0;
}

you can replace that templated class with any of the classes used by this library, and get the same error. Weirdly enough this doesn't happen when compiling for windows https://godbolt.org/z/aoAxd0

@edo9300: Thanks for the example! We might have to add something like this as a regression test.
@kevinlul: I've just noticed you have already opened an PR for this issue. Thanks for that! You might want to add a Fixes #1642 phrase (or other keywords mentioned here) in the description of PR so that gets linked to this issue and automatically close the issue when merged.


adding builtin numerical functions

You think this is generic enough for a start? @larshp
Adding the other builtin numberics in the same way, if so...

this looks good 👍

Fixes #182

👍


Issues with Eigen array header during make

Issue summary
Hello,
When I follow the standard instructions to build gnina on Ubuntu 20.04 (windows WSL) everything goes smoothly until the make command. Then, I receive the following error when building atom_constants.cpp:
[ 48%] Building CXX object gninasrc/CMakeFiles/gninalib.dir/lib/atom_constants.cpp.o
In file included from /usr/include/c++/9/tuple:39,
from /usr/include/c++/9/functional:54,
from /usr/include/c++/9/pstl/glue_algorithm_defs.h:13,
from /usr/include/c++/9/algorithm:71,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/common.h:30,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/atom_constants.h:26,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/atom_constants.cpp:1:
/mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/../Eigen/array:8:4: error: #error The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core.
8 |   #error The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core.
|    ^~~~~
In file included from /usr/include/c++/9/pstl/glue_algorithm_defs.h:13,
from /usr/include/c++/9/algorithm:71,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/common.h:30,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/atom_constants.h:26,
from /mnt/c/Users/[usr]/Desktop/gnina/gnina/gninasrc/lib/atom_constants.cpp:1:
/usr/include/c++/9/functional:1111:29: error: ‘array’ is not a member of ‘std’
1111 |       tuple<_GLIBCXX_STD_C::array<_Tp, _Len>, _Pred> _M_bad_char;
|                             ^~~~~
/usr/include/c++/9/functional:63:1: note: ‘std::array’ is defined in header ‘’; did you forget to ‘#include ’?
62 | # include
+++ |+#include
63 | # include
/usr/include/c++/9/functional:1111:44: error: template argument 1 is invalid
1111 |       tuple<_GLIBCXX_STD_C::array<_Tp, _Len>, _Pred> _M_bad_char;
|                                            ^
/usr/include/c++/9/functional:1111:44: error: template argument 2 is invalid
/usr/include/c++/9/functional:1111:45: error: expected unqualified-id before ‘,’ token
1111 |       tuple<_GLIBCXX_STD_C::array<_Tp, _Len>, _Pred> _M_bad_char;
|                                             ^
/usr/include/c++/9/functional: In constructor ‘std::__boyer_moore_array_base<_Tp, _Len, _Pred>::__boyer_moore_array_base(_RAIter, std::size_t, _Unused&&, _Pred&&)’:
/usr/include/c++/9/functional:1083:4: error: class ‘std::__boyer_moore_array_base<_Tp, _Len, _Pred>’ does not have any field named ‘_M_bad_char’
1083 |  : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
|    ^~~~~~~~~~~
/usr/include/c++/9/functional:1083:33: error: ‘array’ is not a member of ‘std’
1083 |  : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
|                                 ^~~~~
/usr/include/c++/9/functional:1083:33: note: ‘std::array’ is defined in header ‘’; did you forget to ‘#include ’?
/usr/include/c++/9/functional:1083:42: error: expected primary-expression before ‘,’ token
1083 |  : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
|                                          ^
/usr/include/c++/9/functional:1083:49: error: expected primary-expression before ‘{’ token
1083 |  : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
|                                                 ^
/usr/include/c++/9/functional:1083:49: error: expected ‘}’ before ‘{’ token
/usr/include/c++/9/functional: In member function ‘std::__boyer_moore_array_base<_Tp, _Len, _Pred>::__diff_type std::__boyer_moore_array_base<_Tp, _Len, _Pred>::_M_lookup(_Key, std::__boyer_moore_array_base<_Tp, _Len, _Pred>::__diff_type) const’:
/usr/include/c++/9/functional:1105:23: error: ‘_M_bad_char’ was not declared in this scope; did you mean ‘__is_char’?
1105 |    return std::get<0>(_M_bad_char)[__ukey];
|                       ^~~~~~~~~~~
|                       __is_char
/usr/include/c++/9/functional: In member function ‘const _Pred& std::__boyer_moore_array_base<_Tp, _Len, _Pred>::_M_pred() const’:
/usr/include/c++/9/functional:1109:44: error: ‘_M_bad_char’ was not declared in this scope; did you mean ‘__is_char’?
1109 |       _M_pred() const { return std::get<1>(_M_bad_char); }
|                                            ^~~~~~~~~~~
|                                            __is_char
make[2]: *** [gninasrc/CMakeFiles/gninalib.dir/build.make:97: gninasrc/CMakeFiles/gninalib.dir/lib/atom_constants.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1729: gninasrc/CMakeFiles/gninalib.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
Steps to reproduce
git clone https://github.com/gnina/gnina.git
cd gnina
mkdir build
cd build
cmake ..
make
system configuration
Operating system: Ubuntu 20.04 (windows WSL)
nvcc:  V12.2.91

I've added a 20.04 Dockerfile to illustrate building on 20.04: https://github.com/gnina/gnina/blob/master/docker/ubuntu-20.04/Dockerfile
This doesn't do anything special, so I suspect the issue is with your setup.  To me this seems like a problem with the standard libraries not providing array.

I faced the same issue when running make command on WSL2. Please show me the way to address it.

Instructions for WSL2 Ubuntu 22.04 have been added to the readme.

@dkoes I tried your instruction, however, it does not work. Please help me. I created a new issue https://github.com/gnina/gnina/issues/255

@dkoes why do you use cmake 3.18 in dockerfile although your instruction requires cmake 3.25?

That's for Ubuntu 18.04.  The newer versions (and compat) use newer cmake.  I've removed the 18.04 since it is out of support.


Ensure CloudTrail log file validation is enabled

Possible check to target the following resource

[ ] aws_cloudtrail

closing, tracking in spreadsheet

closing, tracking in spreadsheet


target-independent bindings

Currently bindings are restricted to windows and x86_64/x86. This is reflected in the src/ffi/generated.rs:
compile_error!("These bindings can only be used on `x86_64` architectures. To generate bindings for your target architecture, consider using the `regenerate` feature.");

There are two reasons I found for this:

The cty crate depends on the target to create ctype definitions
extern blocks rely on linked symbols and ABIs such as stdcall may not be possible on other targets.

My use case is such that I wish to use structures such as PPEB on non-native targets such as i686-unknown-linux-gnu.
This being the case I forked this repository, which can be found here: https://github.com/Irate-Walrus/phnt-rs
In this fork I introduced a pre-generated x86_64_bindgen.rs and x86_bindgen.rs as well as two feature flags externs and fn_types.
externs allows externally linked symbols to be enabled/disabled:
#[cfg(feature="externs")]
extern "C" {
   pub static GUID_NULL: GUID;
   pub static mut NlsAnsiCodePage: USHORT;
   ...

While fn_types defines the externally linked functions as types:
#[cfg(feature="fn_types")]
mod fn_types {
    pub type NtCallbackReturnFn = unsafe extern "C" fn(OutputBuffer: PVOID, OutputLength: ULONG, Status: NTSTATUS) -> NTSTATUS;
    pub type NtFlushProcessWriteBuffersFn = unsafe extern "C" fn() -> NTSTATUS;
    pub type NtQueryDebugFilterStateFn = unsafe extern "C" fn(ComponentId: ULONG, Level: ULONG) -> NTSTATUS;
    ...

This is helpful if you are trying to call these functions directly in memory:
let rtl_allocate_heap: RtlAllocateHeapFn = core::mem::transmute(rtl_allocate_heap_addr);
let ptr = rtl_allocate_heap(self.handle(), HEAP_ZERO_MEMORY, layout.size() as _)

I've also added to the GitHub workflows to auto-regenerate both x86 and x86_64 bindings and commit them to the repo.
There are a few issues that I've seen so far:

Bad regexes in my build.rs lead to failure with the latest bindgen version 0.71.1
Dropping the use of cty for internally defined ctypes may break compatibility with pre-existing users.
Custom rustfmt to allow for the use of regex when feature-gating externs and function types.

This issue is to gauge your interest in these changes, although it's likely I may continue in the fork to add further definitions from other header files. Thanks for you hard work, it made these changes relatively straightforward.

First of all thanks for the write-up!

The cty crate depends on the target to create ctype definitions

I'm happy to remove cty in the future for custom rolled type definitions.

extern blocks rely on linked symbols and ABIs such as stdcall may not be possible on other targets.

Does your fork address this or is that what the feature guards are for?
I'm not entirely sure what your use case is for using a different target like i686-unknown-linux-gnu, would you like to regenerate the bindings from linux (thinking about Windows headers required on the clang side here) or just use them and be able to disable the function definitions so you can operate on the structures?

In this fork I introduced a pre-generated x86_64_bindgen.rs and x86_bindgen.rs

Good idea! I see you've added the regenerate step to the CI and upload the artifacts from there.
Maybe we should add prebuilt ARM64 bindings as well to support all of the major architectures without having to install C tools and rebuild it.

Merry Christmas! 🎄

Does your fork address this or is that what the feature guards are for?

I use the extern feature guard to prevent linked symbols or incompatible ABIs such as stdcall.

I'm not entirely sure what your use case is for using a different target

See https://github.com/Irate-Walrus/stardust-rs for an example use case. However, I have another use case which involves using some of the defined structs in riscv64 (this resulted in the target_arch checks failing), see https://secret.club/2023/12/24/riscy-business.html .

would you like to regenerate the bindings from linux

I didn't have much luck regenerating on linux and if the bindings are pre-built then I don't need to. In stardust-rsI actually need the function type definitions not the function definitions themselves, due to the regex this meant that function bindings had to be generated.

Maybe we should add prebuilt ARM64 bindings as well.

I'd be keen, I was making the edits on my fork with this in mind. However, there is no Windows ARM64 github runner so we'd probably have to pursue cross-compilation first.

Just realized I'd made a silly mistake regarding imports when using the fn_types feature, resolved now. Also this is the error expected when you compile with externs and have an incompatible ABI:

I'd be keen, I was making the edits on my fork with this in mind. However, there is no Windows ARM64 github runner so we'd probably have to pursue cross-compilation first.

I've managed to build for i686 (x86), x86_64 and aarch64 using windows-2025 GitHub runner. 🥳🎉


modal - update modal paddings and fixed height

How could I contribute with this issue? Are there specs defined for this?


[Draft] Llm on

📝 Description
WIP:
Added Visualization of a description.
pip install openai
Zero-shot of openAI  (need an API key passed as a parameter in the model)
https://ollama.com/download
and
pip install ollama
Zero-shot  and
Few-shot
pip install transformers
Zero-shot of llava
Few-shot of llava -> it doesn't work
Zero-shot of llava-next
Few-shot of llava-next
✨ Changes
Select what type of change your PR is:

[ ] 🐞 Bug fix (non-breaking change which fixes an issue)
[ ] 🔨 Refactor (non-breaking change which refactors the code base)
[X] 🚀 New feature (non-breaking change which adds functionality)
[X] 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] 📚 Documentation update
[ ] 🔒 Security update

✅ Checklist
Before you submit your pull request, please make sure you have completed the following steps:

[ ] 📋 I have summarized my changes in the CHANGELOG and followed the guidelines for my type of change (skip for minor changes, documentation updates, and test enhancements).
[ ] 📚 I have made the necessary updates to the documentation (if applicable).
[ ] 🧪 I have written tests that support my changes and prove that my fix is effective or my feature works (if applicable).

For more information about code review checklists, see the Code Review Checklist.

NIce, whats the performance of any of these models on mvtec ad or visa?


addOptions to list gists forks endpoint

Added test cases to increase coverage

Thank you, @srivignessh. I have a pro-tip for you. Instead of opening and closing multiple PRs until you get all the details perfect (thus artificially bumping up this repo's overall PR count), you can leave the one PR open and commit more changes to it and the tools will rerun tests after each additional commit push.
That has the added benefit that it will reduce all the emails being sent to the (currently) 177 people who are watching this repo.  Thanks!
Are you ready to have this PR reviewed?

Thank you, @gmlewis
I will follow your advice and update the existing PRs with updated commits.
I apologize for the opening and closing multiple PRs
.
Yes, I am ready to get the PR reviewed.

Thank you, @gauntface!
Merging, then bumping major version.


[BUG] Enabling the ability to hide GUIs and changing the group ID sets the toggle to off

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
Normally when changing the group ID to anything other than Bloxstrap's group ID, the toggle would still be shown as on.
However, in a past update (v2.5.1 flying blind,) changing the group ID from that point on would always set the toggle back to off regardless of whether there was an ID present or not.
Despite the toggle being shown as off, you are still granted the ability to hide GUIs for as long as the flag is saved.

Oh, I forgot about this. I'm aware of this, I just forget to actually put this down as something that needs doing whenever I work on a version. I won't forget this time, hopefully.

closed because of recent updates


[Bug]: Race condition possibility with setLocaleIdentifier

Please check the following before submitting a new issue.

[X] I have searched the existing issues.
[X] I have carefully read the documentation and verified I have added the required platform specific configuration.

Please select affected platform(s)

[X] Android
[ ] iOS

Steps to reproduce
In a recent version of flutter-geocoding, instead of passing the locale identifier as part of the request (e.g. placemarkFromCoordinates(lat, long, localeIdentifier), now the user has to first call setLocaleIdentifier(localeIdentifier), and then call placemarkFromCoordinates(lat, long).
This is problematic if (like in my app) the locale identifier is switching frequently, and there may be more than one reverse geocoding call at a given time (basically I need to be able to reverse geocode into several locales at the same time). There is a race condition, whereby two different threads could interfere with each other's geocoding call.
I know this is an unusual usecase, but the chance for race condition is real, and this is not a good API change.
Expected results
Locale should always be passed in the call (as it is in the currently-released version).
Actual results
Locale is passed in a separate initial step, in the git latest version.
Code sample
N/A
Screenshots or video
N/A
Version
N/A
Flutter Doctor output
N/A

Hi @lukehutch,
Thank you for reporting this issue. We completely agree with your reasoning, however this means we need to do a large refactor of the plugin to manage multiple instances over the different platforms (we need to keep the Dart instances in sync with the matching instances on the native platform).
There is a solution for this and we are planning to apply it. However it will take some time. I will keep this ticket open to track the progress.

Hi, I just upgraded to geocoding 3.0.0, and this is still an issue with this new major-version release. Just wanted to ping you to see if there is any progress on the horizon! Thanks :-)

This a big issue. I tried to setLocaleIdentifier but it not working?


TypeError: Invalid attempt to destructure non-iterable instance. In order to be iterable, non-array objects must have a Symbol.iterator method.

  const [camera, setCamera] = React.useState<Camera | null>(null); at line 20 is giving the TypeError of being a non-iterable instance.
Could you suggest another way for handling the state for view's camera variable?

 const [camera, setCamera] = React.useState<Camera | null>(null); at line 20 is giving the TypeError of being a non-iterable instance. Could you suggest another way for handling the state for view's camera variable?

Same problem

Same issue. The current App.tsx sample code does not work with the latest expo libraries.
The "non-iterable" error happens because camera is null on the first render. One workaround is to initialize it immediately and not use useState:
  const camera = new PerspectiveCamera(
    75,
    1, // initial aspect of 1
    0.1,
    1000
  );

    // in onContextCreate
    camera.aspect = width / height;

Hi, i have the same error
ERROR  TypeError: Invalid attempt to destructure non-iterable instance.
In order to be iterable, non-array objects must have a Symbol.iterator method.


MIOpen failed half(5/10) of it's test on non AMD OpenCL platforms.

Hello. I found that MIOpen can be built with the OpenCL backed without ROCm. Doing so on a non ROCm OpenCL (nvidia/intel OpenCL to be pacific) platform will make MIOpen to fail half of it's test. Applying #5 's fix will let MIOpen pass 8 tests(test 5 and 6 failed).
Here is the log.
Is there any chance that this can be fixed so that MIOpen can run on non AMD hardware? I think that it will be a great feature for MIOpen to have. With a cross platform MIOpen, developers can get descent performance via MIOpen on any hardware. Thus make the life of developers easier. And make more people use MIOpen,

@marty1885 Thank you for your question.
At this time MIOpen is planned to be supported only on AMD GPUs.
Having said that, MIOpen is open-source and we very much welcome contributions from the community. Those contributions can be related to improving the existing functionality or adding the support for new platforms.


add support for TLS 1.3 OCSP multi-stapling for server certs

OCSP multistapling for TLSv1.3:
changed resp variable in the the ssl_struct from one DER encoded OCSP response to a stack of responses
server side: added function in s_server code for retrieving the OCSP responses from all certificates in the server cert chain
server side: added function in statem_srvr code to retrieve and return the response for the requested certificate
client side: added verify function for multiple OCSP responses
Checklist

[x] documentation is added or updated
[ ] tests are added or updated

We will need a CLA to be able to accept this PR. https://www.openssl.org/policies/cla.html

Hi!
I have already provided a CLA last October… Anyways, here’s the CLA again.
I hope this is still valid, if not, please let me know and I will create a new one.
Best regards
Michael

Am 12.05.2023 um 10:08 schrieb Tomáš Mráz @.***>:
We will need a CLA to be able to accept this PR. https://www.openssl.org/policies/cla.html
—
Reply to this email directly, view it on GitHub https://github.com/openssl/openssl/pull/20945#issuecomment-1545349258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL6KEQRLRVDNEHJ7F42S4J3XFXVWPANCNFSM6AAAAAAX6QEZ2I.
You are receiving this because you authored the thread.

￼

Ah, Michal Krueger has CLA in our system, but Martin Rauch does not.

Just send the CLA via email :-)

@martinRa2  wrote 11 days ago:

Just sent the CLA via email :-)

For some reason, the CLI hold is still present.

@martinRa2 @DDvO we do not have CCLA confirmation for Martin Rauch yet.

Could you please reopen the pulll request. I have to clarify something and will provide my CCLA as soon as possible.

Could you please reopen the pulll request. I have to clarify something and will provide my CCLA as soon as possible.

It is not closed.

closing pull request and re-open it to get rid of the "CLA missing" tags...

re-opening...

There are several CLA issues remaining. There appear to be multiple different author email addresses in use in this PR. We have a "Michael Krueger" in our cla db and a "Martin Rauch". Some of Martin's commits match the email address on file for the CLA, and some do not. None of Michael's commits match the CLA on file. The commit "Author" fields need to be updated so that the email address matches the CLA on file.

I tried to fix the email address. Now they should fit with the CLAs.

Please squash (most of) the commits.
This may also reduce the number of different email addresses causing "missing CLA" reports.

Hello,
I have restored the original API and added additional tests for the new function. I hopefully fixed also the formatting and other issues.
Please have a look at it and let me know if there are further points.
The CLA should also be fixed. I tried to reduce the commits to Michael's and my private address. Additionally Michael provided a CLA for them.
Please let me know what further steps are required to merge this request.
Best regards,
Martin

This PR has the label 'hold: cla required' and is stale: it has not been updated in 30 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 30 days. Note that this PR may be automatically closed in the future if no CLA is provided. For CLA help see https://www.openssl.org/policies/cla.html

CLAs for Michael and me are already supplied.

close and reopen pull request for CLA

close and reopen pull request for CLA

@martinRa2 The anonymized GitHub e-mails were used to commit some of the commits apparently and these e-mails were not submitted on the ICLA.
Perhaps these commits could be updated to use the regular e-mail of Martin Rauch?

Please also squash the commits where the author is the same and they are just fixups of the code being added.

Looks good except for the commit messages which are confusing and ugly.
I'd suggest:
Added support for OCSP multistapling for 1073152
Added additional OCSP status errors for bd99aba
Fixed some issues from OCSP multistapling support addition for 55d74f0
Additional tests for the ocsp multistapling (_ex) for 6b636f9
(remove the commit message body here which is just a cruft)

I changed the commit message accordingly. Hope it's now clearer

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago

Could you please rebase this on top of fresh master branch?

Could you please rebase this on top of fresh master branch?

I have rebased it. Must the pull request be reopened?

I have rebased it. Must the pull request be reopened?

No, not needed.
Could you please respond to outstanding questions and review comments?

I have rebased it. Must the pull request be reopened?

No, not needed.
Could you please respond to outstanding questions and review comments?

I have adapted the source code as Filip suggested and rebased the project. I hope that helps.

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

Hi,
is there a change that this PR will find its way to the next release?

@martinRa2 Can you please drop the merge commit?

@martinRa2 Can you please drop the merge commit?

Hope I fixed it.

Hello,
can you please give me an update on the status of the PR. Is there a change that it get's into the next release?
Best regards,
Martin

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

Hi @t8m,
I integrated the changes from PR #22192 and rebased it. Is there anything open, which blocks a merge to the main branch?

There seem to be some review comments from @DDvO that are unresolved.

Hello @t8m , hello @DDvO,
sorry I overlooked that there are open points from @DDvO. I hope that I have now everything addressed.
Please let me know what's missing to merge the PR.
Best regards

Hello @DDvO,
thanks for your quick response. I tried to address all your comments. I have not pushed it yet as I'm uncertain how to handle the questions about the extension of the verify parameter.

Hi @t8m,
thanks for review. I had not pushed my last changes yet. I'm waiting to complete the changes requested by @DDvO.

I am afraid we cannot merge half-finished features into master branch. We would have to have a feature branch. How much work would be to at least retain -status_file for single response?

The option -status_file for the s_server app still works. It is missing the support for multiple OCSP responses, for single responses it still works.
I don't think that this should block the merge of this PR. Nevertheless, I will try to extend the option to also support multiple responses. I'm just not sure what the best way would be.
What I noticed is that in the s_server app there is a own parameter section OCSP. In s_client this section does not exist and the parameters are in the section DEBUG. Could I change this?

thanks for review. I had not pushed my last changes yet. I'm waiting to complete the changes requested by @DDvO.

OK.

I am afraid we cannot merge half-finished features into master branch. We would have to have a feature branch. How much work would be to at least retain -status_file for single response?

The option -status_file for the s_server app still works. It is missing the support for multiple OCSP responses, for single responses it still works. I don't think that this should block the merge of this PR. Nevertheless, I will try to extend the option to also support multiple responses. I'm just not sure what the best way would be. Allowing the parameter -status_file multiple times or having multiple responses in the file. Would would you suggest?

OK, it was not clear to me. As the status response in the file must be in the DER format I think it would be preferable to allow using -status_file multiple times on the command line to provide multiple responses.

What I noticed is that in the s_server app there is a own parameter section OCSP. In s_client this section does not exist and the parameters are in the section DEBUG. Could I change this?

Yes, sure.

Hi @t8m,
I'm a little bit confused. I found in the official description of the s_client app on https://www.openssl.org/docs/man3.3/man1/openssl-s_client.html the following description for the -status parameter

-status
Sends a certificate status request to the server (OCSP stapling). The server response (if any) is printed out.

This is what this PR is for. Is it allready implemented?

Hello @t8m, hello @DDvO,
I pushed my changes for the review comments from @DDvO. I think everything should be addresed. Please let me know if there is anything left.
I put the parameters related to OCSP stapling in the app s_client in a own section, therefore I hope it is clear that they are only for this purpose.
I also implemented that the -status_file parameter could be used multiple times to provide OCSP repsonses stored in a file. Only the responses are transmitted, which matches the server certificate and chain.
Regarding your considerations to generalize the changes also in regard to certificate verification, I would address this in separate project as this is out of scope of Michaels and my current project. Please let me know what you think.
Please let me know what left out to merge this PR.

Now all changes are pushed and the project is rebased. Sorry for the delay.

If you open the PR in Files changed view and scroll through it you will see there are a few review comments that are still unresolved.

If you open the PR in Files changed view and scroll through it you will see there are a few review comments that are still unresolved.

Thanks for the hint. I will have a look at it hopefully by end of this week.

Hello @t8m, hello @DDvO,
any news on this topic. It would be great if it could be integrated in the next release.
Best regards,
Martin

Hello @t8m, hello @DDvO, any news on this topic. It would be great if it could be integrated in the next release. Best regards, Martin

@nhorman please consider this for reviewing to include in 3.4 cycle. IMO this is something that could be finalized and merged.

Done, I have the above tracking tasks created to ensure this doesn't fall through the cracks.

@martinRa2 and @t8m, one needs to unfold older parts of this thread from early April in order to see those comments of my earlier review that had been closed prematurely - I re-opened them, adding new comments.

Hello @DDvO, hello @t8m, hello @FdaSilvaYY,
I have pushed my changes so far. They should address most of the review comments.
The extension of the test cases should be the only thing missing.
Please have a look at it and comment on it.
Best regards,
Martin

Hello @DDvO,
thanks for reviewing. I hope I have addressed your comments.
Still open is the point of extending the tests. I hope I could address this in the next days.
After renaming of the EXT_END defien I'm getting the following warning:
test/ext_internal_test.c:17: warning: "EXT_END" redefined
   17 | #define EXT_END(name) { TLSEXT_IDX_##name, TLSEXT_TYPE_out_of_range, #name }
      |
In file included from include/openssl/ocsp.h:65,
                 from include/openssl/x509_vfy.h:31,
                 from include/openssl/x509.h:490,
                 from include/openssl/ssl.h:32,
                 from test/../ssl/ssl_local.h:26,
                 from test/ext_internal_test.c:11:
include/openssl/x509v3.h:640: note: this is the location of the previous definition
  640 | # define EXT_END { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
      |
rm -f test/ext_internal_test

Any hints?
Best regards,
Martin

At the moment just few new comments. I'm on vacation until Aug 25.

Hello @DDvO,
thanks for you reviewing and your comments.
Unfortunately I will be on vacation in September and can not work on it.  Is there a change to get the PR into the autumn release? Is there somebody else who can take over the review?
Best regards,
Martin

At the moment just few new comments. I'm on vacation until Aug 25.

Hello @DDvO, thanks for you reviewing and your comments. Unfortunately I will be on vacation in September and can not work on it. Is there a change to get the PR into the autumn release? Is there somebody else who can take over the review? Best regards, Martin

You are welcome.
Likely I can continue with some reviewing.
Yet there are also others who can and hopefully will, including those who have already done.
Greetings from Nordkapp, Norway

I'm beginning to wonder whether the design of having a separate stack of responses, that is independent of the associated certificates, and may be out of sync with its indices, and may not be possible to match up for lack of issuer certs is the right design. Will discuss within the team before proceeding with the rest of the review.

The current design is inspired by the original single stapling solution. I see no drawback to have the OCSP responses separated. The case where it is not possible to match up because for lack of issuer certs are on server side.
On client side the issuer certificate must be available, because otherwise the certificate could not be verified anyway.
I see also no drawback in regard of performance as the stack of responses has a very limited number of entries.

Also note the style nits reported by the failed CI run Coding style validation / check-style (pull_request).

@DDvO: Since you made a commit to this PR the flag cla required is back or is the CLA from Michael or me expired?

@DDvO: Since you made a commit to this PR the flag cla required is back or is the CLA from Michael or me expired?

Oh, looks like for some weird reason one of my review suggestions turned into a one-line commit 658de4a120735950794f4ce65355bc3aa6edda8f, with
Author: David von Oheimb<EMAIL_ADDRESS>
I suggest merging it with one of your commits to get rid of that silly author attribution.

Regarding the Coding style validation errors, there are some tricky ones, e.g.,
ssl/statem/statem_clnt.c:2891:'if' { 1 stmt }:        s->ext.ocsp.resp_ex = sk_OCSP_RESPONSE_new_null();

If I remove the brackets, it is complaining that they are missing.

Well, the tool is not perfect, so it can produce false positives and negatives, but with that line the new CI run seems fine.
Please check the remaining findings at https://github.com/openssl/openssl/actions/runs/10442100103/job/28916044848?pr=20945

Note also the output of the newly failing CI run https://github.com/openssl/openssl/actions/runs/10442100090/job/28916043652?pr=20945

Regarding the Coding style validation errors, there are some tricky ones, e.g.,
ssl/statem/statem_clnt.c:2891:'if' { 1 stmt }:        s->ext.ocsp.resp_ex = sk_OCSP_RESPONSE_new_null();

If I remove the brackets, it is complaining that they are missing.

Well, the tool is not perfect, so it can produce false positives and negatives, but with that line the new CI run seems fine. Please check the remaining findings at https://github.com/openssl/openssl/actions/runs/10442100103/job/28916044848?pr=20945

I checked the findings in the CI run. My code has either the same format (indent, spaces, etc.) as the surrounding code e.g., include/openssl/tls1.h, or as I mentioned above it complains about the braces and if I remove them it complains about missing braces.

Note also the output of the newly failing CI run https://github.com/openssl/openssl/actions/runs/10442100090/job/28916043652?pr=20945

That's not from code provided by me.

Hello @DDvO ,
I have added the option -status_server_only  to s_server app. This option limits the OCSP response for the server certificate. The option to send all responses to the client is already possible with the already existing option  -status . Therefore, I see no need to add another option.
I hope that fulfills your requirement.

I have added the option -status_server_only to s_server app. This option limits the OCSP response for the server certificate. The option to send all responses to the client is already possible with the already existing option  -status . Therefore, I see no need to add another option.
I hope that fulfills your requirement.

Not fully - for backward compat, -status should keep providing status for the server cert only,
while a new -status_all option should fail for TLS <1.3 and otherwise provide status for the full chain.
See also the suggested doc etc. adaptations.

Regarding the Coding style validation errors, there are some tricky ones, e.g.,
ssl/statem/statem_clnt.c:2891:'if' { 1 stmt }:        s->ext.ocsp.resp_ex = sk_OCSP_RESPONSE_new_null();

If I remove the brackets, it is complaining that they are missing.

Well, the tool is not perfect, so it can produce false positives and negatives, but with that line the new CI run seems fine. Please check the remaining findings at https://github.com/openssl/openssl/actions/runs/10442100103/job/28916044848?pr=20945

I checked the findings in the CI run. My code has either the same format (indent, spaces, etc.) as the surrounding code e.g., include/openssl/tls1.h,

Right, your changes are consistent with existing code, but still
the format (missing spaces and indentation regarding # if) is wrong,
so please change the lines that you touched to comply with the coding style.

or as I mentioned above it complains about the braces and if I remove them it complains about missing braces.

For test/sslapitest.c:1935 the error is a false positive of check_format.pl,
and the errors shown for crypto/objects/obj_dat.h and include/openssl/obj_mac.h are due do bad formatting in the auto-generated code, so those can be ignored here.
Everything else can be resolved by you.

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

Hello @t8m, hello @DDvO, hello @mattcaswell,
luckily I found some time for this project. I addapted the behavior in the requested way. Now the list of OCSP responses are prepared in the correct order already in the app s_server and the general code expects a list with the same order as the certificates and NULL if no OCSP response is available for the respective certificate.
There is still the point about extending the test case, but I would like to wait until you had a change to review the current code and we could agree on that behavior.
It would be great if you could review near-term.
Best regards,
Martin

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 61 days ago


New meta-function: staticSlice

I started using bolts in my openmethods library. Super useful, but I ran short of one meta-function. So here it is.

Nice! This is a great idea!
Since it's very specific to AliasPack, what do you think of putting it inside the template instead? Also the functionality is maybe more pluck and not slice? (as slicing usually means a range of consecutive values - especially in D)
I looked at your usecase as well, and with an method pluck your code would go form this:
    foreach (
      cls;
      openmethods.staticSlice!(
        openmethods.AliasPack!(SpecParams),
        openmethods.AliasPack!(TheMethod.virtualPositions)).Unpack) {
      si.vp ~= cls.classinfo;
    }

to this:
    foreach (
      cls;
      openmethods.AliasPack!(SpecParams)
        .pluck!(TheMethod.virtualPositions)) {
      si.vp ~= cls.classinfo;
    }

Regarding the name, I drew inspiration from Perl. But I find pluck quite cute.
Regarding the arguments and return values...I had the impression that you wanted to work in terms of AliasPacks rather than AliasSeqs. Indeed taking the positions, and returning the values, via AliasSeqs instead of AliasPacks makes the openmethods code fragment much simpler.
OTOH, I find AliasPacks more composable. Essentially, AliasSeq is a Perl list, while AliasPack is a Lisp list. If we keep things "more" packed, we can do some funky Lisp-like things, e.g.:
template staticPlus(Values...)
{
  static if (Values.length == 0) {
    enum staticPlus = 0;
  } else {
    enum staticPlus = Values[0] + staticPlus!(Values[1..$]);
  }
}

template staticApply(alias Fun, alias Pack)
{
  alias staticApply = Fun!(Pack.Unpack);
}

template staticMap(alias Fun, Packs...)
{
  static if (Packs.length == 0) {
    alias staticMap = AliasPack!();
  } else static if (Packs[0].length == 0) {
    alias staticMap = AliasPack!();
  } else {
    static import std.meta;
    alias PackHead(alias Pack) = Pack.Head;
    alias PackTail(alias Pack) = Pack.Tail;
    alias staticMap = AliasPack!(
      Fun!(std.meta.staticMap!(PackHead, Packs)),
      staticMap!(
        Fun,
        std.meta.staticMap!(PackTail, Packs)).Unpack);
  }
}

///
unittest
{
  static assert(staticPlus!(1, 4, 7) == 12);
  static assert(staticApply!(staticPlus, AliasPack!(1, 4, 7)) == 12);

  static assert(staticMap!(staticPlus).equals!());
  static assert(staticMap!(staticPlus, AliasPack!(), AliasPack!()).equals!());

  static assert(
    staticMap!(
      staticPlus,
      AliasPack!(1, 2, 3))
    .equals!(1, 2, 3));

  static assert(
    staticMap!(
      staticPlus,
      AliasPack!(1, 2, 3),
      AliasPack!(10, 11, 12))
    .equals!(11, 13, 15));

  static assert(
    staticMap!(
      staticSlice,
      AliasPack!(AliasPack!(int, char, float), AliasPack!(1, 4, 9)),
      AliasPack!(AliasPack!(0,  2), AliasPack!(1,  2)))
    .equals!(AliasPack!(int, float), AliasPack!(4, 9)));
}

I'm just musing here...I don't know if you want to take bolts down that route.
Regarding free vs member function: obviously I have a bias towards free ;-) My examples above (the PackHead and PackTail aliases) show that free is more composable. They also show that it is trivial to make a free equivalent of a template on the fly. Hey, maybe we should approach Walter and Andrei and suggest UTIS, in addition to UFCS?
One more thing. While working on these examples, I used pragma(trace, Pack.stringof) and the result was not very helpful. Would you be interested in another PR with an AliasPack.stringof method that recursively stringifies the packs?
As for this PR, if after reading this you still feel good about AliasPack.pluck taking and returning tuples, so do I, and I will implement your suggestions. Please let me know...

Regarding the name, I drew inspiration from Perl. But I find pluck quite cute.

Aha. It indeed makes sense in the perl sense. Since you think pluck is cute, let's go with that for now! Another reason is that I tried to use the range operator as a template argument and that doesn't work. So I think I'd like to save staticSlice for a d-style-slice.

I'm just musing here...I don't know if you want to take bolts down that route.

That stuff looks great and I like it! I usually just wait for a use-case to pop up before adding anything so if any of that is needed in user code, and there isn't an already-simpler way to do it, then you'll find no objections here ;)

Regarding free vs member function: obviously I have a bias towards free ;-) My examples above (the PackHead and PackTail aliases) show that free is more composable. They also show that it is trivial to make a free equivalent of a template on the fly. Hey, maybe we should approach Walter and Andrei and suggest UTIS, in addition to UFCS?

I also usually have a preference for free as well ;) Can you envision (or even better if you already have) a case where the free function staticPluck needs composition or benefits from being free over a member?
I'm thinking something like:
staticMap!(ApplyRight!(staticPluck, Positions), sequenceOfPacks);

Would a member pluck that would be...
enum mapFunc(alias pack) = pack.slice!Positions
staticMap!(mapFunc, sequenceOfPacks);

Ok, I think you're right here. Let's keep it free.
Which brings me to:

Regarding the arguments and return values...I had the impression that you wanted to work in terms of AliasPacks rather than AliasSeqs. Indeed taking the positions, and returning the values, via AliasSeqs instead of AliasPacks makes the openmethods code fragment much simpler.

I think my preference is towards the call site when possible. But in this case, I'm now thinking maybe an array of ulong for positions? As that seems a lot more straight forward in this case?
template staticPluck(alias Pack, ulong[] Positions) { ... }

An alias seq of num can be turned to an array by surrounding it with brackets, and typed is (usually) better than untyped. So maybe that?
And the return also I think you're right in that it should stay a pack.

One more thing. While working on these examples, I used pragma(trace, Pack.stringof) and the result was not very helpful. Would you be interested in another PR with an AliasPack.stringof method that recursively stringifies the packs?

Have you seen bolts.traits.StringOf?

maybe an array of ulong for positions?

Yes. good. The reason why I started with the positions in an AliasPack is that I felt that having a trailing list of positions may make things more difficult in the future, because, you know, ... gobbles up everything! What if at some point we want a multi-dimensional pluck?

template staticPluck(alias Pack, ulong[] Positions) { ... }

Are we going for staticPluck or plain pluck? Do you have a naming scheme? E.g. why Flatten, not flatten (it's a function not a type) or staticFlatten (it's compile-time). Personally I find that adding a static prefix to everything may lead to a form of duckspeak.
Let me know what you prefer...

Have you seen bolts.traits.StringOf?

Only after writing my previous post haha.
I pushed a couple of commits (instead of editing history; you can always squash-merge later):

I renamed staticSlice to pluck. Do you prefer staticPluck?
I added a constraint, so that pluck/staticPluck can be overloaded. The downside is that I import std.traits: isInstanceOf. Is that a problem? It's not a public import anyway. Another option is to use a static import. Or from.

Are we going for staticPluck or plain pluck? Do you have a naming scheme? E.g. why Flatten, not flatten (it's a function not a type) or staticFlatten (it's compile-time). Personally I find that adding a static prefix to everything may lead to a form of duckspeak.

I have not thought that much about the naming scheme in meta. I tried to follow phobos more or less. Flatten turned out that way because of Filter from std. My initial thought was a capital letter for functions that operated on type information. But staticMap throws a wrench in that. I agree about the static prefix with you though. So maybe just pascal-case everything in the meta module.
So Zip, Pluck, Flatten, etc.

I renamed staticSlice to pluck. Do you prefer staticPluck? I added a constraint, so that pluck/staticPluck can be overloaded. The downside is that I import std.traits: isInstanceOf. Is that a problem? It's not a public import anyway. Another option is to use a static import. Or from

Good on both accounts. Lazy importing is preferred. But that can go in anther commit. And the naming needs to be thought about more holistically in the meta module I feel now that you bring it up! I'll do that over the next couple days before the next release! Do you have any suggestions other than removing the static prefix?

staticMap throws a wrench in that.

Yeah, it didn't even need the static, as Map would not have conflicted.

So Zip, Pluck, Flatten, etc.

I prefer this to staticThis and staticThat ;-)

Do you have any suggestions other than removing the static prefix?

Not at the moment, but now that bolts is on my radar, I may soon :)


Missed synchronization between kernel completion and subsequent dependent data transfer results in an error

Missed synchronization between kernel completion and subsequent dependent data transfer results in an error
ROCm OpenMP 5.7.1 and earlier may result in a randomly appearing defect that is observable as target regions computing wrong answer/results. This is due to a missed synchronization between kernel completion and subsequent dependent data transfer.
If this behavior is observed, run the application with the following environment variable set:
HSA_ENABLE_SDMA=0
Note: Performance impact may be observed when the above environment variable is used.
Operating System
Ubuntu 22.04 with AMDGPU 6.2.4 driver
CPU
AMD EPYC 7A53 64-Core Processor, AMD EPYC 7313 16-Core Processor, and others
GPU
MI200, MI100, Radeon Pro W6800
ROCm Version
ROCm 5.7.0, 5.7.1
ROCm Component
No response
Steps to Reproduce
No response
Output of /opt/rocm/bin/rocminfo --support
NA

Can you please confirm if this still exists in 6.0? If it was fixed, where was the fix made?

Only from looking at what I believe are symptoms of this, this issue still exists in ROCm 6.0.0 and ROCm 6.0.2 (amdgpu driver version 6.3.6).
Without the mentioned mitigation, we see spurious fails on OpenMP tests. These fails go away when we use HSA_ENABLE_SDMA=0.


Enable setting protectKernelDefaults for kubelet

How to categorize this PR?

/area security certification
/kind enhancement
What this PR does / why we need it:
It is now possible to set protectKernelDefaults in kubelet's configuration. This will also be defaulted to true for shoots with k8s version >= 1.26. This PR is in sync with Kubernetes' STIG. See here for more details.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

It is now possible to configure the `protectKernelDefaults` field for the kubelet configuration in the `Shoot` API via `.spec.{provider.workers[]}.kubernetes.kubelet.protectKernelDefaults`. This will be unset by default for shoots with k8s version < 1.26 and will be defaulted to `true` for shoots with k8s version >= 1.26 once Gardener releases support for these versions.

/area compliance

/test pull-gardener-apidiff

/lgtm
/approve

/test pull-gardener-integration

/test pull-gardener-integration


New version: yt-dlp.yt-dlp.nightly version 2<IP_ADDRESS>706

Created by 🥟 Dumplings in workflow run #1191.
Logs
Updated: 2<IP_ADDRESS>723 → 2<IP_ADDRESS>706
Cannot validate argument on parameter 'ChatID'. The argument is null, empty, or consists of only white-space characters. Provide an argument that contains non white-space characters, and then try the command again.
Submitting WinGet manifests
Cannot validate argument on parameter 'ChatID'. The argument is null, empty, or consists of only white-space characters. Provide an argument that contains non white-space characters, and then try the command again.

Microsoft Reviewers: Open in CodeFlow

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！


[BEAM-13370] [Playground] [Bugfix] Fix/delete prints and unused strings.

Deleted unused prints and strings.
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @pabloem

LGTM


Getting Started with Eigendecomposition in Python

Article checklist
Attention
Our Peer Reviewer and Content Moderator teams do NOT provide any revisions services. All revisions and edits should be completed on your own forked repo (as to not take up room in the queue) in order for our team to review them all in a timely manner.
ANY ARTICLE SUBMITTED WITH GLARING ERRORS WILL BE IMMEDIATELY CLOSED.

As a rule of thumb - please be sure to only submit articles (pull requests) that are fully polished and ready to be published. Be sure to go through our resources documents for extra and 3rd party (vetted) resources to help improve overall technical writing.

Pre-submission checks

Please ensure that you have only one open topic suggestion (issue) + in-review article (linked pull request) at a time. This will ensure that we complete the review process in a timely manner from inception to publishing

If you have not already, please go over our Resources Page for more tips and tricks on how to improve your overall technical writing so reviews are swifter, increase the chance of a payout and provide more value to our readers.

For first-time contributors and for more details on our submission guidelines, see our Contributing Guidelines.

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[x] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels, under 300KB in size, and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[x] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes

Remove the backticks and add the issue number below to link and close your Topic Suggestion (issue) when your article has been published (PR has been merged). See this video for more details.

This closes #5896

Finally, delete the article checklist notes in blockquotes and submit your PR. We look forward to reviewing your article.

@jacksonjate1
The markdown format of these mathematical equations looks incorrect:

Can you verify them please?

@jacksonjate1
The markdown format of these mathematical equations looks incorrect:
Can you verify them, please?

Hello @srishilesh
I think the problem is with the Github markdown compiler. Otherwise, this is how it looks when I open the file on VS code.

@jacksonjate1
The markdown format of these mathematical equations looks incorrect:
Can you verify them, please?

Hello @srishilesh
I think the problem is with the Github markdown compiler. Otherwise, this is how it looks when I open the file on VS code. Same to this  PR

@jerimkaura
Thanks for letting me know. I didn't know that these wouldn't work with GitHub markdown compiler.

@section-engineering-education/peer-reviewers
Is anyone available to pick up this PR? It's been pending for a while.
@jacksonjate1 Please wait until one of our peer-reviewers starts their review process.

I cam review it.
@srishilesh

@section-engineering-education/peer-reviewers
Is anyone available to pick up this PR? It's been pending for a while.
@jacksonjate1 Please wait until one of our peer-reviewers starts their review process.

I can review it.
@srishilesh

@jerimkaura
Thank you.

@jerimkaura
I believe the author has been waiting for a while for the review. Just checking if you could review this. If not, we can re-assign this PR to someone else.

@jerimkaura
I believe the author has been waiting for a while for the review. Just checking if you could review this. If not, we can re-assign this PR to someone else.

Hello @srishilesh
Please assign this PR to someone else. I have enough to work on at the moment.
@section-engineering-education/peer-reviewers

Plagiarism check done ✅

This PR fails to render. Could you check that everything is okay then create a duplicate PR. Thanks

@WanjaMIKE
Have just checked. To my surprise, there is nothing to change. On VS code, everything seems okay.
Kindly, would you consult with @srishilesh?
I think his recommendation was right. I used the same format with this PR #4443. It failed to render on Git markdown but upon publication, everything was okay.

@jacksonjate1 could you recreate a new duplicate PR. Thanks


Client-side deployment

Add jsonnet support and the command appr jsonnet to compile jsonnet files
Add kpm format support
Add client-side deployment and the command appr deploy to trigger deployment and appr remove to teardown
Inprogress server-side deployment (if ran in a k8s server)
Inprogress server-side template expension
Inprogress plain-kubernetes(non-templates) files support
Inprogress helm-client deployment

next:

client-side deployment (kubectl apply)
client-side deployment (tiller)

fixes #50

Codecov Report

Merging #50 into master will decrease coverage by 4.29%.
The diff coverage is 60.11%.

@@            Coverage Diff            @@
##           master      #50     +/-   ##
=========================================
- Coverage   76.64%   72.34%   -4.3%
=========================================
  Files          72       89     +17
  Lines        3481     4528   +1047
=========================================
+ Hits         2668     3276    +608
- Misses        813     1252    +439

Impacted Files
Coverage Δ

appr/models/__init__.py
75% <ø> (ø)
:arrow_up:

appr/platforms/helm.py
0% <0%> (ø)

appr/api/deployment.py
0% <0%> (ø)

appr/commands/remove.py
0% <0%> (ø)

appr/api/builder.py
0% <0%> (ø)

appr/platforms/dockercompose.py
0% <0%> (ø)

appr/api/impl/builder.py
0% <0%> (ø)

appr/api/gunicorn_app.py
0% <0%> (ø)
:arrow_up:

appr/commands/generate.py
0% <0%> (ø)

appr/api/wsgi.py
0% <0%> (ø)
:arrow_up:

... and 99 more

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 3de74e3...3da2f03. Read the comment docs.


Minor cleanup passthrough

Overview
This change contains a variety of minor clean up steps. Mostly documentation links or removing unnecessary namespaces etc.
Vast majority of "file changes" are just meta files for the icon
Remove unnecessary namespace BasePlayModeTests
Bad wording in MixedRealityToolkitConfigurationProfileInspector "Scene System System"
Remove SetDirty on BaseLineDataProviderInspector & related. PropertyFields already handle marking as dirty & history
Simplified access to RenderDocLink via InspectorUIUtility
Added DocLink for PinchSliderInspector, GridObjectCollectionInspector, ToolTipInspector, DependencyWindow
Added inspector & doclink for ManipulationHandler & BoundingBox
Updated all script meta files to use correct MRTK inspector file icon
Changes

Fixes: #4516

Verification

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

/azp run

/azp run


Support for G700s?

Hi everyone, awesome work! I have a Logitech G700s mouse which currently seems to be unsupported. What would be required to add support for that device type?

Hey Florian,
The G700s should be fairly similar to the G700, G500s and G500. To do the first attempts to communicate with the mouse, it should be a matter of just adding your VID/PID in driver-hidpp10.c, and see how it behaves.
I have a G700 that I could access in (roughly) one month, and then I could also have a deeper look at the hid++ 1.0 implementation we have.

I expect it to work like the G500s with maybe a different format for the resolution. You can test tools from this repo too: https://github.com/cvuchener/g500 Results from Reading the memory and Testing some reading request would be interesting.

Did what @bentiss suggested; here's the output (which seems slightly off, although 13 buttons seems to be correct):
$ sudo ./ratbag-command info /dev/input/event8
Device 'Logitech G700s Rechargeable Gaming Mouse'
Capabilities: res profile btn-key btn-macros
Number of buttons: 13
Profiles supported: 3
  Profile 0
    Resolutions:
      0: 46256x17284dpi @ 7Hz
      1: 18084x35968dpi @ 7Hz
      2: 32100x9842dpi @ 7Hz
      3: 13600x25650dpi @ 7Hz
      4: 17288x62136dpi @ 7Hz
    Button: 0 type left is mapped to 'none'
    Button: 1 type middle is mapped to 'none'
    Button: 2 type right is mapped to 'none'
    Button: 3 type thumb is mapped to 'none'
    Button: 4 type thumb2 is mapped to 'none'
    Button: 5 type thumb3 is mapped to 'none'
    Button: 6 type wheel left is mapped to 'none'
    Button: 7 type wheel right is mapped to 'none'
    Button: 8 type resolution up is mapped to 'none'
    Button: 9 type resolution down is mapped to 'none'
    Button: 10 type unknown is mapped to 'none'
    Button: 11 type unknown is mapped to 'none'
    Button: 12 type unknown is mapped to 'none'
  Profile 1
    Resolutions:
      0: 17984x17284dpi @ 7Hz
      1: <disabled>
      2: <disabled>
      3: 13600x12850dpi @ 7Hz
      4: 34576x62136dpi @ 7Hz
    Button: 0 type left is mapped to 'none'
    Button: 1 type middle is mapped to 'none'
    Button: 2 type right is mapped to 'none'
    Button: 3 type thumb is mapped to 'none'
    Button: 4 type thumb2 is mapped to 'none'
    Button: 5 type thumb3 is mapped to 'none'
    Button: 6 type wheel left is mapped to 'none'
    Button: 7 type wheel right is mapped to 'none'
    Button: 8 type resolution up is mapped to 'none'
    Button: 9 type resolution down is mapped to 'none'
    Button: 10 type unknown is mapped to 'none'
    Button: 11 type unknown is mapped to 'none'
    Button: 12 type unknown is mapped to 'none'
  Profile 2 (active)
    Resolutions:
      0: <disabled>
      1: <disabled>
      2: <disabled>
      3: 13600x36864dpi @ 7Hz
      4: 14788x12984dpi @ 7Hz
    Button: 0 type left is mapped to 'none'
    Button: 1 type middle is mapped to 'none'
    Button: 2 type right is mapped to 'none'
    Button: 3 type thumb is mapped to 'none'
    Button: 4 type thumb2 is mapped to 'none'
    Button: 5 type thumb3 is mapped to 'none'
    Button: 6 type wheel left is mapped to 'none'
    Button: 7 type wheel right is mapped to 'none'
    Button: 8 type resolution up is mapped to 'none'
    Button: 9 type resolution down is mapped to 'none'
    Button: 10 type unknown is mapped to 'none'
    Button: 11 type unknown is mapped to 'none'
    Button: 12 type unknown is mapped to 'none'

@cvuchener I also tested your g500 tool; I was able read a 27-page memory dump. Any suggestions where you'd like to have them uploaded?

Upload them any where you want and post the link here or on my github, or send them by email at clement dot vuchener at gmail dot com or both. 27 pages is a lot more than I got with mine, I expect the memory layout will be different.
The 13 button count is hard coded because the G500s has 13 buttons in its profile though only 10 are physically present. It does not mean it worked.

OK, see here: http://floe.butterbrot.org/external/g700s_dump.zip

Again it is a slightly different structure. I had a look at page 2. What I
read is:
5 resolution modes:
0808 2011 resolution = 0x08, leds = off off on
1818 2012 resolution = 0x18, leds = off on on
2828 2022 resolution = 0x28, leds = on on on
4040 1022 resolution = 0x40, leds = on on off
8282 1021 resolution = 0x82, leds = on off off
Some other settings (I expect the default resolution mode and the refresh
rate to be among them)
0180 0110 0201 2c02 5864 ffbc 0009 31
13 buttons
810100 button 1
810200 button 2
810400 button 3
810800 button 4
811000 button 5
812000 button 6
814000 button 7
830300 special
830800 special dpi-
830400 special dpi+
831100 special
830100 special pan left
830200 special pan right
Does that look like one of your profiles? I guess the unknown special
functions are "switch profile" and "battery level".
2015-09-20 9:52 GMT+02:00 Florian Echtler<EMAIL_ADDRESS>
OK, see here: http://floe.butterbrot.org/external/g700s_dump.zip
—
Reply to this email directly or view it on GitHub
https://github.com/libratbag/libratbag/issues/22#issuecomment-141756207.

I started writing the g700s profile documentation :
https://github.com/cvuchener/g500/blob/master/doc/profile/g700s.md
About the memory layout, I found valid profiles in pages 2 to 6 and page 25
and 26. Page 4 has some macros after the profile.
2015-09-20 10:27 GMT+02:00 Clément VUCHENER<EMAIL_ADDRESS>
Again it is a slightly different structure. I had a look at page 2. What I
read is:
5 resolution modes:
0808 2011 resolution = 0x08, leds = off off on
1818 2012 resolution = 0x18, leds = off on on
2828 2022 resolution = 0x28, leds = on on on
4040 1022 resolution = 0x40, leds = on on off
8282 1021 resolution = 0x82, leds = on off off
Some other settings (I expect the default resolution mode and the refresh
rate to be among them)
0180 0110 0201 2c02 5864 ffbc 0009 31
13 buttons
810100 button 1
810200 button 2
810400 button 3
810800 button 4
811000 button 5
812000 button 6
814000 button 7
830300 special
830800 special dpi-
830400 special dpi+
831100 special
830100 special pan left
830200 special pan right
Does that look like one of your profiles? I guess the unknown special
functions are "switch profile" and "battery level".
2015-09-20 9:52 GMT+02:00 Florian Echtler<EMAIL_ADDRESS>
OK, see here: http://floe.butterbrot.org/external/g700s_dump.zip
—
Reply to this email directly or view it on GitHub
https://github.com/libratbag/libratbag/issues/22#issuecomment-141756207
.

2015-09-20 10:51 GMT+02:00 Clément VUCHENER<EMAIL_ADDRESS>
I started writing the g700s profile documentation :
https://github.com/cvuchener/g500/blob/master/doc/profile/g700s.md
About the memory layout, I found valid profiles in pages 2 to 6 and page
25 and 26. Page 4 has some macros after the profile.

I forgot: page 6 has macros too, and page 1 has the same kind of unknown
values found on the other mice.

2015-09-20 10:27 GMT+02:00 Clément VUCHENER<EMAIL_ADDRESS>
Again it is a slightly different structure. I had a look at page 2. What
I read is:
5 resolution modes:
0808 2011 resolution = 0x08, leds = off off on
1818 2012 resolution = 0x18, leds = off on on
2828 2022 resolution = 0x28, leds = on on on
4040 1022 resolution = 0x40, leds = on on off
8282 1021 resolution = 0x82, leds = on off off
Some other settings (I expect the default resolution mode and the refresh
rate to be among them)
0180 0110 0201 2c02 5864 ffbc 0009 31
13 buttons
810100 button 1
810200 button 2
810400 button 3
810800 button 4
811000 button 5
812000 button 6
814000 button 7
830300 special
830800 special dpi-
830400 special dpi+
831100 special
830100 special pan left
830200 special pan right
Does that look like one of your profiles? I guess the unknown special
functions are "switch profile" and "battery level".
2015-09-20 9:52 GMT+02:00 Florian Echtler<EMAIL_ADDRESS>
OK, see here: http://floe.butterbrot.org/external/g700s_dump.zip
—
Reply to this email directly or view it on GitHub
https://github.com/libratbag/libratbag/issues/22#issuecomment-141756207
.

I added a tool: logitech-raw-command, it should be easier to use that send-raw-request.
I also added a script using it. Could you send the output of ./scan-read-command.sh /dev/hidrawN?

$ ./scan-read-command.sh /dev/hidraw0
Error: 1
$ ./scan-read-command.sh /dev/hidraw1
Command 0x00: short
00 00 00
Command 0x01: short
00 00 00
Command 0x07: short
00 22 00
Command 0x0f: short
00 02 00
Command 0x51: short
00 00 00
Command 0x61: short
00 10 00
Command 0x63: long
14 00 14 00 80 01 01 00 00 00 00 00 00 00 00 00
Command 0x64: short
08 00 00
Command 0xa2: long
7b ff bd bf 3d bb 68 76 b2 9e a7 ff ef ef 6d ec
Command 0xd0: short
00 00 00
Command 0xd3: long - unavailable
Command 0xd5: long - unavailable
Error: 3

P.S. actually, I've never used that mouse with Windows or any Logitech tool, so I don't even know how the profiles look.

You can just press them and see what happens. The buttons are numbered and we may assume there are in the same order in the profile. From what I see on the web G8 should show the battery level (830300) and G11 switch profile (831100). G9 and G10 should change the resolution mode.
Does the LED change when you switch resolution or profile? Does either ./logitech-raw-command /dev/hidraw1 0x07 read short or ./logitech-raw-command /dev/hidraw1 0x51 read short change with the LEDs?
When you switch profile does the output of ./logitech-raw-command /dev/hidraw1 0x0f read short change?
We need to find how resolution is encoded. Look at ./logitech-raw-command /dev/hidraw1 0x63 read long with different resolution. If you don't know the resolution, measure it with mouse-dpi-tool in libedev-utils or this program (trace a line of a certain length on a sheet of paper, start the program with the event dev and line length in inch, right click at the beginning of the line and left click at the end).

I wrote in this file: https://gist.github.com/cvuchener/a5a8083a1e1ffa6cd435 what I understand of the profiles in the memory dump (number between parentheses are offset (for referencing macros) not data from the memory). Do they match with what your mouse do? Also for each profile try ./logitech-raw-command /dev/hidraw1 0x64 read short, do the output look like the "refresh rate?" value in the profiles?

I think the g700s is pretty interesting to look closer at. It has some feature that none of the mice I have access to have:

LEDs can set both color and brightness. Perhaps that is what the value in byte 3 of the G9 is for.

Each profile can have a shift (sniper mode) DPI level. Holding the shift button will temporarily go the the selected DPI level. Should be a value like the Default DPI setting.

A toggle for per-axis DPI (does the g500 have this setting?)

A toggle for acceleration

A setting for "Power mode"

If we can understand those we might be able to fill in some blanks in the docs for the g500.

LEDs can set both color and brightness. Perhaps that is what the value in byte 3 of the G9 is for.

I don't think there is a color setting: http://support.logitech.com/article/41587. And there is no color in the first three bytes of the profile. The 0x57 command is not present.

Each profile can have a shift (sniper mode) DPI level. Holding the shift button will temporarily go the the selected DPI level. Should be a value like the Default DPI setting.

Done in the driver not the hardware.

However, the DPI Shift function is only available in Automatic Game Detection mode.

From the same page as above.

A toggle for per-axis DPI (does the g500 have this setting?)

It not a toggle in the profile structure, the resolution is simply repeated twice.

A toggle for acceleration

Maybe byte 1 in command 0x61 and byte 36 in G500 profile structure.
The unknown special button may be "DPI cycle".

The third byte in the items of page 1 match the LEDs for the profile;
02 00 01 -> binary 0001
03 00 03 -> binary 0011
04 00 07 -> binary 0111
05 00 06 -> binary 0110
06 00 04 -> binary 0100
ff ...

For testing notification bits:

try setting all bits with ./logitech-raw-command /dev/hidraw1 0x00 write short FF FF FF
read what bits were effectively set ./logitech-raw-command /dev/hidraw1 0x00 read short

For testing feature bits:

try setting all bits with ./logitech-raw-command /dev/hidraw1 0x01 write short FF FF FF
read what bits were effectively set ./logitech-raw-command /dev/hidraw1 0x01 read short

@floe I just pushed the initial support of the G700 (not 's') to libratbag. Adding the G700s should be a matter of adding it to the hwdb now. Reading the profiles should work. The macros are not parsed nor the consumer control keys, but this is just an implementation detail :)
There is still no support for writing settings. I made it work on the G502, and I hope that the hid++ 1.0 devices should be also easy as soon as the writing of the profile is coded.
Thanks everyone for helping reverse engineering the memory mapping of the profiles :)

Closing as it seems the support is now the same between this model and the G700 (not s). We are still lacking macro writing support, as all other Logitech devices.


incorrect equivalence axiom for hominy

Discovered by @wdduncan in ENVO build: https://github.com/EnvironmentOntology/envo/pull/1240
http://purl.obolibrary.org/obo/FOODON_03310226 hominy
equivalentTo
'corn food product' or 'corn (on-the-cob, kernel or parts)'
this is clearly incorrect and is causing equivalence between named classes:

My immediate recommendation is that after fixing this, use robot to fail fast if equivalencies detected
See
http://robot.obolibrary.org/reason#equivalent-class-axioms
Also https://douroucouli.wordpress.com/2018/09/04/debugging-ontologies-using-owl-reasoning-part-2-unintentional-entailed-equivalence/
My next recommendation would be to very careful with equivalence axioms. Only use them if the term conforms to a documented DP
If the term doesn't have an or in the label, be suspicious of any class forming to a A or B equiv axiom
See also

https://douroucouli.wordpress.com/2019/07/29/ontotip-dont-over-specify-owl-definitions/
https://douroucouli.wordpress.com/2019/07/08/ontotip-write-simple-concise-clear-operational-textual-definitions/, specifically S11

it is a red flag if text and logical definitions don't match
Hominy is a food produced from dried maize (corn) kernels that have been treated with an alkali, in a process called nixtamalization (nextamalli is the Nahuatl word for "hominy").
!=
'corn food product' or 'corn (on-the-cob, kernel or parts)'
Consider a DP for produced-by-process
remember it's better to have no equivalence axiom than an incorrect one

I think this is a case of two errors - the "or" is supposed to be an "and", and the equivalency mistakenly got applied to the wrong entity.  This equivalency is removed; I'll get it rolled out to OntoBee etc.
Thx for robot tip. I'll explore what the equivalency report yields.  I'm thinking we want inferred equivalencies but not explicit ones - which I presume occur when one accidentally puts a disjunction between atomic entities in the equivalency expression.

Also, I've run the robot equivalency report and found a number of other equivalency errors related to the new plant_part_import.owl file we did, so thanks for that tip.  Going forward releases will be tested against this report.


⚠ Alchemy Unbound API has degraded performance

In 0b1d713, Alchemy Unbound API ($API_URL?token=$API_TOKEN) experienced degraded performance:

HTTP code: 211
Response time: 572 ms

Resolved: Alchemy Unbound API performance has improved in e6cd7ff after 12 minutes.


Minor issues

Hi,
there were some typos and bugs in your code.
I took the liberty to fix them for you. 😉
Well, actually, Feram did it.
It’s a tool that we developed to fix our own code.
If you want to use it as well, it’s really simple to integrate:
feram.io/help/getting-started
Hope you like it! 😁

This technically adheres to Ruby standards but doesn't adhere to Homebrew's, which follows the Rubocop style guide with some customisations, FWIW.

The args and the :tags simplifactions look definitely useful!?

You're welcome to discuss it with the person who maintains this tap, I have absolutely no power here. Just saying the changes don't adhere to Homebrew standard, as you can see yourself from the ~4500 examples here.

Thank you for your contribution, @adius.
Personally, I prefer the contemporary Ruby style of single quotes when not using string interpolation, leaving hashrockets in the past, etc.
But in the context of this repo -- a Homebrew formula -- let's stick with the style enforced by brew audit --strict https://raw.githubusercontent.com/valhalla/homebrew-valhalla/master/Formula/valhalla.rb.
If you'd like to propose any functionality changes, please do open a PR at any time!


etcd roles fail because of misconfigured ssl directory

Is this a BUG REPORT:
Environment:

OpenStack

OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"):

core@kube-master-01 ~ $ printf "$(uname -srm)\n$(cat /etc/os-release)\n"
Linux 4.7.3-coreos-r2 x86_64
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1235.5.0
VERSION_ID=1235.5.0
BUILD_ID=2017-01-08-0037
PRETTY_NAME="Container Linux by CoreOS 1235.5.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Version of Ansible (ansible --version):

(env) LP-XLANGE-OSX:kargo-deuce xlange$ ansible --version
ansible 2.2.0
  config file = /Users/xlange/code/viasat/itsec-kube/kargo-deuce/ansible.cfg
  configured module search path = Default w/o overrides

Kargo version (commit) (git rev-parse --short HEAD):
(env) LP-XLANGE-OSX:kargo-deuce xlange$ git rev-parse --short HEAD
5fd2b15

Network plugin used: flannel
Copy of your inventory file:
kube-etcd-01   ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-etcd-02   ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-etcd-03   ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-master-01 ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-master-02 ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-master-03 ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-node-01   ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-node-02   ansible_ssh_host=<IP_ADDRESS> ansible_become=true
kube-node-03   ansible_ssh_host=<IP_ADDRESS> ansible_become=true

[kube-master]
kube-master-01
kube-master-02
kube-master-03

[etcd]
kube-etcd-01
kube-etcd-02
kube-etcd-03

[kube-node]
kube-node-01
kube-node-02
kube-node-03

[k8s-cluster:children]
kube-node
kube-master
etcd

Command used to invoke ansible:
ansible-playbook -i inventory/inventory cluster.yml

Output of ansible run:
https://gist.github.com/xrl/c1882913d0f875ab8ea583e2501df6a9
Anything else do we need to know:

I have local changes to the kargo project:
(env) LP-XLANGE-OSX:kargo-deuce xlange$ git diff
diff --git a/ansible.cfg b/ansible.cfg
index 2f5d25d..b5c7722 100644
--- a/ansible.cfg
+++ b/ansible.cfg
@@ -5,5 +5,5 @@ pipelining=True
 [defaults]
 host_key_checking=False
 gathering = smart
-fact_caching = jsonfile
-fact_caching_connection = /tmp
+#fact_caching = jsonfile
+#fact_caching_connection = /tmp
diff --git a/inventory/group_vars/all.yml b/inventory/group_vars/all.yml
index 308922a..1a6f4b0 100644
--- a/inventory/group_vars/all.yml
+++ b/inventory/group_vars/all.yml
@@ -1,5 +1,5 @@
 # Valid bootstrap options (required): ubuntu, coreos, centos, none
-bootstrap_os: none
+bootstrap_os: coreos

 # Directory where the binaries will be installed
 bin_dir: /usr/local/bin
@@ -141,8 +141,8 @@ dns_mode: dnsmasq_kubedns
 resolvconf_mode: docker_dns

 ## Upstream dns servers used by dnsmasq
-#upstream_dns_servers:
-#  - <IP_ADDRESS>
+upstream_dns_servers:
+ - <IP_ADDRESS>
 #  - <IP_ADDRESS>

 dns_domain: "{{ cluster_name }}"
diff --git a/roles/docker/tasks/set_facts_dns.yml b/roles/docker/tasks/set_facts_dns.yml
index 03cd987..15e6ccf 100644
--- a/roles/docker/tasks/set_facts_dns.yml
+++ b/roles/docker/tasks/set_facts_dns.yml
@@ -50,7 +50,7 @@

 - name: check number of nameservers
   fail: msg="Too many nameservers"
-  when: docker_dns_servers|length > 3
+  when: docker_dns_servers|length > 5

 - name: check number of search domains
   fail: msg="Too many search domains"

This looks not good:
[etcd]
kube-etcd-01
kube-etcd-02
kube-etcd-03

[kube-node]
kube-node-01
kube-node-02
kube-node-03

[k8s-cluster:children]
kube-node
kube-master
etcd

Kargo thinks of the k8s-cluster as the master and minion nodes. If anything else put there, like etcd group members, which are neither master not minion nodes, that will likely cause certificates related errors, like you have had. Please try to remove etcd from the [k8s-cluster:children]

@bogdando thanks for the help, I built my inventory using the documentation here: https://github.com/kubernetes-incubator/kargo/blob/master/docs/ansible.md#inventory . But the inventory.example that comes in the code is as you described, no etcd in k8s-cluster:children group.

@xrl, Oh, that looks like a docs bug. Anyway, if the etcd group is placed into the k8s-cluster children, the etcd group is expected to be contained in the k8s-node group:
if k8s-cluster ⊂ etcd => kube-node ∩ etcd = kube-node


Feature/defensive coach

[x] The tests are passing

Summary
Assigns defensive positions and defenders that go there. Still far from complete, but should be a good start for passive defenders, much like how the 'passive' keeper works half-decently. Especially work integrating the ball possession and pass detection is still required, though the first starts for that should be in other branches already.
Related issues
If there are related issues, reference them here.
fixes ...
fixes ...
Comments for the reviewer
If there are comments for the reviewer, leave them here
Checklist for the reviewer
This acts as a guide to help you and/or the reviewer to analyze the code.
functionality

Is the code is properly tested?
Is the code working as expected
Is the code is understandable and easy to read
Are proper abstractions made? (no duplicate code, nice use of functions/objects)

style

Variables/objects/classes have proper names
Proper use of variables: nu unused vars, no magic numbers
No possible memory leaks. Mutexes properly used when multithreading? possible pointer issues?
Are smart pointers used?
unused variables?
magic numbers?
well documented?
No unused imports?
No leftover code / unused comments
Proper indentation
Proper use of namespaces

replaced by #252


[stable/mychartname] [#20508] Allows the override of the etcd-cluster docker image usd

… etcd-operator to populate the repository used by the etcd cluster.
What this PR does / why we need it:
I need to use locally hosted docker images due to a corporate requirement that images are configuration managed and vulnerability scanned for use on our aws cluster. I attempted to set the .Values.etcdCluster.image.repository to localdockerregistry.internal.example.com/coreos/etcd
Which issue this PR fixes

fixes #20508

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @alejandroesc
@lachie83
Hey please could you look at this for me

/assign @alejandroEsc

The changes here seem a bit drastic, could we add in a conditional statement that allows you to pull the images as you suggest?

Hi @alejandroEsc,
I disagree it is drastic, it is simply removing some values from the values.yaml which aren't being used anymore, and populating the etcdcluster CRD with the value it is populated with by the etcd operator if it is empty.
This line shows the go structure the crd is unmarshalled into
I would agree that making the helm chart provide a default image to the etcd operator means the etcd operator can now longer make it's own decision about what image to use if not set.
Would you rather have the repository value behind a conditional so it is only written into the CRD if it is set? If that is the case would I not add it into the read me.md?
I do think the existing 'image' section in the values section needs to be deleted still because it is misleading.

Hi @alejandroEsc,
Thanks for the review :)
I disagree it is drastic, it is simply removing some values from the values.yaml which aren't being used anymore, and populating the etcdcluster CRD with the value it is populated with by the etcd operator if it is empty.
This line shows the go structure the crd is unmarshalled into
I would agree that making the helm chart provide a default image to the etcd operator means the etcd operator can now longer make it's own decision about what image to use if not set.
Would you rather have the repository value behind a conditional so it is only written into the CRD if it is set? If that is the case would I not add it into the read me.md?
I do think the existing 'image' section in the values section needs to be deleted still because it is misleading.

Alright. Let me take a closer look. I have a few things and another PR to review but will get back to this soon. Again, I appreciate the contribution, no harm intended. Just keep in mind that I would like to avoid breaking changes if possible and only introduce them if necessary. Will get back to you soon.

hey @lachie83 @alejandroEsc ,
was there anything you'd like me to do with this PR that might be preventing it from getting merged?
I did think about making the new repository value optional, but the version value is also populated by default by the etcd-operator, and we're providing that as the default values, so not sure that is the best solution.

Hi @alejandroEsc
This PR duplicates the changes found in
https://github.com/helm/charts/pull/20084
https://github.com/helm/charts/pull/20082/
I've copied the changes both into the chart (to avoid clashing with the Chart.yaml versioning)
I've also made the changes hide behind a conditional which was one of your reasons for hesitating with this change, could you confirm you are happy now?

/ok-to-test

Hey guys had an issue, then vacation then a release, so I havent had a chance to review. Please do not merge until i have a say. Thank you.


Allow mounting results pane separately

Currently the search results pane (in the included Pagefind UI) is tied to the search input; it would be nice if it could be (optionally) placed separately.
Maybe something like:
new PagefindUI({
    element: "#search",
    results: "#search_results"
});

when you don't want the default current behavior.

This is a great suggestion, I'll aim to implement this in the next feature release 🙂

Hi @kenmorse — the latest release didn't touch on the UI much, but this is still on my list. There are a few UI-specific tasks lined up that I'll work on as a unit.

@bglw — sounds good!

This would be absolutely wonderful 🙇
I spent a few hours 😓 trying to get the search results to show up nicely and I'm still fighting the default UI :trollface:
The challenge I have is that I want my search to appear in the navigation, but the results to appear outside of the nav section 😊

Hi @kenmorse and @whyboris  — I've landed on not adding this to the current default UI, and instead offering it as part of a new Modular UI package. A first look at that can be seen in the release notes for v0.11.0 — have a look through that and let me know your thoughts.

🙇  Thank you @bglw for the update!
I tested it out and it's working beautifully 😍
https://github.com/whyboris/utilitarianism.net/pull/85

Removing this from the 1.0 milestone as the Modular UI is now targeting a later release (see https://github.com/CloudCannon/pagefind/pull/382)
(The modular UI as it exists is still being released and is usable, but it will be reworked in a future non-major release)