NIFI-12853 Refactor FlowFilePrioritizer using updated Java APIs

Summary
NIFI-12853
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[x] Build completed using mvn clean install -P contrib-check

[x] JDK 21

Licensing

[x] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[x] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[x] Documentation formatting appears as expected in rendered files

Reviewed this and the code LGTM. I tested all 4 prioritizers before and after this change and functionality remained the same. I also setup some performance tests in the unit tests before and after, and saw no significant differences in performance.
+1 merging.


feat: add configurable duplicate form submission check

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


tests: Just "q35" type is a common machine type across images

Signed-off-by: Kedar Bidarkar<EMAIL_ADDRESS>
What this PR does / why we need it:
RHEL images would not have pc-q35-3.0 as machine types, rather it would have  pc-q35-rhel7.6.0 , pc-q35-rhel8.0.0, e.t.c
We encountered this issue while running these tests on CNV builds.
qemu-kvm: -machine pc-q35-3.0,accel=kvm,usb=off,dump-guest-core=off: unsupported machine type\nUse -machine help to list supported machines'

The supported machine types on RHEL virt-launcher pods are as below:
sh-4.4# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.0 (Ootpa)
sh-4.4# /usr/libexec/qemu-kvm -machine help
Supported machines are:
pc                   RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0)
pc-i440fx-rhel7.6.0  RHEL 7.6.0 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-rhel7.5.0  RHEL 7.5.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.4.0  RHEL 7.4.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.3.0  RHEL 7.3.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.2.0  RHEL 7.2.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.1.0  RHEL 7.1.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.0.0  RHEL 7.0.0 PC (i440FX + PIIX, 1996)
q35                  RHEL-8.0.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.0.0)
pc-q35-rhel8.0.0     RHEL-8.0.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.6.0     RHEL-7.6.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.5.0     RHEL-7.5.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.4.0     RHEL-7.4.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.3.0     RHEL-7.3.0 PC (Q35 + ICH9, 2009)
none                 empty machine

So, thinking we could make use of just q35 which is common to both RHEL and non-RHEL virt images.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

The possible problem I see there is that the "q35" alias is very much akin to a floating tag: the content isn't fixed in time, and changes depending on which version of QEMU is actually running. On the other hand, using a specified version (e.g. pc-q35-3.0) we have much stronger guarantees.
But AFAICT we don't really need these guarantees in tests, so I think this patch is good and can be merged, since it solves a real issue.

ci test please

ci test please

I raised this PR assuming, the output from the running VM would match, with the one set in the vmi spec file. But it looks like the exact value pointed by the variable is being fetched when runningVMISpec.OS.Type.Machine is being used.
[kbidarka@localhost ~]$ oc get vmi vmi-fedora-cdisk -o yaml | grep -i "     type"
      type: q35

I did test it and the tests now pass successfully,
------------------------------
• [SLOW TEST:27.314 seconds]
Configurations
/home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:49
  with machine type settings
  /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1080
    should set machine type from VMI spec
    /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1093
------------------------------
• [SLOW TEST:29.337 seconds]
Configurations
/home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:49
  with machine type settings
  /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1080
    should set default machine type when it is not provided
    /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1103
------------------------------
• [SLOW TEST:30.620 seconds]
Configurations
/home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:49
  with machine type settings
  /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1080
    should set machine type from kubevirt-config
    /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1113
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
Waiting for namespace kubevirt-test-default to be removed, this can take a while ...
Waiting for namespace kubevirt-test-alternative to be removed, this can take a while ...

Ran 3 of 340 Specs in 121.396 seconds
SUCCESS! -- 3 Passed | 0 Failed | 0 Pending | 337 Skipped

ci test please

/retest

@cynepco3hahue, I had tested it and it had worked, my bad, for some reason, my changes didn't get pushed.
I just pushed my changes.

To test the logic, I intentionally failed the test case.
• Failure [45.313 seconds]
Configurations
/home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:49
  with machine type settings
  /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1080
    should set machine type from VMI spec [It]
    /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1093

    Expected
        <string>: pc-q35-rhel8.0.0
    to contain substring
        <string>: pc-q36

    /home/kbidarka/go/src/kubevirt.io/kubevirt/tests/vmi_configuration_test.go:1100

@kbidarkar can you check if you were looking into an old build result? What was the exact url?

@kbidarkar is this still something which needs to be fixed?

Closing this PR in favor of https://github.com/kubevirt/kubevirt/pull/2719


On the Android browser, inserted numbers are doubled if the user press the keys quickly on the virtual keyboard

I use autoNummeric on hybrid project application and has an issue on samsung device.
When user press fast, numbers insert incorrect. They have been inserted double

Hey @kenshichi, thanks for reporting this.
Could you tell us more about that problem so that we could try to reproduce it?
What happens exactly?
Which version of autoNumeric are you using?
Which browser?
Which version of Android too?
A codepen would be great!
Thanks

Hi @AlexandreBonneau,
I use the lastest version of autoNumeric. I embed to my Hybrid Application (jquery mobile and mobilefirst) and build for android, ios.  Everything looks like good till when I build to android app and run it on
Samsung smartphone: SamSung S6, Android 6
If I press slowly, not problem but when I press faster or press 2 key in once time, the number has been duplicated. Press 2 numbers, it insert 4 numbers, more and more duplicate... I was test on multi device and it's only problem on samsung device with default virtuarl keyboard
please help me fix this issue

We're experiencing this bug as well. We're planning to look into it this week. When we find and fix the problem, we'll fork and create a PR

Thank you very much.
On Thu, Mar 23, 2017 at 3:49 PM Michiel van Roon<EMAIL_ADDRESS>wrote:

We're experiencing this bug as well. We're planning to look into it this
week. When we find and fix the problem, we'll fork and create a PR
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/BobKnothe/autoNumeric/issues/404#issuecomment-288653722,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFQuKjh8L0DRIM0oE4Vnc69-SdfSmHObks5rojIzgaJpZM4MJgr8
.

--
Mr_Đức_Nguyễn......< Kenshichi >

Because chrome android browser does not throw the "keypress" event you may need to add support for the "input" and correct improper character insertion.
We appreciate any help and contribution to the code.

@BobKnothe we might be better of getting refactoring the code a bit and getting rid the keypress event handler (#400). Agreed?

@mvanroon, @kenshichi,
Well we have been working on the and would appreciate some user testing.
http://www.decorplanit.com/android/index.html
this is on version 2.n and will be ported to version 4 in the near future

@BobKnothe fixed that issue in the latest commit mentioned above.
If you feel there still is a problem, feel free to reopen this issue.

I'm still having this issue on beta16.  Anyone still get this issue?

I just encountered this issue on 4.0.3 when testing on chrome on android.  I switched to latest stable version 2.0.13 and it seems to be working ok on android now.  Haven't tested iOS yet.

For info, this regression bug is tracked on https://github.com/autoNumeric/autoNumeric/issues/522.


Initial provider token fixes.

fixes #42

CC @weissi @itcohorts @MaciejGad

OKay so @weissi Tests currently break. I advancing time forward doesn't actually change DispatchTime.now()
So im not really sure how I could validate that it works via tests.
My manual testing worked perfectly though.


Update to latest sdk version 1.3.0

This PR updates ts sdk to the latest version where we use number types for transaction options parameters. https://github.com/aptos-labs/aptos-ts-sdk/pull/248
With this change the legacy code still converts transaction option parameters to BigInt for wallet backward compatibility, but for any usage with the new sdk we use the number type.

What about the version file?

what version file?

What about the version file?

what version file?

Oh woops, I thought this was the SDK.
We need to also update SDKv1 into here to fix it entirely

What about the version file?

what version file?

Oh woops, I thought this was the SDK.
We need to also update SDKv1 into here to fix it entirely

I dont think so. This is for a project that uses the new sdk, legacy code functions the same


[Testing] Add debugging feature which leaves integration test containers running after test completes

Motivation
For debugging purposes, it is useful to have the ability to leave the integration test containers running after the test completes. For example, this feature was necessary in investigating the issue #9622 . It was possible to view the log files and find out the issue. If the containers are killed, this options is lost.
Modifications
Testcontainers has a feature to disable "Ryuk", the automatic container cleanup which usually kills all containers started by Testcontainers after the JVM shuts down.
This mode can be activated by setting environment variable TESTCONTAINERS_RYUK_DISABLED=true.
This Testcontainers feature doesn't make a difference when the test code itself stops the containers. Therefore there should be handling in the test code itself to skip stopping of containers for debugging purposes.
The modifications in this PR skip stopping PulsarContainer and PulsarCluster instances if environment variable TESTCONTAINERS_RYUK_DISABLED=true  .
Usage example
In unix shells, one can pass environment variables by prepending the command with the variables:
TESTCONTAINERS_RYUK_DISABLED=true mvn -B -f tests/pom.xml test -DintegrationTests -DredirectTestOutputToFile=false -DtestRetryCount=0 -DfailIfNoTests=false -Dtest=CLITest

After the test run, one can use docker ps and docker exec -it [container_name] bash to get a shell in the running container that was left behind the test run when this feature introduced by this PR is active.
When container cleanup is disabled, one can use this command after debugging to kill docker containers started by Testcontainers:
docker ps -q --filter "label=org.testcontainers=true" | xargs -r docker kill

It would be wonderful if we can add the description into the test README.md, that would be helpful for others who want to debug the tests.

@zymap Makes sense. I was thinking of updating the README later. I have plans to add features for enabling attaching a debugger to a container as well as enabling the use of JConsole / Java Mission Control / Java Flight Recorder by enabling JMX for the JVMs in a configurable way. The README could be updated at that time to also cover the feature of this current PR.

/pulsar run-failure-checks

/pulsarbot run-failure-checks

@lhotari TBH I would advice against this approach. There is no guarantee that the JVM hook will be using stop() (we thought about terminating multiple containers by the session label filter). Not to mention that Ryuk generally should not be disabled, unless your CI does not support it (the reason why the flag was added on a first place).
If you need to the container to remain running, consider using the reusable containers mode.

@bsideup Thanks for your comments. In this case, the changes in this PR aren't meant to be used in CI at all. The reason to leave the container running is to debug an issue locally. I've had the impression that it's the reason why TESTCONTAINERS_RYUK_DISABLED=true exists. At least, that's how I've been using it in the past.
Would you also recommend using the reusable container mode for also for the debugging use case that I have described? I guess that would require also enabling testcontainers.reuse.enable in ~/.testcontainers.properties?
I have one concern. The problem with reusable container mode is that it impacts the execution. I'd simply like to leave the containers after the test and the test JVM completes so that I could open a shell to the container and inspect the state. Perhaps this would be a feature request for Testcontainers?
Is there a workaround with reusable containers by adding a random label to the container etc so that the container would never get reused?

@lhotari

I've had the impression that it's the reason why TESTCONTAINERS_RYUK_DISABLED=true exists

We added the flag because BitBucket did not support mounting Docker socket a few years ago, but, since the builds were ephemeral, Ryuk could be omitted.

Is there a workaround with reusable containers by adding a random label to the container etc so that the container would never get reused but just left behind?

Yes. The reusable feature works by hashing the container's definition. If you make the hash unique (e.g. random label / env variable / network alias / network id) then a new container will be started each execution and old containers won't be terminated (one can see it as a disadvantage but in your case this is exactly what you need :D)

Thanks for the advice @bsideup . I'll revisit this PR so that it doesn't depend on TESTCONTAINERS_RYUK_DISABLED=true and uses the reuse containers feature as part of the solution. That's cleaner.

@bsideup I have revisited the solution in this PR to use the Testcontainers reuse mode instead of depending on the usage of TESTCONTAINERS_RYUK_DISABLED=true. Would you mind reviewing the changes?

/pulsarbot run-failure-checks

@lhotari it is okay :) I had a feeling that the stop() override is unnecessary but you know your usage better 👍

/pulsarbot run-failure-checks


Added Deployment templates that create Synapse workspace

I have added 3 deployment templates:

Create workspace and new DataLake storage
Create Workspace on existing storage
create storage that can be used for Synapse Workspace.

#sign-off


Gives weird output

Hi,
We are using your plugin for speech recognition to develop cordova ios app.
All things working fine but it gives weird output(doesnt recognize speech input properly) .
We have implemented this line for US english then too it does not recognize speech correctly.
(recognition.lang="en-US").
Do we need to change somewhere else to set language preference.
Environment which we are using:
cordova: 6.3.1
iOS device: iPhone5(iOS 10.1.1)(14B100)
IOS:OS X EI Capitan..10.11.6 (15G1004)
Kindly help.
Thanks in advance.

This might be a limitation of iSpeech.
Try latest version, it now uses SFSpeechRecognizer on iOS 10 and should return better results


added some qna for 1965

related to:  https://github.com/instructlab/taxonomy/issues/833
If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

...
...
...

Input given at the prompt

   ...

Response from the original model

  ...

Response from the fine-tuned model

  ...

Contribution checklist

[ ] The contribution was tested with ilab generate
[ ] No errors or warnings were produced by ilab generate
[ ] All commits are signed off (DCO)
[ ] The qna.yaml file contains at least 5 seed_examples
[ ] The qna.yaml file was linted and prettified (yaml-validator can do both)
[ ] An attribution.txt file in the same folder as the qna.yaml file
[ ] Content does not include PII or otherwise sensitive or confidential information
[ ] Content does not include anything documented in the project's Avoid these Topics guidelines

And DCO too please :)

Please fix the DCO and the linting issues.

Please remove the non relevant files before we can move farther with this.

Please fix the DCO issue.

The wikipedia page we used for this bounty is too many lists for the model to handle. Just not a great knowledge submission, Julia’s fault for not noticing beforehand!
Sorry it turns out we need to close this one. Thank you for doing all this work, but this won't be accepted nor any 1965 Lit PRs from Red Hat Summit 2024.


SetClipboardData requires a memory object allocated with GMEM_MOVEABLE (and locks)

Maintainer merge checklist

[x] Title is descriptive/clear for inclusion in release notes.
[x] Applied a Component: xxx label.
[ ] Applied the api-deprecation or api-break label.
[ ] Applied the release-highlight label to be highlighted in release notes.
[x] Added to the milestone version it was merged into.
[ ] Unittests are included in PR.
[ ] Properly documented, including versionadded, versionchanged as needed.

As per Microsoft Docs regarding SetClipboardData, if the hMem parameter (the handle) identifies a memory object (and that applies to our implementation), the object must have been allocated using the function with the GMEM_MOVEABLE flag.
Additionally, the handles returned by GetClipboardData, and the handle we create via GlobalAlloc, should be locked before getting accessed, to have the actual pointer of the data.
This fixes #8458 (and makes the CI happy)

@p0lygun and @Julian-O , since you're certainly more knowledgeable than me about Windows things (and have access to a device), can you please check if everything looks fine?
(And if it works as expected when used on a TextInput)

Code: Nope, can't comment sorry.
Actual TextInput: Took it for a spin. Seems to be supporting the clipboard fine.


Networking API

This api is primarily a port of the Fabric networking api.
Reason for the direct port is that this is one of the more modern APIs and is strongly written.
I do need to make some small changes in some spots, naming of certain interfaces to match qsl and improving some docs. Otherwise the API surface should be final given no other comments.
Most of the tests are disabled pending the command api at least for the server commands #33

@i509VCB what still needs to be done here before this is ready for review?

The only real change I think that we could use is making it more clear by changing naming to Reciever in the networking classes vs Handler since handler may be vague for serialization and de-serialization.

Please bug me to look at this pr again.


NNPACK randomly crashes in specific case

Dear NNPACK author,
We are trying to deploy NNPACK in our production environment, but it segmentation faults in a simple case below. It is interesting that it crashes randomly: sometimes it runs with segfault, sometimes without any error.
#include <nnpack.h>
#include <string.h>
#include <stdlib.h>
#include <malloc.h>
#include <stdio.h>
#include <assert.h>
#include <sys/time.h>

void conv_1(float *T0, float *T1, char * workspaceBuffer, size_t * workspaceSize) {
        float *bias = (float[64]){0};
        float *kernelData = (float[9408]){0};
        enum nnp_activation activation = nnp_activation_identity;
        enum nnp_convolution_algorithm algorithm = nnp_convolution_algorithm_auto;
        enum nnp_convolution_transform_strategy strategy = nnp_convolution_transform_strategy_compute;
        enum nnp_status status = nnp_convolution_inference(algorithm, strategy, 3, 64, (struct nnp_size){.width = 224, .height = 224}, (struct nnp_padding){.top = 3, .right = 3, .bottom = 3, .left = 3}, (struct nnp_size){.width = 7, .height = 7}, (struct nnp_size){.width = 2, .height = 2}, T0, kernelData, bias, T1, workspaceBuffer, workspaceSize, activation, NULL, NULL, NULL);
}

void forward(float *T0) {
        int sizes[4] = {1, 3, 224, 224};

        char workspaceBuffer[39096320];
        size_t workspaceSize = 39096320;
        float T1[802816];
        conv_1(T0, T1, workspaceBuffer, &workspaceSize);
        float T4[1 * 64 * 56 * 56];
        return;
}

int main(int argc, char const *argv[]) {
        enum nnp_status status = nnp_initialize();
        assert(status == nnp_status_success);
        float T0[1 * 3 * 224 * 224];
        for(int i = 0; i < 1 * 3 * 224 * 224; i++)
                T0[i] = 1;
        forward(T0);
        status = nnp_deinitialize();
        assert(status == nnp_status_success);
        return 0;
}

Some information about our environment:

X86_64 Linux with 3.5.0-17-generic kernel (carried with Ubuntu 12.10)
Build NNPACK with cmake using gcc-4.7.2.
Intel Xeon CPU E3-1231 with AVX2 and FMA3.

We tried to gdb it, it segfaults in nnp_sgemm_only_4x24__fma3(). Since there is no debug symbol in peachpy generated object files, we are not able to go further.
To run this simple example, we set ulimit -s unlimited to make unlimited stack size.
Please inform us if any more information is needed to fix it.
Many thanks for your time.

Update:
I have tested this code on Debian 9 (gcc 6.3, kernel 4.9). Still the same error. Anything wrong with this code?

I guess I have somehow found the problem. The allocated workspace size is not aligned.


Update thin-dev-branch

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Added translation to the news page on...translations

do you want to make it the first part of the news item? Rather than the second?

do you want to make it the first part of the news item? Rather than the second?

Good idea! Done

Nice!

Thanks!!!
On Fri, Jun 18, 2021 at 12:52 PM Saskia Hiltemann @.***>
wrote:

Nice!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/training-material/pull/2653#issuecomment-863981811,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKUKCSK47UBNXDPSMW4NKQLTTMXOTANCNFSM465MVF2A
.


lib/mkSettingsRenamedOptionModules: allow attrs value with 'old' and 'new' keys

The optionRenamedToSettings attribute allows to automatically create mkRenamedOptionModules for simple renames (options that move from plugin top-level to settings).
This helper is implemented using the lib.nixvim.mkSettingsRenamedOptionModules function.
This PR improves this function by making it accept attrs elements in the form
{
  old = ["one" "fooBar"];
  new = "one_foo_bar";
}

This makes it much more flexible and allows us to get rid of several calls to the native lib.mkRenamedOptionModule in the plugin modules.

lib/mkSettingsRenamedOptionModules: allow attrs value with 'old' and 'new' keys
-> Makes the change to mkSettingsRenamedOptionModules
plugins/*: use new mkSettingsRenamedOptionModules
-> Takes advantage of this implementation tree-wide

@mergifyio queue


Unable to control S23 Ultra (Read-Only Mode) / Can't use mouse & Keyboard

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: [Ubuntu 23.10]
scrcpy version: [2.3.1]
installation method: [apt]
device model: S918U (Samsung S23 Ultra)
Android version: [14]

Issue Description:

I ran scrcpy it mirrored the screen but I'm unable to to control the device using the mouse and keyboard.
The shared phone screen on my Ubuntu is on Read-Only mode.

NOTE: I don't have USB debugging (Security Settings) setting on my Samsung S23 Ultra

Ask:

Is there any equivalent setting  to the USB debugging (Security Settings) that must be enabled to be able to control the phone ?
Or is this caused by an other issue ?

installation method: [apt-> updated using pull request]

What do you mean?
What is the full output in the console?

installation method: [apt-> updated using pull request]

What do you mean?
What is the full output in the console?

I installed it using apt then updated it using a git pull request surly.
The output of the console:

scrcpy 2.3.1 <https://github.com/Genymobile/scrcpy>
* daemon not running; starting now at tcp:5037
* daemon started successfully
INFO: ADB device found:
INFO:     -->   (usb)  R5CW30HCHCA                     device  SM_S918U
/usr/local/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 94.5 MB/s (66007 bytes in 0.001s)
[server] INFO: Device: [samsung] samsung SM-S918U (Android 14)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6.0 NVIDIA 535.154.05
INFO: Trilinear filtering enabled
INFO: Texture: 1080x2312
INFO: Texture: 2312x1080

Run scrcpy -Vverbose, and press some keys and click with the mouse, then copy the whole console output.

I ran scrcpy -Vverbose, and here is the output of the console:

VERBOSE: input: touch [id=finger] move position=637,1685 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=729,1685 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=827,1685 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=924,1685 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=1016,1685 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=1089,1680 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=1148,1675 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] move position=1189,1670 pressure=1.000000 action_button=000000 buttons=000001
VERBOSE: input: touch [id=finger] up   position=1189,1670 pressure=0.000000 action_button=000001 buttons=000000
VERBOSE: [Audio] Buffering: target=2400 avg=3748.159180 cur=3772 compensation=-1348
VERBOSE: input: touch [id=finger] down position=121,1687 pressure=1.000000 action_button=000001 buttons=000001
...

OK, so everythings looks fine (except that your device does not react).
Focus some text area / text field on your device, and execute from your computer:
adb shell input text hello

Does it inject "hello"?

Having the same issue - scrcpy is detecting interaction but the phone does not reply.
adb shell input text hello works
Nothing Phone 2 -  OS 2.5.2 Android 14

Having the same issue - scrcpy is detecting interaction but the phone does not reply.
adb shell input text hello works
Nothing Phone 2 - OS 2.5.2 Android 14

I am having this input issue as well.  "adb shell input text hello" works properly.  I'm on a Pixel 6 Pro, running Android 14.
Please let me know of you'd like further information, happy to help.

adb shell input text hello works

If you run scrcpy --prefer-text, are you able to enter text ("hello") manually?


Create the exchange module

Description
closes: #1698
related: #1658
This PR creates the exchange module and adds it to the app.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

I'm dropping this into ready-for-review.
I've created issues to fill in the remaining TODOs. Those issues can be found under sub-tasks.
I haven't yet done the code review myself, though (which I usually do before dropping it into read-for-review). I'm expecting cleanup of unused/unneeded stuff to happen with the work for #1699.

diff analysis:
Line Changes -     Code:  +7577     -56
Line Changes -    Tests: +22979      -1
Line Changes -    Proto:  +1073      -0
Line Changes - Markdown:  +1572      -0
Line Changes -     Auto: +23884      -0
========================================
Line Changes -    Total: +57085     -57

@jtalis this is the upcoming exchange module... when this merges we will have it available in dev

We will need to update internal/stargate_whitelist.go to contain the exchange queries we want provwasm to support.

We will need to update internal/stargate_whitelist.go to contain the exchange queries we want provwasm to support.

Oops! Good call. I need to add the hold module queries too.


1.19?

can this get a 1.19 update?

+1 for this please

Done, should work as intended.
https://github.com/Sirmentio/fabric-mod-ihgm/releases/tag/1.1

pog thanks


Refactor docker implementation to separate container build in CI

Currently there are 2 containers that are compiled every commit: 16.04 and 16.04-dev. The 16.04 container extends the 16.04-dev and adds the compiler (where the 16.04-dev is intended to run on your own checkout to aid execution).
The 16.04 container should be re-built on every commit, since it includes code.
However, the 16.04-dev container can be rebuilt far less frequently. Perhaps once per week, unless there's a change in the /Docker folder.
Circle.yml should be refactored to only run make docker-build-clean once per week, or if /Docker changes.
And on cases where we don't run make docker-build-clean, run docker build --no-cache -t ircmaxell/php-compiler:16.04 -f Docker/ubuntu-16.04/Dockerfile . instead.

There's some other refactoring that the config can use too:

Make it use the docker environment instead of the machine environment (after the above is done)
Run the phan/phpunit tests in parallel instead of in sequence


Transfer the craned default logic to framework.

Describe the feature
Transfer the recommendation like replicas, resource to framework.

I will implement some parts of default functions.

done in #445


assigning specific port to brokers

when I tried assigning specific port to broker it failed and declined my offer. port ranges work
port=9092 did not work
port=31000..32000 worked
2015-07-22 16:03:07,015 [Thread-207] INFO  ly.stealth.mesos.kafka.Scheduler$  - Declined offers:
<IP_ADDRESS>#19580 - broker 1: no suitable port
<IP_ADDRESS>#19581 - broker 1: no suitable port
<IP_ADDRESS>#19582 - broker 1: no suitable port

It seems that your mesos slaves doesn't allow (send) 9092 port in their
offers
On 22 July 2015 at 19:10, Vidhya Arvind<EMAIL_ADDRESS>wrote:

when I tried assigning specific port to broker it failed and declined my
offer. port ranges work
port=9092 did not work
port=31000..32000 worked
2015-07-22 16:03:07,015 [Thread-207] INFO
ly.stealth.mesos.kafka.Scheduler$ - Declined offers:
<IP_ADDRESS>#19580 - broker 1: no suitable port
<IP_ADDRESS>#19581 - broker 1: no suitable port
<IP_ADDRESS>#19582 - broker 1: no suitable port
—
Reply to this email directly or view it on GitHub
https://github.com/mesos/kafka/issues/86.

Closing this as not actual.
<IP_ADDRESS>#19580 - broker 1: no suitable port message 100% means that offer doesn't contain 9092 port. So this is problem of mesos slave configuration.


chore: move autora/ to src/autora/

Description
This annoying change fixes a problem where PyCharm automatically creates incorrect import statements. This occurred in test cases
Type of change:

Major bug fix

Consequences:

All current PRs will need to be updated with the new paths

Example
Setup

Create a new file
Assign the name DARTSRegressor to a variable without importing it first
Put cursor on the red-underlined text
Click Alt + Enter

Correct new behavior

The correct path autora.skl.darts.DARTSRegressor is imported

The code works locally
The code works in the GitHub actions test runner

Erroneous old behavior

An incorrect path skl.darts.DARTSRegressor is imported

The code works locally (because of a quirk of how PyCharm functions)

⚠ The code doesn't work on GitHub.

Let's not merge this until January.

we're going to put off this change until February, during the next major clean-up of the code.


Add Port field to Template

Closes https://github.com/Octops/gameserver-ingress-controller/issues/38

Tested this PR in our cluster, but originally it doesn't seem to be filling the annotation correctly on the service object:
Our service object resulted in this:

On further inspection, it was because helm templating was substituting our fleet before it was deployed.    To get around this, we needed to escape in our fleet definition as follows:
octops.service-projectcontour.io/upstream-protocol.tls: '{{"{{"}} .Port {{"}}"}}'

I guess this is pretty expected when using something like helm, but should maybe be noted for developers, that this line in the documentation:

Should be escaped, if deploying fleets via helm or something else that may end up running template before deployment.

Good catch.

After deploying and running for a bit, this PR works as expected.


Commit messages

This is really the same as https://github.com/pplude/TronScriptEvo/issues/4 but to sum it up, please be more specific with the commit messages. Trying to find when something changed is MUCH harder when commit messages only show the version number.

Also using the same commit message for more then one commit makes it even harder. Ex 3 commits all messaged "6.5.2"

Furthering my last comment (because it's late and my thoughts are incomplete)
If I were to ask someone what version they were using and they replied 6.5.2 I would then have to ask "which 6.5.2?" Because there are 3 commits of 6.5.2, and any of those changes could make a difference in the behavior being seen. Looking back at 6.5.0 makes this issue even more evident.
I do still encourage you to make a commit with a version number when you have decided to "officially release" a new version, because then you can see easily in the commit history when each version happened, and the names of the commits in between each version.
Generally to make things easy for others to follow along and contribute, it's a good idea to keep one idea per commit, and the commit message should explain what the idea is doing. One idea could change multiple files. But you should avoid multiple ideas in a single commit if possible. When releasing a new version, change the version number that is hard coded in the file, and commit that change with the version number as the commit message. Don't include actual code changes in version bump commits.
This is all just me making recommendations in hopes of making your project easier for contributors to participate. If this doesn't work for you, please ignore me and continue making your awesome script in whatever way works best for you. Thank you, I will definitely be making use of your script personally, and probably parts of it at work :)

Hi nemchik,
I sort of assumed no one watches the github, and I do all development on my local workstation, just pasting it to GH when it's done. I'll try to throw more information in commit messages but no promises!
The reasoning behind version numbers in the commit message was that usually a v6.5.2-testing indicates I'm still fiddling with it, while a v6.5.2 indicates it's "done." But then when a bug crops up and I have to fix it, I just update the code and leave the same version number in the commit message because it's still the same release. How would you suggest notating bug fixes? In the extended comments field?

My mentality is that if you fix a bug that counts as a change, and that change would be included in the change log, and any change since the last release should be included in the next release.
This all comes down to how you would like to use the version number. Here are two web pages (google results) with information about making use of version numbers
http://stackoverflow.com/questions/65718/what-do-the-numbers-in-a-version-typically-represent-i-e-v1-9-0-1
https://en.wikipedia.org/wiki/Software_versioning
On the StackOverflow page the accepted answer indicates that one of the most common version numbering structures is Major.Minor.BugFix.BuildNumber
So really it's up to you how you'd like to manage the version numbering, but if it were me doing it I would increase the version number for any release, and bugfixes would happen between releases. If a bug is fixed and not yet released then the general public (non git users) would have to wait until that bugfix is included in the next release. You can choose to make releases as often or infrequent as you like based on how often you fix a bug, test, and then release a new version.
Again all of this is entirely up to your preference, so please don't let me hold you back from doing whatever is comfortable for you. I'm posting this in hopes of you making the project more contributor friendly on git. Accomplishing this would allow others to see the upcoming changes, test them out, provide feedback, and then you can decide to release a new version when you feel it's ready based on your testing and feedback from contributors.

I guess as a side note, I consider what you're currently doing "backporting", meaning to include a bugfix from a newer release into an older version of the software. So rather than releasing a new version (like 6.5.3 or <IP_ADDRESS>) you are backporting the fixes into 6.5.2 and re-releasing it. IMO this makes it difficult to truly keep track of what version one of your users is making use of. This could cause undue headaches for you in the future.
Also you mentioned you made a commit at 6.5.2-testing but I see only one of those, while I see multiple commits as 6.5.2, which implies you had made multiple changes to the released version of 6.5.2 after it was released.
Generally what i have seen most git repos do is to make changes and bugfixes and then once everything for a new release is ready change the hard coded version number in the file and commit that with the version number as the message. So an example would be this
6.5.2
bugfix zc
bugfix zb
bugfix za
6.5.1
bugfix yc
bugfix yb
bugfix ya
So I would not expect bugfix za to be included in 6.5.1

If you look at the included changelog, you'll see this is how I version things:
Legend:
 + Addition   - Removal  * Update/improvement
 . No change  ! Bug fix  / Change (non bug-fix)

Version number legend:
  x.x.x
  | | |
  | | program/definition update, minor change or bugfix (critical or regular)
  | regular release or feature change
  major release or feature change

I don't count tiny alterations as new versions (e.g. changing the text of a string, editing a comment, etc), but I can throw an -rcN designator on the end, where N is release candidate.
Tron's versioning is based off the Semantic Versioning standard.
Part of the difficulty with Tron is that it's not purely a source project as there are many tools it relies on that I don't control. So if a new version of ComboFix comes out, and it's included, but Tron didn't change, does that mean Tron is on a new version?
For now I'm not going to change versioning standards or build separate alpha/beta/testing/etc releases, I just don't have time for it. However, I do appreciate your comments, and will try to be more descriptive with version numbers, as well as pay closer attention to properly incrementing version numbers when pushing bug fixes, minor releases, etc. A while ago I was incrementing the third digit with every bug fix that went out, but sort of drifted out of doing it, so thanks for the reminder.
I'll close this for now, thanks for the feedback.

Maybe this could work?
  x.x.x.x
  | | | |
  | | | external tool update
  | | program/definition update, minor change or bugfix (critical or regular)
  | regular release or feature change
  major release or feature change

I guess really where i'm going with this though is that until you actually release a new version to the public, the changes in between releases would be committed to git with a commit message indicating what the change is doing. Then when you have decided a release is ready for the public commit a version number as the commit message, but try to keep version number commits to only changing the hard coded version number in the bat file (and maybe adding the changelog). This way the changes are all in their own commits, and the versions are kind of like mini-milestones.
Anyway, cheers!


Your hardware does not support this application. Failed to load 'libmain.so' java.lang.UnsatisfiedLinkError: dopen failed: library "libmain.so" not found

**_
"Your hardware does not support this application.
Failed to load 'libmain.so'
java.lang.UnsatisfiedLinkError: dopen failed: library "libmain.so" not found"
_**
Getting this message when trying to launch a Unity AR app as a library from Android Studio.
Unity 2022.3.7f1
Android Studio Giraffe
abiFilters "armeabi-v7a", "x86"
Gradle 7.2
Added include ':unityLibrary:xrmanifest.androidlib' as per latest unity update
Used in Unity:
Mapbox SDK without AR Components that were bundled with that SDK
ReadyPlayerMe SDK
ARFoundation
gLTFast and Draco 3D data compression (but not using it)
Google ARCore XR Plugin
Please let me know what other information you need to help me resolve this issue.
The app runs fine as an APK when built and run directly from Unity.

This doesn't look like an error with RPM core specifically, but rather a Unity issue.
https://forum.unity.com/threads/app-not-working-on-some-devices-failed-to-load-libmain-so.1031137/
Can you try some of the solutions mentioned in this forum thread?
For example some are in the screenshot below, that include adjusting build settings.

Closing due to inactivity


mock fs doesn't work as expected after upgrade from 0.29.8 to 1.3.1

Describe the bug
When we upgraded from Vitest v0.29.8 to v1.3.1, vi.mock('fs', () => {}) was not working, here's the code:
import { assert, expect, it, describe, vi, beforeAll, afterAll } from 'vitest';
import { readContent } from '../src/index';

describe('test-mock', () => {
  beforeAll(() => {
    vi.mock('fs', () => {
      return {
        readFileSync(path: string) {
          if (path.endsWith('example.html')) {
            return 'some-mock-text';
          }
          return `/** ${path} **/`;
        },
      };
    });
  });

  it('test 1', () => {
    const res = readContent();
    expect(res).toBe('some-mock-text');
  });
  afterAll(() => {
    vi.unmock('fs');
  });
});

Reproduction
Here is the stackbliz repo to reproduce this problem:

v0.29.8: https://stackblitz.com/edit/stackblitz-starters-vqwtgb?file=test%2Findex.test.ts
you can see that the fs mock worked as expected:

v1.3.1: https://stackblitz.com/edit/stackblitz-starters-43ldmt?file=test%2Findex.test.ts
you will see that test failed as below:

System Info
System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.18.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.3 - /usr/local/bin/pnpm
  npmPackages:
    vitest: 1.3.1 => 1.3.1

### Used Package Manager

npm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

vi.mock and vi.unmock are hoisted: https://vitest.dev/api/vi.html#vi-mock
There is zero effect of calling them inside beforeAll/afterAll hooks - they are moved to the top of the file and executed before imports. In your example you mock and unmock the same module, so there is no effect. Move vi.mock outside of beforeAll and remove vi.unmock and everything will work as expected.
The fact that it worked somehow before is a bug.


Feature Request - Support better lazy loading

Hey 👋🏾
Thanks for this pretty plugin. I'm just setting it up for me and start to customize it. One thing I stumbled over was an issue with properly lazy loading the plugin.
I use the command Navbuddy to load to this plugin and its configuration. So it only loads when I need it. This also means I do not use a manual autocommand to attach navbuddy to the LSP clients, but use the configuration for auto-attachment. BUT, this only works for newly started clients, as is uses the LspAttach event. That then leads to issues because Navbuddy is not aware of the already existing clients.
So I wrote myself a little utility function which runs after the setup. It does the job and everything works nicely. It looks like the following:
--- Fix the issue that NavBuddy can attach automatically to new clients, but
--- does not for already started ones. To have better lazy loading support, this
--- retroactively attaches NavBuddy to all already existing clients and their
--- buffers.
local function attach_to_existing_lsp_clients()
  local all_clients = vim.lsp.get_active_clients()

  local supported_clients = vim.tbl_filter(function(client)
    return client.server_capabilities.documentSymbolProvider
  end, all_clients)

  for _, client in ipairs(supported_clients) do
    local buffers_of_client = vim.lsp.get_buffers_by_client_id(client.id)

    for _, buffer_number in ipairs(buffers_of_client) do
      navbuddy.attach(client, buffer_number)
    end
  end
end

So I thought maybe it would be nice to add this to the plugin itself? It would make the plugin more robust in terms of the load order, lazyness etc. So if the user has enable the option to automatically attach, the setup function will not only register the auto-command, but also does something similar to my function above.
What do you think? Should I open a PR?

Yep! This sounds good. You can open a PR


[ci/cd] Optimize docker build

[ ] parallelize with matrix
[ ] use cache with cache-form / cache-to

Here are some links :
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners
https://docs.docker.com/engine/reference/commandline/buildx_build/#cache-to
https://github.com/moby/buildkit#export-cache
https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs

So, after discussion with @kiorky, I try several things :

parallelization with matrix on platforms

an issue appears, with the build & push github action, the latest build is pushed and overwrite all previously images
a better idea of this could be the use of docker manifest to create a multi-arch manifest (https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/) AFTER all platforms are built
this could also help us if we want to test all built images (particularly arm32 ones)
the last step of the workflow could be the push of the tag with the multi-arch manifest

set the cache-from / cache-to

I don't see any improvements on build time
I let them for now and check if there is some benefits

move the docker build job in the api-quality workflow to reuse build artifacts

this is the main shift, as it cut off the build time from one hour to ~6mn
and this, without the use of matrix as it breaks the push of multi-arch images

Initial time:
https://github.com/locokit/locokit/actions/runs/5923472268

After use of parallelization with matrix on platforms:
https://github.com/locokit/locokit/actions/runs/5965675095

After shifting docker build in the api quality workflow:
with parallelization (and issue when pushing tag to hub.docker.com)
https://github.com/locokit/locokit/actions/runs/5966002861

without parallelization (and no issue on push)
https://github.com/locokit/locokit/actions/runs/5966049744

For now, we'll stay on what is in the PR, so :

shift of the docker build in the api quality workflow
reuse of build artifacts for docker build
no matrix / parallelization by platform


fixed #id do not convert to #rel_url:id in combined mode

And also add an unittest to test transform_href.
We can run test via tox -e py38 now.

It seems #43 and #70 will be fixed with this PR.


git error when running yarnhook

I cloned a project that uses yarnhook, changed a file, and then ran git checkout on that file. yarnhook got triggered, but it failed with this output:
<path_to_project>/node_modules/.bin/yarnhook
<path_to_project>/node_modules/yarnhook/node_modules/execa/index.js:303

                throw (result.error || new Error(result.stderr === '' ? result.stdout : result.stderr));
                ^
Error: fatal: Log for 'HEAD' only has 1 entries.
    at Function.module.exports.sync (<path_to_project>/node_modules/yarnhook/node_modules/execa/index.js:303:26)
    at Object.<anonymous> (<path_to_project>/node_modules/yarnhook/index.js:58:38)
    at Module._compile (internal/modules/cjs/loader.js:1147:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1167:10)
    at Module.load (internal/modules/cjs/loader.js:996:32)
    at Function.Module._load (internal/modules/cjs/loader.js:896:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47
error Command failed with exit code 1.

Tried googling but found nothing. Any advice?

Hi, thanks for reporting this issue. I'm working again on this project and would like to solve your problem.
The problem seems to be that your use of checkout is not a branch-changing one but yarnhook gets triggered anyway. Since theres's no git hook solely for pulls and branch changes we try to react to this with 3 different git hooks. I'll work a bit more on detecting branch changes and nothing else.
This probably wouldn't be an issue if you changed a branch at least once, in which case reflog for HEAD would have at least two entries. Thanks for catching an edge case.
I'll either rename this issue or close this one to create a blanket issue for the general problem.


Errors during LSP config callbacks are silently discarded

Description
Please have a look at https://github.com/neovim/neovim/issues/25375 for backstory.
To sum up, neovim's lsp client is pcalling user config callbacks and discarding their return. Configs recommended by nvim-lspconfig using on_init assume client.workspace_folders is defined, but nvim-lspconfig removes it in single file mode. The callback throws an error attempting to index nil, neovim swallows it, and there is no indication whatsoever that the user's initialization failed.
https://github.com/neovim/nvim-lspconfig/blob/68b23c06132cb1ef8d5690111c112388fbcf1c30/lua/lspconfig/manager.lua#L145-L152
Relevant config recommendations include:
https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#lua_ls
https://github.com/neovim/nvim-lspconfig/wiki/Project-local-settings
and these have been propagated elsewhere.
I would also like to point out that nvim-lspconfig is also using pcall to haphazardly silence errors.
https://github.com/neovim/nvim-lspconfig/blob/68b23c06132cb1ef8d5690111c112388fbcf1c30/lua/lspconfig/configs.lua#L94-L96
https://github.com/neovim/nvim-lspconfig/blob/68b23c06132cb1ef8d5690111c112388fbcf1c30/lua/lspconfig/configs.lua#L197-L202
Neovim version
NVIM v0.10.0-dev-1203+g0592fd5e1
Build type: Release
LuaJIT 2.1.1695409640
Nvim-lspconfig version
68b23c06132cb1ef8d5690111c112388fbcf1c30
Operating system and version
n/a
Affected language servers
lua_ls
Steps to reproduce

Build neovim
Install prebuilt lua-language-server
Install nvim-lspconfg
Config lua-ls using https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#lua_ls
Open lua file without a workspace.

Actual behavior
The lsp client is starts successfully but config during on_init does not complete and no indication is given that there was a problem.
Expected behavior
Recommended lua_ls config should work without problems regardless of single file mode. Errors that can't be handled gracefully should never be thrown away.
Minimal config
require'lspconfig'.lua_ls.setup {
  on_init = function(client)
    local path = client.workspace_folders[1].name
    if not vim.loop.fs_stat(path..'/.luarc.json') and not vim.loop.fs_stat(path..'/.luarc.jsonc') then
      client.config.settings = vim.tbl_deep_extend('force', client.config.settings, {
        Lua = {
          runtime = {
            -- Tell the language server which version of Lua you're using
            -- (most likely LuaJIT in the case of Neovim)
            version = 'LuaJIT'
          },
          -- Make the server aware of Neovim runtime files
          workspace = {
            checkThirdParty = false,
            library = {
              vim.env.VIMRUNTIME
              -- "${3rd}/luv/library"
              -- "${3rd}/busted/library",
            }
            -- or pull in all of 'runtimepath'. NOTE: this is a lot slower
            -- library = vim.api.nvim_get_runtime_file("", true)
          }
        }
      })

      client.notify("workspace/didChangeConfiguration", { settings = client.config.settings })
    end
    return true
  end
}

LSP log

@A-Babin since https://github.com/neovim/neovim/pull/25409 (all ?) LSP server misconfiguration errors should be displayed.
I just tried the configuration provided in this issue together with the one from https://github.com/neovim/neovim/issues/25375, and now I get an error message with quite a good stacktrace:

I personally consider this issue resolved then.


Event Page Notificaiton Automation

Adds a feature to automatically send out an email to relevant individuals once a new event is posted, informing them of the time, date, and location.

Not to be implemented now, will be implemented once we get rpi.edu email.


Fix memory leak of HdfsBuilder

ASAN report memory leak of HdfsBuilder, after checking libhdfs source code, hdfsBuilderConnect does not free hdfsBuilder as its doc claimed. https://github.com/apache/hawq/blob/e9d43144f7e947e071bba48871af9da354d177d0/depends/libhdfs3/src/client/Hdfs.cpp#L406
Gluten issue: https://github.com/oap-project/gluten/issues/3713

Hi @mbasmanova @kgpai could you help review this patch?

@kgpai Krishna, would you help merge this PR?

Hi @kgpai could you help merge this patch? thank you!

Working on merging this.


Improvements from fork

@mrd0ll4r I see you have made improvements in your fork. I don't know if you intend to contribute those new algorithms to this repo (or if you are ready to do so) but I would grab the doc and SizeLimited improvements if that's ok.

Oh, nice! Of course, do grab those! I think most of the algorithms we added on our side are also ready to be included. Some of them are experimental and we tried different implementations. For those, we're still evaluating which implementations perform best.
I think everything apart from BFBC should be fine.
To pull them into here, I probably have to rewrite history on our end a bit to separate the two into different commits...
On the other hand, I see that you somehow cherry-picked multiple things from that one commit I made, and it even preserved authorship somehow. How did you do that?


Feature/expand-bendersmpi-2

work on bendersmpi to use it with 1 proc
merging bendersmpi and sequential
open discussion on benders by batch with mpi

This PR just makes MPI mandatory, for now MPI and sequential are not merge


common: do not regenerate a cluster fsid if cluster exits

This commit solves the situation where you lost your fetch directory and
you are running ansible against an existing cluster. Since no fetch
directory is present the file containing the fsid doesn't exist so we
are creating a new one. Later the ceph.conf gets updated with a wrong
fsid which causes problems for clients and ceph processes.
Closes: #1148
Signed-off-by: Sébastien Han<EMAIL_ADDRESS>

@mistur please test this. The mon key has the same problem, I'm fixing this as well.

seem to be good for fsid, but mon key seem to not be fetch correctly
fetch/monitor_keyring.conf should be the same as /var/lib/ceph/mon/-/keyring, souldn't it ?

Yes it should, it's only useful when you want to add new nodes actually

this patch does not fix the fetch of the mon keys but only the fsid, right ?

Correct, I can have a look into the mon key, later

ok, so this patch fix my issue. you can close

jenkins test ansible2.2-centos7_cluster

jenkins test ansible2.2-centos7_cluster

jenkins test ansible2.2-dmcrypt_journal


Fix global quartz db timer service test

Minor fixes in a test case.

+1 to merge (once the build succeeds, just to be sure).


Button not injected in GitHub when changing branches

On a GitHub project page, the button disappears when a different branch is selected. Refreshing the page will cause the button to appear again:
https://user-images.githubusercontent.com/83611742/228654498-6699214f-39c4-43d5-9d59-5cb79bc40dd3.mov
The button should not disappear to the user.

Fixed by #73


ARROW-1806: [GLib] Add garrow_record_batch_writer_write_table()

C++ test was failed on Travis CI. I restarted it then C++ test passed.


Unclear how to clone a github repository

Trying to clone one of our official repositories.  It feels like we should be able to do this.  Is the correct way to do this via powershell?

Install git tools, refresh env then do the clone.

@crutkas as you have found out, the issue here is that after installation of some tools, the commands associated with those tools are not available in the current command/powershell window until you refresh.  This is normally due to the fact that a change to the system PATH variable has been made, which isn't available in the current command/powershell window.
There are two solutions to this.  Firstly, you can either close and re-open the current command/powershell window.  Or, Chocolatey provides the refreshenv command, which you can use to achieve the same thing, without needing to close the window.


Header bar and landing screen are bad on mobile

Nav bar doesn't function well and general appearance is sloppy. I'd suggest at least:

[x] hiding slider
[x] logo and name appear on same line

Have removed logo but put title on the nav strap, and improved the nav layout so it drops down nicely under that. Removed slider and altered button display so it makes sense now to read down the page and get the button / do other things. Edited for oab and odb.


<EMAIL_ADDRESS>postinstall is not downloading

Please only submit reproducible issues.
If you're not sure if it's a real bug or if it's just you, please open a topic on the forum: https://forum.magicmirror.builders/category/15/bug-hunt
Problems installing or configuring your MagicMirror? Check out: https://forum.magicmirror.builders/category/10/troubleshooting
When submitting a new issue, please supply the following information:
Platform: Place your platform here... give us your web browser/Electron version and your hardware (Raspberry Pi 2/3, Windows, Mac, Linux, System V UNIX).
Node Version: Make sure it's version 0.12.13 or later.
MagicMirror Version: Now that the versions have split, tell us if you are using the PHP version (v1) or the newer JavaScript version (v2).
Description: Provide a detailed description about the issue and include specific details to help us understand the problem. Adding screenshots will help describing the problem.
Steps to Reproduce: List the step by step process to reproduce the issue.
Expected Results: Describe what you expected to see.
Actual Results: Describe what you actually saw.
Configuration: What does the used config.js file look like? Don't forget to remove any sensitive information!
Additional Notes: Provide any other relevant notes not previously mentioned. This is optional.

Please refer to http://forum.magicmirror.builders for support and troubleshooting.
I'm closing this issue for now. If you feel this issue should remain open, please let me know.


It does not work inside docker Docker image

I am trying to run it inside Docker-in-Docker:
$ docker run --rm -t -i docker:19
$ wget https://github.com/christian-korneck/docker-pushrm/releases/download/v1.0.0/docker-pushrm_linux_amd64
$ mkdir -p $HOME/.docker/cli-plugins
$ mv docker-pushrm_linux_amd64 $HOME/.docker/cli-plugins/docker-pushrm
$ chmod +x $HOME/.docker/cli-plugins/docker-pushrm
$ docker --help
...
Invalid Plugins:
  pushrm      failed to fetch metadata: exit status 127
...

hi @mitar, thanks for the info!
I just briefly tested and it looks like there's an issue with running docker-pushrm on alpine (which the docker:19 image is based on) and Docker "from scratch" images. It silently dies with exit code 127.
I'll investigate and push a patch as soon as I know what the problem is.
In the meantime, is there any chance that you could run it on a different Docker base image? (It worked fine for me on ubuntu/debian/centos/fedora etc). You don't actually need the Docker CLI tool to run it, you can just execute ./docker-pushrm directly.

hi @mitar,
this has been fixed in v1.0.1.
Here's a basic example with the docker:19 container image that works for me (for simplicity I'm copying the README file and the Docker config file (with the credentials) in the Dockerfile, but you could of course also mount them as volume). I took the liberty to add a slightly more complex line for downloading the plugin from github releases that I'm using in my own CI jobs. It uses a (hopefully) save/stable api call to find the download url of the latest release.
$ ls
Dockerfile	README.md	config.json

contents of Dockerfile:
FROM docker:19
USER root
RUN mkdir -p /root/.docker/
COPY ./config.json /root/.docker/config.json
COPY ./README.md /README.md
RUN apk add curl jq
RUN export FILENAME=docker-pushrm_linux_amd64 && export DESTDIR=$HOME/.docker/cli-plugins && mkdir -p "$DESTDIR" && DOWNLOAD_URL=$(curl --silent --fail --show-error https://api.github.com/repos/christian-korneck/docker-pushrm/releases/latest | jq -r ".assets | map(select(.name == \"$FILENAME\"))[0].browser_download_url") && curl --silent --fail --show-error -L $DOWNLOAD_URL -o "$DESTDIR/docker-pushrm" && chmod +rx "$DESTDIR/docker-pushrm"

contents of config.json:
{
	"auths": {
		"https://index.docker.io/v1/": {
			"auth": "bXl1c2VyOm15cGFzc3dvcmQ="
		},
		"demo.goharbor.io": {
			"auth": "bXl1c2VyOm15cGFzc3dvcmQ="
		},
		"quay.io": {
			"auth": "bXl1c2VyOm15cGFzc3dvcmQ="
		}
	},
	"plugins": {
		"docker-pushrm": {
			"apikey_quay.io": "my-quay-api-key-in-clear-text"
		}
	}
}

(I've created this file on my workstation by running docker login and then copying the relevant parts from $HOME/.docker/config.json. If you want to create it manually, the auth values are base64 of user:passwd. The Quay API key is clear text. You could of course also do a docker login inside of the container, but please note that this requires a connection to a running docker engine in a dind (docker in docker) container as described here: https://hub.docker.com/_/docker . (I'm passing on this here for simplicity, but it works, too.))
then:
$ docker build -t mydocker:19 . --no-cache
$ docker run --rm -t mydocker:19 docker pushrm my-user/my-repo --debug
...
DEBU content validation successfull, readme successfully pushed to repo server

Hope this helps - let me know if you have any questions or run into further problems.
Best,
Chris

It uses a (hopefully) save/stable api call to find the download url of the latest release.

I do not want the latest release in my CI jobs, but a fixed one. :-) CI jobs broke too many times because of a third party upgrade.
Thanks for fixing this. I will try it later today.

I do not want the latest release in my CI jobs, but a fixed one. :-)
sure - your command works fine as well :)

@mitar :

You could of course also do a docker login inside of the container, but please note that this requires a connection to a running docker engine in a dind (docker in docker) container

Regarding running docker-pushrm in a container: To avoid that you need a running Docker engine (with all the overhead and security issues of a Docker in Docker setup) just to be able to run docker login it's now (since v1.2.0) possible to pass credentials to docker-pushrm via env vars. So you don't need anything else in your container besides the docker-pushrm executable. I've also added a --file <path> option to access a README file in another path (to access a README in a container volume).
Example:
DOCKER_USER=my-user DOCKER_PASS=my-password ./docker-pushrm --file /myvol/README.md my-user/my-repo

Awesome! This tool is getting better and better. :-)

and there's now also a Dockerfile / container image:
https://github.com/christian-korneck/docker-pushrm#running-docker-pushrm-as-a-container


Add support for SPHINXBUILD environment variable

Closes #58

Coverage remained the same at 76.068% when pulling 1c7f8edfd05fc3df96968624f24aa66fe1f5a97c on bachp:sphinxbuild-evn into e0f40b6359ca00a48ca5ba903de1e25da27de453 on GaretJax:develop.

Oh, interesting! Definitely a good idea!


helm rollback sometimes doesn't roll back to the original state

Output of helm version:
version.BuildInfo{Version:"v3.16.1", GitCommit:"5a5449dc42be07001fd5771d56429132984ab3ab", GitTreeState:"clean", GoVersion:"go1.22.7"}
also tested on:
version.BuildInfo{Version:"v3.13.0", GitCommit:"825e86f6a7a38cef1112bfa606e4127a706749b1", GitTreeState:"clean", GoVersion:"go1.20.8"}
The 3-way merging logic of Helm is causing me some headaches. If a new container (for example) is added to my deployment that I upgrade to but that upgrade fails, Helm sometimes considers the new container to be an external addition that then does not remove even with helm rollback.
Given the following Chart:
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: leakyrollback
spec:
  selector:
    matchLabels:
      app: leakyrollback

  replicas: 1
  template:
    metadata:
      labels:
        app: leakyrollback
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: main
          image: busybox:latest
          args:
            - "/bin/sh"
            - "-c"
            - "date && sleep infinity"
        {{ if (.Values.feature) }}
        - name: featureimplementer
          image: busybox:latest
          args:
            - "/bin/sh"
            - "-c"
            - "echo Feature implementer && sleep infinity"
        {{ end }}
---
{{- if (.Values.makeUpgradeFailAtPost) -}}
apiVersion: batch/v1
kind: Job
metadata:
  name: "failurecauser"
  annotations:
    helm.sh/hook: post-upgrade
    helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded,hook-failed
spec:
  template:
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: never
          image: busybox:latest
          args:
            - "/bin/sh"
            - "-c"
            - "date && false"
          imagePullPolicy: Always
      restartPolicy: Never
  backoffLimit: 0
{{- end -}}

If I install with helm install -n NS, all is well. If I then upgrade to enable the feature with helm upgrade --set feature=true --set makeUpgradeFailAtPost=true the upgrade fails but only after the Deployment manifest has been patched. So far, perfectly reasonable behavior.
If I then revert the values changes and update the release with helm upgrade, the additional container is considered to be externally added as suggested in 3-way-strategic-merge-patches. This seems to be because Helm considers the last successful deployment to be the basis of comparison, and ignores the the last attempted deployment even if it failed in post-upgrade which means that most differences to the manifests are actually coming from the upgraded release, not an external tool.
This is rather confusing behavior. Once the new revision is complete, the new container is now part of the live Pods, and even a helm rollback 1 keeps it there.
Of course, the change in the chart need not be a new container in an existing Pod, it could be a new envvar, a new spec setting and so on. The only fields that appear to be immune from this are fields that were already set in the successful revision (i.e., image tags of previously present containers are always rolled back).
The only scenario I can see where Helm removes the newly added container is if I invoke helm rollback immediately after the failed upgrade (or use --atomic). Any intervening upgrades that "adopt" the changes cause helm rollback to keep them.
Shouldn't helm rollback r behave the same regardless of how many intervening failed helm upgrades there were?
I can see why it follows from having 3-way merges and taking the last successful deployment as base, but is that wise? As things stand, changes made in failed upgrades can be adopted by Helm which are then kept for subsequent upgrades and rollbacks making them sticky.
Reproduction steps and full logs are below.
Initial install and validation
kubectl create ns leakyrollback
helm install -n leakyrollback test .
kubectl -n leakyrollback get pod

Output:
NAME: test
LAST DEPLOYED: Mon Sep 23 18:39:34 2024
NAMESPACE: leakyrollback
STATUS: deployed
REVISION: 1
TEST SUITE: None

NAME                             READY   STATUS    RESTARTS   AGE
leakyrollback-67d976b847-l5gr9   1/1     Running   0          5s

So far, so good.
helm upgrade to enable feature-flag which fails
helm upgrade -n leakyrollback --debug test . --set makeUpgradeFailAtPost=true --set feature=true
kubectl -n leakyrollback get pod

Output:
upgrade.go:164: 2024-09-23 18:39:57.119827386 +0200 CEST m=+0.239306317 [debug] preparing upgrade for test
upgrade.go:172: 2024-09-23 18:39:57.751371326 +0200 CEST m=+0.870850236 [debug] performing update for test
upgrade.go:375: 2024-09-23 18:39:58.08346789 +0200 CEST m=+1.202946800 [debug] creating upgraded release for test
client.go:393: 2024-09-23 18:39:58.215098365 +0200 CEST m=+1.334577300 [debug] checking 1 resources for changes
client.go:693: 2024-09-23 18:39:58.342892703 +0200 CEST m=+1.462371645 [debug] Patch Deployment "leakyrollback" in namespace leakyrollback
client.go:486: 2024-09-23 18:39:58.553708001 +0200 CEST m=+1.673186902 [debug] Starting delete for "failurecauser" Job
client.go:490: 2024-09-23 18:39:58.613858169 +0200 CEST m=+1.733337100 [debug] Ignoring delete failure for "failurecauser" batch/v1, Kind=Job: jobs.batch "failurecauser" not found
wait.go:104: 2024-09-23 18:39:58.613930096 +0200 CEST m=+1.733409027 [debug] beginning wait for 1 resources to be deleted with timeout of 5m0s
client.go:142: 2024-09-23 18:39:59.011984507 +0200 CEST m=+2.131463432 [debug] creating 1 resource(s)
client.go:712: 2024-09-23 18:39:59.085350708 +0200 CEST m=+2.204829636 [debug] Watching for changes to Job failurecauser with timeout of 5m0s
client.go:740: 2024-09-23 18:39:59.148795119 +0200 CEST m=+2.268274062 [debug] Add/Modify event for failurecauser: ADDED
client.go:779: 2024-09-23 18:39:59.148864227 +0200 CEST m=+2.268343159 [debug] failurecauser: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
client.go:740: 2024-09-23 18:40:02.772383345 +0200 CEST m=+5.891862287 [debug] Add/Modify event for failurecauser: MODIFIED
client.go:779: 2024-09-23 18:40:02.772440631 +0200 CEST m=+5.891919558 [debug] failurecauser: Jobs active: 0, jobs failed: 0, jobs succeeded: 0
client.go:740: 2024-09-23 18:40:02.796101363 +0200 CEST m=+5.915580301 [debug] Add/Modify event for failurecauser: MODIFIED
client.go:486: 2024-09-23 18:40:02.929281415 +0200 CEST m=+6.048760316 [debug] Starting delete for "failurecauser" Job
wait.go:104: 2024-09-23 18:40:02.991465058 +0200 CEST m=+6.110943987 [debug] beginning wait for 1 resources to be deleted with timeout of 5m0s
upgrade.go:487: 2024-09-23 18:40:03.118025239 +0200 CEST m=+6.237504168 [debug] warning: Upgrade "test" failed: post-upgrade hooks failed: 1 error occurred:
        * job failurecauser failed: BackoffLimitExceeded

Error: UPGRADE FAILED: post-upgrade hooks failed: 1 error occurred:
        * job failurecauser failed: BackoffLimitExceeded

helm.go:86: 2024-09-23 18:40:03.192032186 +0200 CEST m=+6.311511122 [debug] post-upgrade hooks failed: 1 error occurred:
        * job failurecauser failed: BackoffLimitExceeded

UPGRADE FAILED
main.newUpgradeCmd.func2
        helm.sh/helm/v3/cmd/helm/upgrade.go:243
github.com/spf13/cobra.(*Command).execute
        github.com/spf13/cobra@v1.8.1/command.go:985
github.com/spf13/cobra.(*Command).ExecuteC
        github.com/spf13/cobra@v1.8.1/command.go:1117
github.com/spf13/cobra.(*Command).Execute
        github.com/spf13/cobra@v1.8.1/command.go:1041
main.main
        helm.sh/helm/v3/cmd/helm/helm.go:85
runtime.main
        runtime/proc.go:271
runtime.goexit
        runtime/asm_amd64.s:1695

NAME                             READY   STATUS    RESTARTS   AGE
leakyrollback-65b784fd7c-4jv2l   2/2     Running   0          13s

While the helm upgrade itself failed, we can see that both containers are present in the pod.
helm upgrade to revert
helm upgrade -n leakyrollback --debug test .
kubectl -n leakyrollback get pod

Output:
upgrade.go:164: 2024-09-23 18:40:19.241595035 +0200 CEST m=+0.243035762 [debug] preparing upgrade for test
upgrade.go:172: 2024-09-23 18:40:19.935801768 +0200 CEST m=+0.937242508 [debug] performing update for test
upgrade.go:375: 2024-09-23 18:40:20.281323747 +0200 CEST m=+1.282764483 [debug] creating upgraded release for test
client.go:393: 2024-09-23 18:40:20.421229221 +0200 CEST m=+1.422669949 [debug] checking 1 resources for changes
client.go:693: 2024-09-23 18:40:20.549737101 +0200 CEST m=+1.551177813 [debug] Patch Deployment "leakyrollback" in namespace leakyrollback
upgrade.go:180: 2024-09-23 18:40:20.695406318 +0200 CEST m=+1.696847045 [debug] updating status for upgraded release for test
Release "test" has been upgraded. Happy Helming!
NAME: test
LAST DEPLOYED: Mon Sep 23 18:40:19 2024
NAMESPACE: leakyrollback
STATUS: deployed
REVISION: 3
TEST SUITE: None
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
{}

HOOKS:
MANIFEST:
---
# Source: leakyrollback/templates/Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: leakyrollback
spec:
  selector:
    matchLabels:
      app: leakyrollback

  replicas: 1
  template:
    metadata:
      labels:
        app: leakyrollback
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: main
          image: armdocker.rnd.ericsson.se/dockerhub-ericsson-remote/busybox:latest
          args:
            - "/bin/sh"
            - "-c"
            - "date && sleep infinity"

NAME                             READY   STATUS    RESTARTS   AGE
leakyrollback-65b784fd7c-4jv2l   2/2     Running   0          30s

While the upgrade itself was successful, it did not remove the second container. Given that this is the primary difference between r1 and r2, this upgrade hasn't accomplished much, but unless we inspect the deployed objects, we'd have no way of noticing.
Try again with helm rollback
helm rollback --debug -n leakyrollback test 1
kubectl -n leakyrollback get pod

Output:
rollback.go:65: 2024-09-23 18:40:40.660052874 +0200 CEST m=+0.230967088 [debug] preparing rollback of test
rollback.go:131: 2024-09-23 18:40:40.808039551 +0200 CEST m=+0.378953770 [debug] rolling back test (current: v3, target: v1)
rollback.go:72: 2024-09-23 18:40:40.871551892 +0200 CEST m=+0.442466105 [debug] creating rolled back release for test
rollback.go:78: 2024-09-23 18:40:41.026198976 +0200 CEST m=+0.597113191 [debug] performing rollback of test
client.go:393: 2024-09-23 18:40:41.452228464 +0200 CEST m=+1.023142654 [debug] checking 1 resources for changes
client.go:693: 2024-09-23 18:40:41.578535731 +0200 CEST m=+1.149449959 [debug] Patch Deployment "leakyrollback" in namespace leakyrollback
rollback.go:257: 2024-09-23 18:40:41.712636358 +0200 CEST m=+1.283550575 [debug] superseding previous deployment 3
rollback.go:84: 2024-09-23 18:40:41.784515114 +0200 CEST m=+1.355429326 [debug] updating status for rolled back release for test
Rollback was a success! Happy Helming!

NAME                             READY   STATUS    RESTARTS   AGE
leakyrollback-65b784fd7c-4jv2l   2/2     Running   0          48s

At this point, it appears that the previous upgrade has inherited the second container, but as it wasn't present in the rendered-form of the previous upgrade, it is considered external and so still kept.

It seems, that a rollback without the intermediate upgrade removes the orphaned container.


About the k-point used in the document example.

Here gives the following example:

from spgrep import get_spacegroup_irreps
from spgrep.representation import get_character

# Rutile structure (https://materialsproject.org/materials/mp-2657/)
# P4_2/mnm (No. 136)
a = 4.603
c = 2.969
x_4f = 0.3046
lattice = [
    [a, 0, 0],
    [0, a, 0],
    [0, 0, c],
]
positions = [
    [0, 0, 0],  # Ti(2a)
    [0.5, 0.5, 0.5],  # Ti(2a)
    [x_4f, x_4f, 0],  # O(4f)
    [-x_4f, -x_4f, 0],  # O(4f)
    [-x_4f + 0.5, x_4f + 0.5, 0.5],  # O(4f)
    [x_4f + 0.5, -x_4f + 0.5, 0.5],  # O(4f)
]
numbers = [0, 0, 1, 1, 1, 1]

kpoint = [0.5, 0, 0]  # X point
irreps, rotations, translations, mapping_little_group = get_spacegroup_irreps(
    lattice, positions, numbers, kpoint
)

# Symmetry operations by spglib
assert len(rotations) == 16
assert len(translations) == 16

# At X point, the little co-group is isomorphic to mmm (order=8)
assert len(mapping_little_group) == 8
print(mapping_little_group)  # [ 0,  1,  4,  5,  8,  9, 12, 13]

# Two two-dimensional irreps
for irrep in irreps:
    print(get_character(irrep))
# [2.+0.j 0.+0.j 0.+0.j 2.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j]
# [2.+0.j 0.+0.j 0.+0.j -2.+0.j 0.+0.j 0.+0.j 0.+0.j 0.+0.j]

In this example, the space group is P4_2/mnm (No. 136), and the selected k point is [0.5, 0, 0]  (X point). I checked this information from BCS KVEC's convention represented here, as shown below:

As you can see, the two coordinates given above are not consistent. Any hints for this problem?
Regards,
Zhao

Let $(\mathbf{R}, \mathbf{v})$ be a symmetry operation. Two k-points $\mathbf{k}$ and $\mathbf{R}^T\mathbf{k}$ are equivalent and irreps at these k-points are also unitary equivalent. For $P4_2/mnm$, (1/2, 0, 0) and (0, 1/2, 0) are transformed each other by four-fold screw operation. So the same irreps are returned whichever k-points to be chosen.

Thank you for your explanation. Below I give some supplementary validation and analysis.

Let $(\bf R,v)$ be a symmetry operation, two k-points $\bf k$ and $\bf R^T k$ are equivalent

This is guaranteed by the following theorem, as describe in the book Computer Algebra and Materials Physics
A Practical Guidebook to Group Theoretical Computations in Materials Science:

and irreps at these k-points are also unitary equivalent.

Using SpaceGroupIrep package, I checked the irreps  corresponding to the two k points discussed here, i.e., (1/2, 0, 0) and (0, 1/2, 0), as shown below:

But I didn't see their equivalence at first glance.

For $P4_2/mnm$, (1/2, 0, 0) and (0, 1/2, 0) are transformed to each other by four-fold screw operation.

According to the data here, I verified as follows in Mathematica:

It is actually a non-trivial task to numerically find a transformation $U$ between two equivalent projective irreps $D_{1}$ and $D_{2}$ of group $G$ s.t. $U^{-1} D_{1}(g) U = D_{2}(g) \quad (\forall g \in G)$.
When $D_{1}$ and $D_{2}$ have the same factor systems, spgrep.representation.get_intertwiner can compute the transformation $U$. However, when comparing two different k-points, the factor systems are also different in general, and I don't know how to calculate $U$ in such a case. I will investigate on this. Thank you for stimulating this discussion!
BTW, the appropriate place to discuss your validation will be SpaceGroupIrep's issue page because these irreps are not same as those of spgrep.

It is actually a non-trivial task to numerically find a transformation $U$ between two equivalent projective irreps $D_1$ and $D_2$ of group $G$ s.t. $U^-1D_1(g)U=D_2(g) \quad (\forall g \in G).$

With a simple Google search with the keywords "s.t. abbreviation math", it shows that s.t. means  “such that” or “so that”.

The above relationship described here between $D_1(g)$ and $D_2(g)$ is conjugate isomorphism.

When $D_1$ and $D_2$ have the same factor systems,

Here, does the term factor system refer to little co-group?

However, when comparing two different k-points, the factor systems are also different in general, and I don't know how to calculate $U$ in such a case.

I've initiated a similar discussion here, and the JordanDecomposition based solution suggested by Gianluca Gorni seems like a good way to go.

BTW, the appropriate place to discuss your validation will be SpaceGroupIrep's issue page because these irreps are not same as those of spgrep.

The author of SpaceGroupIrep is a friend of mine, and we discussed this in private.

Here, does the term factor system refer to little co-group?

I mean $\mu$ in spgrep's document.

and the JordanDecomposition based solution suggested by Gianluca Gorni seems like a good way to go.

The Jordan decomposition is notoriously known to vulnerable to numerical noise. So I'm not sure whether it works.

The Jordan decomposition is notoriously known to vulnerable to numerical noise. So I'm not sure whether it works.

Another approach is based on Eigenvalue and Gauss-elimination, as represented by Hans Dolhaine in the above wolfram forum disussion:
(*Your matrices  *)
A = {{-I, 0, 0, 0}, {0, I, 0, 0}, {0, 0, 0, -I}, {0, 0, -I, 0}};
B = {{0, 1, 0, 0}, {-1, 0, 0, 0}, {0, 0, 0, I}, {0, 0, I, 0}};
(* Are they conjugates , do they have the same Eigenvalues (Thanks to Daniel)  ?*)
Eigenvalues[A]
Eigenvalues[B]
 (* The potential Matrix for the transformation *)
mm = Table[m[i, k], {i, 1, 4}, {k, 1, 4}];
mm // MatrixForm
(* Make an equation for your problem *)
e1 = # == 0 & /@ Flatten[A.mm - mm.B]
(* and transform it to an algebraic problem *)
e2 = CoefficientArrays[e1, Flatten[mm]]
(* get the according matrix *)
e3 = Normal[e2][[2]];
e3 // MatrixForm
(*check whether a solution is possible ( that means det = 0 ) *)
Det[e3]
(* There are 16 - rank of matrix = 8 solutions of the problem *)
MatrixRank[e3]
(*Find the solutions to the enhanced problem *)
vecs = NullSpace[e3]
(* Transform the solution vectors back to matrices *)
mats = Partition[#, 4] & /@ vecs
(* each fulfills the original problem, as it must be *)
Simplify[A.# - #.B] & /@ mats
(* but none is invertible  *)
Det[#] & /@ mats
(* so sum them up *)
mat = Total[mats]
Det[mat]
(* and *)
A.mat - mat.B

I mean $\mu$ in spgrep's document.

Projective representation is the method used in this package to obtain the small representation, i.e., the projective irreps of little co-group.


Task Review

https://github.com/AlejandraKeber/space-travelers-hub/projects/1
We are a team of two members 😄

Hi @ShinhyoBelok and @AlejandraKeber 👍 ,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Highlights
Kanban Board set up properly ✔
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


cleaning up pr testing

deleting the test file I posted yesterday

Coverage increased (+0.01%) to 79.66% when pulling 3e33e1851fa303fecb0a03293b9981c2d5f70ce1 on dfolch:network_docs into 7110407b16a708d196f3df4089af4fb488a320f5 on pysal:network_docs.


Support HTTP basic authentication to restrict access

Is your feature request related to a problem? Please describe.
Using HTTP basic authentication to restrict access is a common scenario in the usage of HTTP reverse-proxy .
Describe the solution you'd like
I can use the HTTP basic authentication plugin to protect the API of the backend, avoiding the none authenticated access.
Describe alternatives you've considered
No any alternatives in the Easegress
Additional context
The solution of the Nginx

I'm interested in implementing this. Here's proposal:
We could create new filter for HTTP basic authentication:
name: basic_auth
kind: HTTPBasicAuthentication
userFile: '/etc/apache2/.htpasswd'
# OR
useEtcd: true

Authorized users can be either listed in a file where each line is like userY:_md5_encrypted_pw_ or queried from etcd dynamically for each query.
Then this filter is used together with GlobalFilter and HTTPServer:
name: basicAuthFilter
kind: GlobalFilter
beforePipeline:
  flow:
    - filter: basicAuth
      jumpIf: { invalid: END }
  filters:
    - name: basic_auth
      kind: HTTPBasicAuthentication
      userFile: '/etc/apache2/.htpasswd'
      # OR
      useEtcd: true
---
kind: HTTPServer
name: server
port: 10081
globalFilter: basicAuthFilter
keepAlive: true
https: true
rules:
    - paths:
      - pathPrefix: /authorized-api
        backend: authorized-api # only authorized request pass here

In order to access authorized paths, HTTP request should contain Authorization header: Authorization: Basic <credentials> where <credentials> is Base64 encoding of userY:_md5_encrypted_pw_ user and password pair. HTTPBasicAuthentication filter Base64 decodes the header (only <credentials> part) and verifies if given user is listed in authorized users and if the MD5 encrypted password is correct. If not HTTPBasicAuthentication returns invalid and GlobalFilter will interrupt the request.
Here's sequence diagram of authorized request:

(AuthorizedUsers is either file userFile or etcd. AuthorizedApi is defined in HTTPServer.rules and here just for example)
Reference: https://en.wikipedia.org/wiki/Basic_access_authentication

Another idea:
Instead of creating new type of filter, the httpBasic could be part of the existing Validator. So httpBasic would the fifth option along headers, jwt, signer and oauth2 that we have currently. Here's the previous example updated:
name: basicAuthFilter
kind: GlobalFilter
beforePipeline:
  flow:
    - filter: basicAuth
      jumpIf: { invalid: END }
  filters:
    - name: basicAuth
      kind: Validator
      basicAuth:
        userFile: '/etc/apache2/.htpasswd'
        # OR
        useEtcd: true
---
kind: HTTPServer
name: server
port: 10081
globalFilter: basicAuthFilter
keepAlive: true
https: true
rules:
    - paths:
      - pathPrefix: /authorized-api
        backend: authorized-api # only authorized request pass here

Both solutions are good to me, but you may notice the status code of the validator failed and authentication failed are different( avoiding to use same status code to return).

for "or queried from etcd dynamically for each query", we need to use some kind of cache to avoid access etcd for every request.

for "or queried from etcd dynamically for each query", we need to use some kind of cache to avoid access etcd for every request.

HTTP Basic Auth would request with BASE64(username&password) every time, following Bomin's idea, I think to cache the BASE64(username&password) directly after authorized successfully could save a lot of works.


[BUG] Overriding OSD styles is breaking the interface

https://github.com/opensearch-project/dashboards-observability/blob/ea2fb2c1669a229f4a58de145db81247eaec6b18/public/components/event_analytics/explorer/sidebar/sidebar.scss#L155-L158
.deSidebar is a class name used by OSD and the min-width and max-width break the interface. As a result of these, the sidebar on Discover is too wide and clipped by the parent, hiding the scollbar and vital buttons.

On second thought, looks like OSD has borrowed code from observability and as such, they have to change theirs.

Spoke to Eric. Looks like Observability borrowed the code and will need to decouple.

https://github.com/opensearch-project/dashboards-observability/blob/main/public/components/event_analytics/explorer/sidebar/sidebar.scss#L155
Naming changed, fixed


Please add a LICENSE file

I believe your package is intended to be MIT like Meteor itself and most of the community's packages, but please explicitly add the LICENSE (also to meteor-accounts-salesforce)

Thanks, done


Break other Weatherlink integration https://github.com/siku2/hass-weatherlink

The problem
If you have the Weatherlink integration from https://github.com/siku2/hass-weatherlink installed and then you install https://github.com/astrandb/weatherlink integration it breaks the one from siku2.
Version of Weatherlink integration having the issue?
0.9.6
Version of Home Assistant Core having the issue?
2023.12.3
Anything in the logs that might be useful for us?
Thanks for your work on this integration. I tested your Weatherlink integration in my test HA environment and liked that it shows stats like Rain this month and Rain this year. My test environment didn't have https://github.com/siku2/hass-weatherlink integration installed. When I installed it into my Production HA environment it cause the other integration not to load. It would be nice if both could work together. Siku2's integration collects the data in realtime using the IP of the Weatherlink station.

Diagnostic data file
No response
Additional information
No response

Thanks for your work on this integration. I tested your Weatherlink integration in my test HA environment and liked that it shows stats like Rain this month and Rain this year. My test environment didn't have https://github.com/siku2/hass-weatherlink integration installed. When I installed it into my Production HA environment it cause the other integration not to load. It would be nice if both could work together. Siku2's integration collects the data in realtime using the IP of the Weatherlink station.

@raf10gh These two integrations hav differnt approaches to collecting data. There are pros and cons with both models. This integration uses the Weatherlink cloud API and therefore supports the entire product range from Davis Weatherlink. The two integrations cannot coexist in the same HA instance. I will make a note of that on the Readme page.