[BUG] keras.layers.StringLookup and Vocabulary of Tensors

There is a bug in keras.layers.StringLookup when initializing it with a vocabulary of tensors.
import tensorflow as tf

vocab = ["a", "b", "c", "d"]
data = [["a", "c", "d"], ["d", "z", "b"]]
layer = tf.keras.layers.StringLookup(vocabulary=tf.convert_to_tensor(vocab) mask_token="[MASK]")
layer(data)

Output:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
[<ipython-input-9-0fea6eb1a832>](https://localhost:8080/#) in <cell line: 3>()
      1 vocab = ["a", "b", "c", "d"]
      2 data = [["a", "c", "d"], ["d", "z", "b"]]
----> 3 layer = tf.keras.layers.StringLookup(vocabulary=tf.convert_to_tensor(vocab), mask_token="[MASK]")
      4 layer(data)

4 frames
[/usr/local/lib/python3.10/dist-packages/keras/src/layers/preprocessing/string_lookup.py](https://localhost:8080/#) in <listcomp>(.0)
    372         vocabulary = vocabulary.numpy()
    373         return np.array(
--> 374             [tf.compat.as_text(x, self.encoding) for x in vocabulary]
    375         )
    376

AttributeError: 'StringLookup' object has no attribute 'encoding'

I believe I found the reason for the bug.
In the implementation of StringLookup.__init__, we find:
        super().__init__(
            max_tokens=max_tokens,
            num_oov_indices=num_oov_indices,
            mask_token=mask_token,
            oov_token=oov_token,
            vocabulary=vocabulary,
            idf_weights=idf_weights,
            invert=invert,
            output_mode=output_mode,
            pad_to_max_tokens=pad_to_max_tokens,
            sparse=sparse,
            name=name,
            vocabulary_dtype="string",
            **kwargs,
        )
        self.encoding = encoding
        self._convert_input_args = False
        self._allow_non_tensor_positional_args = True
        self.supports_jit = False

Note that it invokes the superclass (IndexLookup) constructor before setting the encoding. Then, in the implementation of IndexLookup.__init__, we find:
        if vocabulary is not None:
            self.set_vocabulary(vocabulary, idf_weights)

But set_vocabulary invokes _tensor_vocab_to_numpy:
        if tf.is_tensor(vocabulary):
            vocabulary = self._tensor_vocab_to_numpy(vocabulary)

Which tries to access self.encoding:
    # Overridden methods from IndexLookup.
    def _tensor_vocab_to_numpy(self, vocabulary):
        vocabulary = vocabulary.numpy()
        return np.array(
            [tf.compat.as_text(x, self.encoding) for x in vocabulary]
        )

Since self.encoding is not yet initialized, an error occurs.
It seems version 3.0.0 of Keras introduced this bug. In version 2.15.0, the StringLookup constructor initializes self.encoding before calling the superclass constructor:
        self.encoding = encoding

        super().__init__(
            max_tokens=max_tokens,
            num_oov_indices=num_oov_indices,
            mask_token=mask_token,
            oov_token=oov_token,
            vocabulary=vocabulary,
            vocabulary_dtype=tf.string,
            idf_weights=idf_weights,
            invert=invert,
            output_mode=output_mode,
            sparse=sparse,
            pad_to_max_tokens=pad_to_max_tokens,
            **kwargs
        )

Hi @rlcauvin ,
Thanks for report. I have reporduced the issue with Keras3 and TF2.15v as well. Tested with Tf2.12v and it works well. The rootcause pointed by you seems proper solution. In TF2.12v ,  I can see self.encoding before super class constructor call.
https://github.com/keras-team/keras/blob/f9336cc5114b4a9429a242deb264b707379646b7/keras/layers/preprocessing/string_lookup.py#L331-L333
Please feel free to create a PR if you are willing to contribute.

Hi @rlcauvin ,
Proposed a PR along with test case. Thanks!


cargo-shuttle: 0.21.0 -> 0.22.0

Diff: https://github.com/shuttle-hq/shuttle/compare/v0.21.0...v0.22.0
Changelog: https://github.com/shuttle-hq/shuttle/releases/tag/v0.22.0
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 246789 run on x86_64-darwin 1

1 package built:

cargo-shuttle


Capture NB IOT payload in database

Dear Tanganelli,
I am looking to obtain data that arrives from NB IOT module.  The data are in JSON format. I need to capture payload and save it locally to database.
What is the best way to do it?

Hi,
pardon but I don't understand your question. I mean, which is your architecture? Do you have a CoAP server? Or a CoAP client? What do you mean for "capture" payload?
BR
Giacomo

Hi,
I am planing to use COAP server to get messages for NB IOT device (it is clinet). I am just looking the way how to save message data that are coming to the server from the IOT device. For example if my NB IOT device sending temperature and humidity I want to save locally in the database or just in the log file with two columns (temp and humidity) and values corresponding.

Ok, now I get the point. The simplest way to deal with this is to create on the CoAP server a resource for every IoT NB node, the resource should expose a POST (or PUT) method to be called from clients. On the other hand, IoT NB devices will send a POST (or PUT) requests to their specific resource URI on the server, filling the payload with the json representation of the data. In the handler of the POST (or PUT) you can easily read the payload and store it in the database.  For this last point take a look at the exampleresource.py
BR
Giacomo


Reflected laser ray disappears before reflection point (not sure if a bug)

The problem is shown on following gif. The laser rays looks normal while they aren't reflected. If they are reflected lasers disappear before theirs reflection points. Is it normal? Is there an explanation if so?

zk-283.blend.zip

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Your scene is malformed: you need to set the outside volume of the material of the "spiral" (or to any other object inside the scattering volume). It isn't set so LuxCore uses the default scene volume (i.e. nothing, clear space). LuxCore deduces the volume a ray was traveling trough when it hits a surface.
Once you set the materiel exterior volume, it will work fine:

Thank you, it works


Tang Operator Failed in Multiarch image

Hi,
I tried the with multi-arch image but this time it is not progressing at all.
I am using the following operator sdk version.
operator-sdk version
operator-sdk version: "v1.21.0", commit: "89d21a133750aee994476736fa9523656c793588", kubernetes version: "1.23", go version: "go1.17.10", GOOS: "linux", GOARCH: "s390x"

# operator-sdk run bundle quay.io/sec-eng-special/tang-operator:multi-arch --index-image quay.io/operator-framework/opm:v1.23.0
FATA[0002] Failed to run bundle: load bundle metadata: metadata not found in bundle-2257575074

operator-sdk run bundle quay.io/sec-eng-special/tang-operator:multi-arch
FATA[0002] Failed to run bundle: load bundle metadata: metadata not found in bundle-341866069

@gauravpbankar: can you please provide some hint about how to install the tang-operator multi-arch image?
I understand it is built up on the different multi-arch images but, how is it installed?

Hi @sarroutbi,
I have checked with @mp-redhat and i can see that your bundle images are still pointing to single arch image.
tang-operator/bundle/manifests/tang-operator.clusterserviceversion.yaml
- /manager
 image: quay.io/sec-eng-special/tang-operator:v0.0.25

so you should build bundle image using multi-arch image from your official repo which we built using Github action.
So following steps you should followbelow steps to build bundle images using multi-arch:
$ make bundle IMG="quay.io/sec-eng-special/tang-operator:multi-arch"
$ make bundle-build bundle-push BUNDLE_IMG="quay.io/sec-eng-special/tang-operator-bundle:multi-arch"

Below are the events which shows we have used multi-arch image from your official repo:
oc describe pod/tang-operator-controller-manager-57b7d5b9f5-8vhdf
Events:
  Type    Reason          Age   From               Message
  ----    ------          ----  ----               -------
  Normal  Scheduled       85s   default-scheduler  Successfully assigned tang-operator-system/tang-operator-controller-manager-57b7d5b9f5-8vhdf to worker2.motley.cp.fyre.ibm.com by master2.motley.cp.fyre.ibm.com
  Normal  AddedInterface  84s   multus             Add eth0 [<IP_ADDRESS>/22] from openshift-sdn
  Normal  Pulling         84s   kubelet            Pulling image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0"
  Normal  Pulled          80s   kubelet            Successfully pulled image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0" in 3.570125103s
  Normal  Created         80s   kubelet            Created container kube-rbac-proxy
  Normal  Started         80s   kubelet            Started container kube-rbac-proxy
  Normal  Pulling         80s   kubelet            Pulling image "quay.io/sec-eng-special/tang-operator:multi-arch"
  Normal  Pulled          74s   kubelet            Successfully pulled image "quay.io/sec-eng-special/tang-operator:multi-arch" in 5.564040887s
  Normal  Created         74s   kubelet            Created container manager
  Normal  Started         74s   kubelet            Started container manager

Hello. Thanks for clarifying. I updated the bundle image to:
quay.io/sec-eng-special/tang-operator-bundle:multi-arch
@mp-redhat : Can you please check if you can start such bundle? Command should be similar to:
operator-sdk run bundle quay.io/sec-eng-special/tang-operator-bundle:multi-arch --index-image quay.io/operator-framework/opm:v1.23.0

@sarroutbi ,
Below difference we can see after bulding bundle image using multi-arch tang image:
git diff
diff --git a/bundle/manifests/tang-operator.clusterserviceversion.yaml b/bundle/manifests/tang-operator.clusterserviceversion.yaml
index ca1dec0..89fad97 100644
--- a/bundle/manifests/tang-operator.clusterserviceversion.yaml
+++ b/bundle/manifests/tang-operator.clusterserviceversion.yaml
@@ -37,17 +37,6 @@ spec:
       displayName: Tang Server
       kind: TangServer
       name: tangservers.daemons.redhat.com
-      resources:
-      - kind: Deployment
-        version: v1
-      - kind: ReplicaSet
-        version: v1
-      - kind: Pod
-        version: v1
-      - kind: Secret
-        version: v1
-      - kind: Service
-        version: v1
       specDescriptors:
       - description: HealthScript is the script to run for healthiness/readiness
         displayName: Health Script to execute
@@ -318,7 +307,7 @@ spec:
                 - --leader-elect
                 command:
                 - /manager
-                image: quay.io/sec-eng-special/tang-operator:v0.0.25
+                image: quay.io/sec-eng-special/tang-operator:multi-arch
                 livenessProbe:
                   httpGet:
                     path: /healthz
@@ -335,10 +324,10 @@ spec:
                 resources:
                   limits:
                     cpu: 100m
-                    memory: 400Mi
+                    memory: 30Mi
                   requests:
                     cpu: 100m
-                    memory: 200Mi
+                    memory: 20Mi
                 securityContext:
                   allowPrivilegeEscalation: false
               securityContext:
diff --git a/config/manager/kustomization.yaml b/config/manager/kustomization.yaml
index 053bc1c..932c2d4 100644
--- a/config/manager/kustomization.yaml
+++ b/config/manager/kustomization.yaml
@@ -13,4 +13,4 @@ kind: Kustomization
 images:
 - name: controller
   newName: quay.io/sec-eng-special/tang-operator
-  newTag: v0.0.25
+  newTag: multi-arch

Can you check  your config/manager/kustomization.yaml file as it is still having latest tag?

Those need to be changed manually, as default memory limits are not valid, and removal of resources result on scorecard issues

@sarroutbi ,
In our case above changes are done after running below commad automatically, i think it will replace tag from both file:
make bundle IMG="quay.io/sec-eng-special/tang-operator:multi-arch"
Which tag you used for creating bundle image:

What I do is:
make bundle IMG="quay.io/sec-eng-special/tang-operator:multi-arch"
This result on the change that you pointed out previously. Then, I modify file "bundle/manifests/tang-operator.clusterserviceversion.yaml", to maintain only image related change.
After that, I pushed the bundle:
make bundle-build bundle-push BUNDLE_IMG="quay.io/sec-eng-special/tang-operator-bundle:multi-arch"

Hi @sarroutbi , I've build the multi arch as per the ppc process. But looks like I am getting the same error mkdir /database permission issue.  podman inspect on the multi arch and index shows arch as s390x.
# oc logs quay-io-madhu-pillai-tang-s390x-latest
mkdir: can't create directory '/database': Permission denied

operator-sdk run bundle quay.io/madhu_pillai/tang_s390x:latest --index-image quay.io/operator-framework/opm:latest

INFO[0008] Successfully created registry pod: quay-io-madhu-pillai-tang-s390x-latest
INFO[0008] Created CatalogSource: tang-operator-catalog
INFO[0008] OperatorGroup "operator-sdk-og" created
INFO[0008] Created Subscription: tang-operator-v0-0-25-sub
FATA[0120] Failed to run bundle: install plan is not available for the subscription tang-operator-v0-0-25-sub: timed out waiting for the condition

# podman images | grep 'quay.io/operator-framework/opm'
quay.io/operator-framework/opm                              latest      4e5e74e4e34c  3 weeks ago   67.8 MB

podman inspect quay.io/operator-framework/opm:latest | grep s390x
          "Architecture": "s390x",

podman  inspect quay.io/madhu_pillai/tang_s390x:latest | grep -i arch
          "Architecture": "s390x"

@mp-redhat : have you tried operator-sdk run bundle quay.io/sec-eng-special/tang-operator-bundle:multi-arch --index-image quay.io/operator-framework/opm:v1.23.0 command to check if it starts correctly on S390x architecture?

@sarroutbi : That worked. Thank you. No idea what made it not working before...
# operator-sdk run bundle quay.io/sec-eng-special/tang-operator-bundle:multi-arch --index-image quay.io/operator-framework/opm:v1.23.0
INFO[0010] Successfully created registry pod: quay-io-sec-eng-special-tang-operator-bundle-multi-arch
INFO[0010] Created CatalogSource: tang-operator-catalog
INFO[0010] OperatorGroup "operator-sdk-og" created
INFO[0010] Created Subscription: tang-operator-v0-0-25-sub
INFO[0022] Approved InstallPlan install-dxbh9 for the Subscription: tang-operator-v0-0-25-sub
INFO[0022] Waiting for ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" to reach 'Succeeded' phase
INFO[0022]   Waiting for ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" to appear
INFO[0044]   Found ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" phase: Pending
INFO[0046]   Found ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" phase: InstallReady
INFO[0047]   Found ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" phase: Installing
INFO[0068]   Found ClusterServiceVersion "tang-operator-system/tang-operator.v0.0.25" phase: Succeeded
INFO[0068] OLM has successfully installed "tang-operator.v0.0.25"
# oc get pods
NAME                                                              READY   STATUS      RESTARTS   AGE
3365b159ddd301f3f48995839d4b3e935e31f6bbe60d562015c0752252xk2q4   0/1     Completed   0          3m22s
quay-io-sec-eng-special-tang-operator-bundle-multi-arch           1/1     Running     0          3m39s
tang-operator-controller-manager-9bd47d6ff-v7jj6                  2/2     Running     0          2m57s

As I said in previous comment, index image quay.io/operator-framework/opm:latest is not valid.
Until operator registry issue is fixed, --index-image quay.io/operator-framework/opm:v1.23.0 is required


Adding browserSync for JavaScript file changes

Addresses #82
Summary of changes:
Updated the gulp file so that the user can make changes to JS without having to recompile.

Hey, @alex-page -- thanks for the fix! I've taken the gist of this and rolled it into my in-progress branch, aysnc-building and merged it with the new file watcher structure.
Does BrowserSync inject JS or do something special when you say: browserSync.reload('*.js')? If so, do you trust it?

From my understanding and usage of browserSync it doesn't do anything special or inject anything new when adding an additional watch parameter for JavaScript. There is the initial injection for the watching script, which from my understanding just waits for a change to any of the specified paths and files.
That additional line of code is saying:

Please watch JavaScript files
If the files change go through your normal process of reloading the page

This allows themer's to easily add small javascript snippets to the patterns which extend functionality without having to reload the page on every change. This is useful for creating an accordion or a dropdown menu pattern.


Bumping react-color from 2.17.3 to 2.18.1 is really slowing the drag down

The Dragging functionality of the color map and the slider is obviously slowed down.
It looks like I'm clicking to move the selector, but I'm actually dragging it, and it has almost a 1000ms of delay

Ditto. Rolling back to 2.17.3 helped.

Same problem. I was forced to use onChange to replace  onChangeComplete。Then write the debounce function in it.

I confirm this. Have to stay on 2.17.3.

any updates on this? is it "works as designed" and one should work around it with debouncing onChange or stay on the 2.17.x version?


Arrow function with never return type does not cause unreachable code when called

TypeScript Version:  3.8.3
Search Terms: arrow function never unreachable narrowing
Code
const f = (): never => {
    throw new Error()
}
f()
// should be unreachable but isn't
console.log()

Expected behavior:
Unreachable code detected. (7027) warning on line 6 (last line).
Actual behavior:
No warning.
Playground Link: link
Related Issues: #36753, #12825

As mentioned in linked #36753 (and many other) - it's design limitation.
Your const f need to have explicit type annotation to participate in CFA.
const f: () => never = ...


OpenID Connect and SAML Interoperability

In a scenario were ADFS is an IdP for various SP using SAML and a User has obtained a valid SAML Token to access one of the SP, it can then use the same token to access any other SP that use SAML.
But, what happens if the same users, in the same browser session tries to access a Resource that uses OpenID Connect registred on the same ADFS server? Will ADFS process the authorization flow without asking for User Credentials and provide an "access_token" silently?
Is there any Interoperability scenario between SAML, OAuth 2.0 and OpenID Connect, when using AD FS as common point?

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


Update Readme.md to Correct a typo in Heat Map

ORIGINAL:
"Entries marked <1 or >-1 are have a correlation that is close"
AFTER CORRECTION:
"Entries marked <1 or >-1 have a correlation that is close"

This is a small edit to correct a typo in the Heat Map section of the read me document. See below.
ORIGINAL:
"Entries marked <1 or >-1 are have a correlation that is close"
AFTER CORRECTION:
"Entries marked <1 or >-1 have a correlation that is close"


Update Existing Releases To Include Missing Assets Folder

Summary
Manually add the assets folder to the two previously released builds. Going forward this will be automated with work done in #25

I've updated the downloads on the releases tab to include the assets directory so things run nicely out of the box. 📦


fix go-releaser

Clear and concise description of the problem
The current config of GitHub actions is not configured for the git tag.
Additional context
ref: https://budougumi0617.github.io/2020/10/07/auto_release_by_goreleaser/

It seems GoReleaser isn't adapted Go 1.18...?


jest.useFakeTimers() leaking to other tests

🐛 Bug Report

To Reproduce
describe('test', () => {
  it('test A', (callback) => {
     jest.useFakeTimers()

     jest.runAllTimers()

     callback()
  })

  it('test B', (callback) => {
     setTimeout(callback, 20)
  })
})

Expected behavior
Second test should pass. I know I can overcome this by adding jest.useRealTimers() to test B but it seems redundant since I'm using fake timers only in the first test.
Link to repl or repo (highly encouraged)
https://repl.it/repls/LightheartedLawngreenCategory#sum.test.js
envinfo
  System:
    OS: macOS 10.15.3
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 8.9.3 - ~/.nvm/versions/node/v8.9.3/bin/node
    Yarn: 1.13.0 - ~/.nvm/versions/node/v8.9.3/bin/yarn
    npm: 5.5.1 - ~/.nvm/versions/node/v8.9.3/bin/npm
  npmPackages:
    jest: ^20.0.4 => 20.0.4

That is expected behaviour I would say. You should clean up timers, mocks etc. in afterEach if needed.

Is it expected behavior? I was under the impression that you can isolate jest.useFakeTimers() in describe code blocks:
per the docs:

If running multiple tests inside of one file or describe block, jest.useFakeTimers(); can be called before each test manually or with a setup function such as beforeEach. Not doing so will result in the internal usage counter not being reset.

Hey @FabianSellmann. From this blog post, it appears that this is in fact the intended behavior:
"You can still override this by specifying "timers": "fake" in the configuration or by calling jest.useRealTimers() and jest.useFakeTimers() global switches."
The "real" ticket in this case should be filed to update the docs.


Feat/segmenteddownloads

add dropdown for link editions download in data catalogue

Why are there so many merged commit here? Did you start working from main or staging branch?

Why are there so many merged commit here? Did you start working from main or staging branch? @luhamoza

my bad here, i think i started working from main branch, should i submit a new pr from staging branch ?

Why are there so many merged commit here? Did you start working from main or staging branch? @luhamoza

my bad here, i think i started working from main branch, should i close this one and submit a new pr from staging branch ?

if you could change it without much of a hassle, yes please

Why are there so many merged commit here? Did you start working from main or staging branch? @luhamoza

my bad here, i think i started working from main branch, should i close this one and submit a new pr from staging branch ?

if you could change it without much of a hassle, yes please

okay noted, will close this one, and create new pr


App front-end setup

Set up material-ui w/ basic custom theme and styled-components infra.

 Assemble UI of the editor


[Bug] Groups don't snap to grid (When "Always snap to grid" is enabled)

Example:

This is supported a core comfyui feature


Add the missing Serving Runtime pod sepc

Short description:
Observed that some parameters in the Serving Runtime specification were missing.
More details:
Several parameters from the runtime manifest are not present in the runtime resource. (https://github.com/kserve/kserve/blob/master/pkg/apis/serving/v1alpha1/servingruntime_types.go)

I added new parameters, spec_annotation and spec_labels, as they are specific to the model pod based on runtime  rather than the metadata. I used the prefix spec to enhance understanding.
Other parameters are standard ones that were missing from the codebase, as detailed in the manifest below.

What this PR does / why we need it:
This PR add the missing parameter for runtime CR
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

Summary by CodeRabbit

New Features

Enhanced configuration options for the ServingRuntime class, allowing users to specify additional parameters for Kubernetes pod scheduling and resource management.
New optional attributes include spec_labels, spec_annotations, affinity, node_selector, tolerations, and volumes.

Documentation

Expanded documentation for the constructor to include descriptions of the newly added parameters.

@tarukumar
The file link is just a test, we still need to generate the resource after the merge.
I will do that once my PR is merged.

@tarukumar The file link is just a test, we still need to generate the resource after the merge. I will do that once my PR is merged.
Doesn't it make sense to reopen this pr and merge it once you pr is merged

i will regenerate and send the pr here

i will regenerate and send the pr here

My PR was merged

@myakove if you want you can send the PR i am out for couple of hour for important work


fix(common): Add DCV converter for MM -> Gson

Resolves the issue discussed in KyoriPowered/adventure#1130 for the modded platforms.

Thank you for the fix!


AssertionError in Evaluation

Hi,thanks for your contribution.When I use this command to evaluate the pretrained model, I meet the some errors.
bash tools/dist_test.sh configs/animal/2d_kpt_sview_rgb_img/topdown_heatmap/ap10k/CLAMP_ViTB_ap10k_256x256.py work_dirs/CLAMP_ViTB_ap10k_256x256/epoch_210.pth 2 "0,1"
Errors are follows:

/home/administrator/Desktop/zy/CLAMP/mmcv/mmcv/cnn/bricks/transformer.py:28: UserWarning: Fail to import MultiScaleDeformableAttention from mmcv.ops.multi_scale_deform_attn, You should install mmcv-full if you need this module.
warnings.warn('Fail to import MultiScaleDeformableAttention from '
Traceback (most recent call last):
File "tools/test.py", line 174, in
main()
File "tools/test.py", line 156, in main
outputs = multi_gpu_test(model, data_loader, args.tmpdir,
File "/home/administrator/Desktop/zy/CLAMP/mmpose/apis/test.py", line 70, in multi_gpu_test
result = model(return_loss=False, **data)
File "/home/administrator/miniconda3/envs/clamp/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "/home/administrator/miniconda3/envs/clamp/lib/python3.8/site-packages/torch/nn/parallel/distributed.py", line 1040, in forward
output = self._run_ddp_forward(*inputs, **kwargs)
File "/home/administrator/miniconda3/envs/clamp/lib/python3.8/site-packages/torch/nn/parallel/distributed.py", line 1000, in _run_ddp_forward
return module_to_run(*inputs[0], **kwargs[0])
File "/home/administrator/miniconda3/envs/clamp/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
return forward_call(*input, **kwargs)
File "/home/administrator/Desktop/zy/CLAMP/mmcv/mmcv/runner/fp16_utils.py", line 98, in new_func
return old_func(*args, **kwargs)
File "/home/administrator/Desktop/zy/CLAMP/mmpose/models/detectors/top_down.py", line 448, in forward
return self.forward_test(
File "/home/administrator/Desktop/zy/CLAMP/mmpose/models/detectors/top_down.py", line 545, in forward_test
assert img.size(0) == len(img_metas)
AssertionError

Here the img.size(0) is 32 while the length of img_metas is 1, so I got the AssertionError. What should I do?

Did you follow the instructions to install related packages? I did not meet such an error.

Of course. I follow the instruction to install mmcv and mmpose.
But when I run dist_train.sh, it gives me the AttributeError: ‘MMDistributedDataParallel‘ object has no attribute ‘_sync_params‘  . I solve this problem according to this blog . After that everything is OK in training.
But when I try use dist_test.sh to evaluate the pretrained model, it gives me the AssertionError above. My cuda version is 11.4 and my pytorch version is 1.13.1

I did not test my code on torch 1.13. You may have a try on lower versions, such as torch 1.7 1.8.


Second try at Pull Request for issue 169

I was using a branch and it did not take the first time.

Thank you Nick!
On Sep 22, 2015 12:01 PM, "Nicholas Stein"<EMAIL_ADDRESS>wrote:

I was using a branch and it did not take the first time.
You can view, comment on, or merge this pull request online at:
https://github.com/QuantConnect/Lean/pull/171
Commit Summary

Issue 169 Rolling Window
Fix RollingWindow
Merge branch 'issue_169'

File Changes

M Indicators/RollingWindow.cs
https://github.com/QuantConnect/Lean/pull/171/files#diff-0 (1)
M Tests/Indicators/RollingWindowTests.cs
https://github.com/QuantConnect/Lean/pull/171/files#diff-1 (47)

Patch Links:

https://github.com/QuantConnect/Lean/pull/171.patch
https://github.com/QuantConnect/Lean/pull/171.diff

—
Reply to this email directly or view it on GitHub
https://github.com/QuantConnect/Lean/pull/171.

Will merge today.

Merged in https://github.com/QuantConnect/Lean/commit/93ebcf2a8dbff1e733adba1cbebbb66cdf0596de


Try to fix races in resident relaunching

@jeschkies oh, that's a much nicer pattern, thanks!
Yeah I just stole something from InstanceUpdater to see if this solves the races. I am all for ideas on how to make this code better. I would not feel good merging this to the feature branch :)

I would not feel good merging this to the feature branch :)

How about we run a loop on this branch to validate that it's the issue?

@jeschkies yes! let's do that :)

@jeschkies now that I am think about it, I don't think I can use the pattern you proposed :( Because I am serializing only per runspecId, all others still run in parallel while your stash pattern would mean that I do only one at a time...

The last 70 builds of this branch are green. Let's merge it!


Determine smallest possible size bin to use

I have 11,875 possible bin combinations (from 6x6x2" to 30x20x20") and a list of items that need to be shipped. Is it possible to figure out the smallest (most effective shipping cost wise) bin to pack items in?

"most effective shipping cost wise" depend on what you are saving cost or space.

if you are saving cost, which bin is the most effective cost? a small number of large bin or a large number of small bin?
if you are saving space, the small bin should be referred

@brandonros where you able to find a good way to find the most cost effective bin combination?


The effect of selecting the check box in version 1.15.0 is different from that in version 1.14.0

Describe the bug
After upgrading to version 1.15.0, I found that the checkbox style when selected is different from before. Is this a problem?
To Reproduce
https://github.com/peterbrittain/asciimatics/blob/master/samples/forms.py
Expected behavior
Same as version 1.14.0.
Screenshots
CheckBox [v1.15.0]

CheckBox [v1.14.0]

System details (please complete the following information):

OS and version: [Linux]
Python version: [docker-python:3.8.17-buster]
Python distribution: [CPython]
Asciimatics version [1.15.0]

Additional context

Well spotted!  That was a bug in the new f strings as I  moved to Python 3.  It's just a minor visual bug and doesn't affect any function.


Introduce ghost traits

Rust doesn't track panics or divergence in its type system.
For inherent implementations or simple function definitions, this is not a problem: we can always decorate them with pre- and post-conditions or similar.
For traits, however, things get more complicated. Annotating an impl method is useless: it will be exposed with the signature defined in the trait.
One possibility is to turn those annotations into trait methods that impose pre and post-conditions to impls. This is not OK in the settings of a trait from an external crate.
Solution
Instead, for every trait T, we should be able to define a trait T_ghost.
For each method f: T1 -> ... -> TN -> O (assuming no &mut) in T, T_ghost should contain:

f_pre: T1 -> ... -> TN -> bool;
f_post: T1 -> ... -> TN -> O -> bool;
f_decreases: T1 -> ... -> TN -> ANY a decreases clause (though this is very F* specific).
For each type  U in T, T_ghost should (probably?) contain U_refinement: U -> bool.

Technical details
Definition of the trait T_ghost
Should be right after or before the definition of T, otherwise, we need to refer to it explicitly when defining impls.
Impl blocks of T_ghost
The design should allow for inexistent T_ghost impls: sometimes, an implementation of trait T for a type is total and requires no annotation.
We need a way of connecting impl blocks for T and impl blocks for T_ghost very tightly: we don't want to ask the rust compiler for the trait resolution of both T and T_ghost.
An impl of T should correspond exactly to zero or one impl of T_ghost for the exact same type.
Instead, I think we should impose the following principle: if one wants to extract a T impl block with pre/postconditions/refinements/whatever, one should associate it with one T_ghost impl block.
T_ghost impls should be marked with an attribute (say is_ghost_trait) and should have a parent clause to T. This parent clause to T should resolve exactly to a concrete impl block. This way, whenever hax sees a is_ghost_trait impl, it finds it's T parent clause and links it automatically.
Parent traits in the extractions
We should reverse the parent-child relation between T and T_ghost in the extraction. In Rust, we cannot have T_ghost a parent of T, otherwise the pattern would not work for external traits. In the extraction, we should always be able to grab pre/posts given a impl of T.
Ergonomics
Users should (almost) never write T_ghost trait definition or impls. Instead, they should annotate traits methods and type.
Roadmap

[ ] add an is_ghost attribute in hax
[ ] generate *_ghost traits
[ ] edit the macros so that one can annotate an impl block with pre/post/...
(Note that default methods in T should be default as well in T_ghost, inheriting annotations)

Note: we want to get a minimal support for this ASAP.
Minimal means have the full mechanism, but without any sugar (if you want a precondition, then you'll have to write everything manually)


How can I stop a dynamic import component from preloading?

I am defining a series of dynamic components which are conditionally rendered. How can I stop the client from prefetching all of them before they are rendered? I can see them all downloading in Chrome's network tab.
Some of them are rather large and only a small % of our users may load them, I'd like to save on bandwidth.

Solved it, I was using copy pasta code from another older project which didn't use the loader option


Ipam pod IP not released

On our cluster, some nodes are rapidly out of free IP to assign, limit of number of assigned ipamblocks is reached. This cluster is having ~1200 total pods (350 active ones, others are completed jobs).
Expected Behavior
Jobs and normal pods should be started with new IP each time. Each node on the cluster should have around 50~60 IP allocated at any moment.
Current Behavior
One node (not the one where every job's pod starts, the cluster is rather evenly balanced), the 4th node in below example, is not releasing IPs. Here the report created by calicoctl ipam check command :
Datastore locked.
Checking IPAM for inconsistencies...

Loading all IPAM blocks...
Found 33 IPAM blocks.

Loading all IPAM pools...
  <IP_ADDRESS>/20
Found 1 active IP pools.

Loading all nodes.
Found 4 node tunnel IPs.

Loading all workload endpoints.
Found 223 workload IPs.
Workloads and nodes are using 227 IPs.

Looking for top (up to 20) nodes by allocations...
  srv-k8s-qual-4 has 1280 allocations
  srv-k8s-qual-3 has 59 allocations
  srv-k8s-qual-1 has 55 allocations
  srv-k8s-qual-2 has 48 allocations
Node with most allocations has 1280; median is 55

Scanning for IPs that are allocated but not actually in use...
Found 1215 IPs that are allocated in IPAM but not actually in use.
Scanning for IPs that are in use by a workload or node but not allocated in IPAM...
Found 0 in-use IPs that are not in active IP pools.
Found 0 in-use IPs that are in active IP pools but have no corresponding IPAM allocation.

We have to release manually the IPs in order to allow pods to be started on that node. Without that manual step, node can't schedule any pod anymore in a matter of hours. The k8s scheduler will continue scheduling pods on that machine, pods that will stay in ContainerCreating because no IP could be allocated, so those jobs are stuck indefinitely without human action.
To manually release the ipam as a workaround, we use the calicoctl ipam release command, after locking the datastore:
Check complete; found 1215 problems.
Releasing 1215 old IPs
Released 1215 IPs successfully
You may now unlock the data store.
Datastore unlocked.

Steps to Reproduce (for bugs)
I'm not sure how to reproduce this bug. We have 3 clusters in the same infrastructure, and this is the only one with that behavior.
I can't see any error in calico-node nor calico-kube-controller's logs, nothing suspicious.
My Environment

Calico version : 3.19.3
Orchestrator version : Kubernetes vanilla 1.19.8. (This cluster is almost 4 years old, not sure what was the first calico version, but calico was used since the begining)
Operating System and version: Linux 5.10.21

Calico configuration :

Datastore type : kubernetes
cni version : 0.3.1
ipam type : calico-ipam
IpinIp : Never
VXLan : Never
IPv6Support : false

Well, unfortunately there's nothing in those logs that suggests an error is occurring. Might just not have been captured, but it's hard to tell.

It seems that sometimes, the count of problematic IPs (unreleased) goes up when no new pod is scheduled

This seems to suggest that the CNI plugin is trying to allocate IPs for start the pod, but the container runtime thinks that the pod has failed and so tries to restart it. Calico relies on the container runtime to inform us when we need to release an IP address, so it is possible that this is a result of a bug in the container runtime you're using. I have seen this behavior before in several different runtimes. What container runtime are you using? CRI-O / containerd / something else?

I'm using containerd 1.4.6.
I just upgraded it to 1.4.11 and after a couple of hours, there's no unreleased IP anymore reported by calicoctl ipam check ! Let's wait for a little more but it looks promising

Problem seems to be fixed. I upgraded kubelet and containerd (+ ctr + crictl),but I guess only containerd had a role in this as you said. I haven't found in the release notes what can be related to my problem, but I'm glad it's fixed now :)
Thanks for your help @caseydavenport !


Print consoleReportPath path as file URI

Hi and thanks for this great plugin!
I suggest printing the report path as file URI to make it clickable in most terminals.
This makes it much easier for consumers to navigate to the report.
So instead of
https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/blob/31c31026fd5cacfeed4a4a4309cef3bdcd64ff8f/src/main/kotlin/com/autonomousapps/tasks/BuildHealthTask.kt#L43
you could write
  append("There were dependency violations. See report at file://${consoleReportPath}")

Sounds good! Do you want to PR that?

I think the PR linked should also resolve this. Closing this optimistically.


Enable spellcheck

This tool helps to detect typos in markdown files

/ok-to-test

@gvbalaji Use "approve" not lgtm. LGTM is used just to signal the final merge, approve is used to show your approval.
/approve
/lgtm


taint plugin don't execute

What happen?
[root@master-0 ~]#  cat Kubefile
FROM kubernetes:v1.20.0
COPY metrics-server.yaml .
CMD kubectl apply -f metrics-server.yaml
[root@master-0 ~]# cat Clusterfile
apiVersion: sealer.cloud/v2
kind: Cluster
metadata:
name: jdq-cluster
spec:
image: taint_test:v2.1
hosts:
- ips: [ <IP_ADDRESS> ]
roles: [ master ]
ssh:
passwd: "ka0@2021"
user: root
apiVersion: sealer.aliyun.com/v1alpha1
kind: Plugin
metadata:
name: taint
spec:
type: TAINT
action: PreGuest
data: |
<IP_ADDRESS> node-role.kubernetes.io/master:NoSchedule-

The taint plugin is not executed and no error is reported.

Relevant log output?
No errors is reported.

What you expected to happen?
No response
How to reproduce it (as minimally and precisely as possible)?
No response
Anything else we need to know?
No response
What is the version of Sealer you using?
v0.8.6 and v0.8.5
What is your OS environment?
centos 7
What is the Kernel version?
Linux master-0 3.10.0-1127.19.1.el7.x86_64
Other environment you want to tell us?

Cloud provider or hardware configuration:
Install tools:
Others:

@sunshinejdq #1854

@sunshinejdq , seems this bug is already fixed. i will close this issue, pls feel free to contact us if you have any questions


Versioning of project versions

The template should introduce a proper versioning workflow, which allows the developer to easily get/set/create/update the current version of the project.
Our current approach:
version:
	$(shell echo $(shell git describe --long --tags --dirty --always) > ../src/version)
	@echo $(shell cat ../src/version)

For reference: PHP helper for versions
This could also be "the feature" of an initial CLI command, yii app/version.

What's the use case?

When accessing an application I want to be 100% sure which version is running, sometimes an update might have failed or source-code is distributed (scaled) across multiple systems.
Like every program has a --version option.

Looks out of Yii scope to me. Also, one could use mercurial or even SVN or, far worse, CVS :)

Version can be easily maintained since:
https://github.com/yiisoft/yii2/pull/12727
But actual version detection is too application specific. See following for example:
https://github.com/yiisoft/yii2/pull/12727#discussion_r82987297


Unable to connect Squeezebox players (touch, boom, duet) to MAS

What version of Music Assistant has the issue?
2.0.0b32
The problem
When I try to connect squeezebox players with MAS, the players ate discovered by MAS but connection does not take place. I tried connection with Squeezebox Touch, Boom and Duet.
How to reproduce
As described in problem description: by trying to connect the player
Relevant log output
See descriptions below.
Additional information
See descriptions below
What version of Home Assistant Core are your running
2023.5.4
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Generic x86-64 (e.g. Intel NUC)

I just tried to connect the squeezebox touch. The device is now visible in the list of players. Connection didn't succeed.
I found the following log:
**2023-05-29 21:16:45 WARNING asyncio -- Executing <TimerHandle when=899038.402624412 SlimClient._send_heartbeat() created at /usr/local/lib/python3.11/site-packages/aioslimproto/client.py:643> took 0.235 seconds,
2023-05-29 21:17:13 WARNING asyncio -- Executing <TimerHandle when=899066.218535322 SlimClient._send_heartbeat() created at /usr/local/lib/python3.11/site-packages/aioslimproto/client.py:643> took 0.217 seconds
2023-05-29 21:17:41 WARNING asyncio -- Executing <Task pending name='Task-1205355' coro=<BaseSelectorEventLoop._accept_connection2() running at /usr/local/lib/python3.11/asyncio/selector_events.py:222> wait_for=<Future pending cb=[Task.task_wakeup()] created at /usr/local/lib/python3.11/asyncio/base_events.py:427> created at /usr/local/lib/python3.11/asyncio/selector_events.py:198> took 0.221 seconds,
2023-05-29 21:18:00 WARNING asyncio -- Executing <Task finished name='Task-1210075' coro=<SlimClient._process_helo() done, defined at /usr/local/lib/python3.11/site-packages/aioslimproto/client.py:504> result=None created at /usr/local/lib/python3.11/asyncio/tasks.py:374> took 0.207 seconds,
2023-05-29 21:18:09 WARNING asyncio -- Executing <Task finished name='Task-1212123' coro=<SlimprotoProvider._create_client() done, defined at /usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/init.py:149> result=None created at /usr/local/lib/python3.11/asyncio/streams.py:249> took 0.218 seconds,
2023-05-29 21:21:15 WARNING asyncio -- Executing <Handle StreamReaderProtocol.connection_made(<_SelectorSoc...e, bufsize=0>>) created at /usr/local/lib/python3.11/asyncio/selector_events.py:915> took 0.206 seconds,
2023-05-29 21:19:20 INFO music_assistant.players -- Player registered: 00:04:20:22:7e:5b/controller: 00:04:20:22:7e:5b
2023-05-29 21:21:53 WARNING asyncio -- Executing <Handle StreamReaderProtocol.connection_made(<_SelectorSoc...e, bufsize=0>>) created at /usr/local/lib/python3.11/asyncio/selector_events.py:915> took 0.223 seconds**

When I try to connect to the MAS music library, using the squeezebox duet controller, I get the following logs:
_2023-05-30 11:36:36 WARNING asyncio -- Executing <Task pending name='Task-39' coro=<MusicController._start_provider_sync..run_sync() running at /usr/local/lib/python3.11/site-packages/music_assistant/server/controllers/music.py:544> wait_for=<Future pending cb=[_chain_future.._call_check_cancel() at /usr/local/lib/python3.11/asyncio/futures.py:387, Task.task_wakeup()] created at /usr/local/lib/python3.11/asyncio/base_events.py:427> cb=[MusicAssistant.create_task..task_done_callback() at /usr/local/lib/python3.11/site-packages/music_assistant/server/server.py:293, MusicController._start_provider_sync..on_sync_task_done() at /usr/local/lib/python3.11/site-packages/music_assistant/server/controllers/music.py:558] created at /usr/local/lib/python3.11/site-packages/music_assistant/server/server.py:286> took 0.150 seconds,
future: <Task finished name='Task-724' coro=<SlimClient.volume_set() done, defined at /usr/local/lib/python3.11/site-packages/aioslimproto/client.py:301> exception=OSError(107, 'Transport endpoint is not connected') created at /usr/local/lib/python3.11/site-packages/music_assistant/server/server.py:286>,
2023-05-30 11:40:26 ERROR asyncio -- Task exception was never retrieved,
File "/usr/local/bin/mass", line 8, in ,
source_traceback: Object created at (most recent call last):,
sys.exit(main()),
File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run,
handle._run(),
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 1914, in _run_once,
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 607, in run_forever,
self._run_once(),
loop.run_forever(),
run(,
File "/usr/local/lib/python3.11/site-packages/music_assistant/main.py", line 108, in main,
File "/usr/local/lib/python3.11/site-packages/aiorun.py", line 273, in run,
self._context.run(self._callback, *self._args),
File "/usr/local/lib/python3.11/site-packages/aioslimproto/client.py", line 526, in _process_helo,
self.callback(EventType.PLAYER_CONNECTED, self),
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/init.py", line 166, in client_callback,
self._handle_connected(client),
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/init.py", line 523, in _handle_connected,
self.mass.create_task(client.volume_set(init_volume)),
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/server.py", line 286, in create_task,
task = self.loop.create_task(target),
Traceback (most recent call last):,
File "/usr/local/lib/python3.11/site-packages/aioslimproto/client.py", line 306, in volume_set,
await self._send_frame(,
File "/usr/local/lib/python3.11/site-packages/aioslimproto/client.py", line 424, in _send_frame,
self.disconnect(),
File "/usr/local/lib/python3.11/site-packages/aioslimproto/client.py", line 182, in disconnect,
self._writer.write_eof(),
File "/usr/local/lib/python3.11/asyncio/streams.py", line 338, in write_eof,
return self._transport.write_eof(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^,
File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 1111, in write_eof,
self.sock.shutdown(socket.SHUT_WR),
OSError: [Errno 107] Transport endpoint is not connected

Trying to discover Squeezebox Boom by MAS, I get the following logs:
2023-05-30 11:48:46 ERROR aioslimproto.discovery -- Error occured while trying to parse a datagram from ('<IP_ADDRESS>', 3483) - data: b'd\x00\n9\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04 \x1en\x7f'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 205, in datagram_received
dgram = Datagram.decode(data)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 42, in decode
return ClientDiscoveryDatagram(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 63, in init
assert msg[0] == "d"
^^^^^^^^^^^^^
AssertionError
Discovery has not been taken place.

Boom player was connected with mysqueezebox.com.
After disconnecting the Boom player is discovered by MAS. But after discovery same kind of logs:
2023-05-30 12:10:37 INFO music_assistant.players -- Player registered: 00:04:20:1e:6e:7f/boom: 00:04:20:1e:6e:7f
2023-05-30 12:12:11 ERROR aioslimproto.discovery -- Error occured while trying to parse a datagram from ('<IP_ADDRESS>', 3483) - data: b'd\x00\n9\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04 \x1en\x7f'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 205, in datagram_received
dgram = Datagram.decode(data)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 42, in decode
return ClientDiscoveryDatagram(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aioslimproto/discovery.py", line 63, in init
assert msg[0] == "d"
^^^^^^^^^^^^^
AssertionError

@poerlemans do you by have the slimproto integration installed in HA? If so that interferes with the slimproto provider in MA

I have not installed the slimproto integration in HA. For controlling the squeezeboxes in HA I use the Squeezebox integration.
But, because of the fact that the LMS server is not running anymore (because I use now MAS), this Squeezebox integration is useless.
The connection problems of my squeezebox devices as described above were already present before HA integration of MAS was realized.

I'm very curious to see the effect of elimination of several slimproto bugs. I will test the improvements on real squeezebox hardware.

Yeah I guess @erkr missed the conversation we already had about this

Yep sorry

Please try with beta 35

I tested beta 35 with Squeezebox Touch, Boom and Duet.
Connection was possible with all three players.
Connection very stable with Squeezebox Touch (ethernet network connection).
Connection with Squeezebox Boom and Duet (both Wifi connection) sometimes interrupted and restored after some time.
Control of the players via Music Assistant web interface went smoothly.
Conclusion: very impressive improvements!
But very frequently the following log:
2023-06-10 12:15:54 ERROR asyncio  -- Task exception was never retrieved
future: <Task finished name='Task-15731' coro=<LmsCli._handle_cometd_request.._handle() done, defined at /usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py:549> exception=ValueError('too many values to unpack (expected 2)') created at /usr/local/lib/python3.11/site-packages/music_assistant/server/server.py:284>
source_traceback: Object created at (most recent call last):
File "/usr/local/bin/mass", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.11/site-packages/music_assistant/main.py", line 108, in main
run(
File "/usr/local/lib/python3.11/site-packages/aiorun.py", line 273, in run
loop.run_forever()
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 607, in run_forever
self._run_once()
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 1914, in _run_once
handle._run()
File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/controllers/webserver.py", line 115, in _handle_catch_all
return await handler(request)
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py", line 485, in _handle_cometd
self._handle_cometd_request(cometd_client, cometd_msg)
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py", line 560, in _handle_cometd_request
self.mass.create_task(_handle())
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/server.py", line 284, in create_task
task = self.loop.create_task(target)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py", line 550, in _handle
result = await self._handle_request(cometd_request["data"]["request"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py", line 579, in _handle_request
cmd_result = await cmd_result
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/cli.py", line 632, in _handle_status
return player_status_from_mass(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/models.py", line 348, in player_status_from_mass
cur_item = playlist_item_from_mass(mass, queue.current_item, queue.current_index, True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/music_assistant/server/providers/slimproto/models.py", line 179, in playlist_item_from_mass
artist, track = queue_item.streamdetails.stream_title.split(" - ")
^^^^^^^^^^^^^
ValueError: too many values to unpack (expected 2)

I have the strong impression that the connection interruptions with the Squeezebox Boom and Duet are not related to a bad Wifi connection. In my router I see upload and download activities during the time the player is not available in Music Assistant.

There can be uploads and downloads happening but if the nitrate can’t be supported then interruptions will occur. You can try lower quality streams such as mp3 in the advanced settings

Cool to hear this progress and that it now works for like 90% already.
I'll fix that last error you spotted in the logs. I also think that is what causes the interruptions as I noticed that all the "jive" based squeezebox players are really sensitive to errors in the cli. I had to reverse engineer Logitech Media Server in order to get it working but thats parts of the challenge.

Connection between Music Assistant and the players (Duet or Boom) also occur when nothing is playing. But I will try what lowering the quality stream will bring.
@marcelveldt I'm also very positive about what is realized already. For some reason interruptions were much less present this evening than some hours ago. So I hope that further improvement of the cli will result in good news.

@marcelveldt , @OzGav : I was talking about connection problems here above (https://github.com/music-assistant/hass-music-assistant/issues/1273#issuecomment-1585818104). I found these problems had to do with my internal network. After some adjustments, connection problems removed!

@poerlemans Ok so confirming all your squeeze box players are working fine now. If so I will close this

Ok I am going to spawn a new issue with the above feature requests to tidy things up. Likely this will be low priority but will be addressed at some point.


Add DigitalOcean mock api template

DigitalOcean is a popular cloud service provider, it would be nice to have a public mock api for it.
References

API Documentation: https://docs.digitalocean.com/reference/api/api-reference/
OpenAPI original source: https://api-engineering.nyc3.cdn.digitaloceanspaces.com/spec-ci/DigitalOcean-public.v2.yaml

Submitter checklist

[x] Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
[x] The PR request is well described and justified, including the body and the references
[x] The PR title represents the desired changelog entry
[x] OpenAPI and WireMock JSON files are valid
[x] The metadata files are added
[x] If provided, you have a permission to use this logo (Not provided)

Thanks you! It is a pretty big stub, but it should work. I guess we will need to reach out to Digital Ocean to get a logo approval, right?

Yes,
We would need to reach out to DigitalOcean to get permission to use their logo.

OK, let's start from merging it then

Thanks for your contribution @engineerakki !

@oleg-nenashev
I see CI is failing for this commit.
Are there any additional actions needed from me ?


add DUNEatLapp package

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/116887
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.0.0 -m "<description of version>" 67998de2443f9bdda4f4dfe1613495643cfb1a4c
git push origin v1.0.0


Add an option to configure encoding for "javadoc.options" file

Expected Behavior
There should be a way to specify which encoding is used to generate javadoc.options file.
Sample config causing the failure:
tasks.withType<Javadoc>().configureEach {
    (options as StandardJavadocDocletOptions).apply {
        bottom = "©"
    }
}

Set environment option _JAVA_OPTIONS=-Duser.country=DE -Duser.language=de and launch javadoc generation in Gradle.
Current Behavior
Currently javadoc.options is produced with Charset.defaultCharset() encoding, and defaultCharset might be different between Gradle worker and javadoc executable.
Unfortunately, javadoc tool in OpenJDK uses Charset.defaultCharset() when reading the options file, and there's no other way to tell which charset to use when parsing @javadoc.options file.
As far as I see, Gradle uses the default charset only when writing the options file: https://github.com/gradle/gradle/blob/023d74bc099d9fd956901636d4b661e9c5f474d4/subprojects/language-java/src/main/java/org/gradle/external/javadoc/internal/JavadocOptionFileWriter.java#L32-L40
See relevant javadoc parser in OpenJDK

https://github.com/openjdk/jdk/blob/37107fc1574a4191987420d88f7182e63c7da60c/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L336-L341
https://github.com/openjdk/jdk/blob/37107fc1574a4191987420d88f7182e63c7da60c/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java#L107-L108

Context
Build Scan: https://scans.gradle.com/s/l4itdppi5s3fs
Gradle
I'm facing javadoc: error - cannot read Input length = 1, and it looks like the failure is caused by a copyright character in javadoc.options file.
> Task :src:dist:javadocAggregate FAILED
Build cache key for task ':src:dist:javadocAggregate' is b54f1fa85f63801fd1e334e291107a46
Task ':src:dist:javadocAggregate' is not up-to-date because:
  No history is available.
file or directory 'D:\a\jmeter\jmeter\src\components\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\core\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\functions\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\jorphan\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\protocol\bolt\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\protocol\http\src\main\groovy', not found
file or directory 'D:\a\jmeter\jmeter\src\protocol\jdbc\src\main\groovy', not foundPicked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:hashCode=2 -Duser.country=DE -Duser.language=de
Starting process 'command 'C:\hostedtoolcache\windows\Java_Liberica_jdk\11.0.17-7\x64\bin\javadoc.exe''. Working directory: D:\a\jmeter\jmeter\src\dist Command: C:\hostedtoolcache\windows\Java_Liberica_jdk\11.0.17-7\x64\bin\javadoc.exe @D:\a\jmeter\jmeter\src\dist\build\tmp\javadocAggregate\javadoc.options
Successfully started process 'command 'C:\hostedtoolcache\windows\Java_Liberica_jdk\11.0.17-7\x64\bin\javadoc.exe''

javadoc: error - cannot read Input length = 1
Problems generating Javadoc.
  Command line issued: [C:\hostedtoolcache\windows\Java_Liberica_jdk\11.0.17-7\x64\bin\javadoc.exe, @D:\a\jmeter\jmeter\src\dist\build\tmp\javadocAggregate\javadoc.options]
  Generated Javadoc options file has following contents:
------
-locale 'en'
-bottom 'Copyright � 1998-2022 Apache Software Foundation. All Rights Reserved.'
-charset 'UTF-8'
-classpath 'D:\\a\\jmeter\\jmeter\\src\\bshclient\\buil

We consider setting the same encoding for both processes as the workaround to be used until this problem is fixed.

I'm inclined that the workaround might break when JVM toolchains are in use.
If Gradle process uses different Java than javadoc then JEP 400: UTF-8 by Default can default javadoc to UTF-8, while Gradle would default to something like CP-1251.

To put it another way, I'm inclined that  javadoc: error - cannot read Input length = 1 is a quite popular error message which causes a negative experience, especially for Gradle newbies. I think that the resolution of https://github.com/gradle/gradle/issues/22575 would make Gradle error messages more accessible, and it would improve the learning curve.


feat: MoveAlongPathEffect should maintain initial angle of the component

Description

See #2833

Checklist

[x] I have followed the Contributor Guide when preparing my PR.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues

Closes #2833

@spydon Coding style preference

      (target as AngleProvider).angle = (target is PositionComponent)
          ? -start.angle + (target as PositionComponent).nativeAngle
          : -start.angle;

instead of
(target as AngleProvider).angle = _lastAngle = -start.angle;
(target as AngleProvider).angle += (target is PositionComponent)
          ? (target as PositionComponent).nativeAngle
          : 0;

@spydon Coding style preference

I think it is even clearer to read it if you separate them and just add:
final _target = target;
(_target as AngleProvider).angle = -start.angle;
if(_target is PositionComponent) {
  _target.angle += _target.nativeAngle;
}


How did you develop for Raspberry Pi?

Hi Gerardo,
this is not really in issue more a question of interest..
How are you developing .net for the Raspberry Pi. The normal way is to use Visual Studio on Windows and place the binaries on the pi. But debugging is a little pain with that scenario.
I tried to compile MonoDevelop 7.x for the Pi, but unfortunately it didn't work. MonoDevelop would be nice because of the Remote Debugging feature ...
So what's your way of coding and debugging?
Dominik

Ok. You do not need mono develop at all. Compile on your pc. Just install mono, always keep it updated, just copy and paste libraries and exe. It will work.

That's the way I do it :-)
The problem is you have no chance for debugging (stepping through the code, check variables, etc).

Du you have a link for the plugin / server?
Or is there anywhere a tutorial for the first steps?

https://marketplace.visualstudio.com/items?itemName=Bongho.MonoRemoteDebugger

That´s awesome !
It lacks in some scenarios, but overall it´s great.
Anyway ... MonoDevelop would be a Solution, too.
Will try to compile the new one for Windows ...

If the project is not big and simple, yes you can use monodevelop with no problems. As soon as the project grows, the only way is to use VS and fulfill the code with logs.


useless "ln" deletion

deleting "ln" or any other busybox symlinks create fake self confidence,
because they easily can be restored cp /bin/busybox /bin/ln

Hi @tzawlxih , are you talking about https://github.com/ironPeakServices/hardened-alpine/blob/master/Dockerfile#L93 ? If so, that only removes broken symlinks.


feat: upgrade kubeclarity

This PR brings a new version of Kubeclarity and now supports multiple analyzers and scanners running in parallel.
To upgrade, first remove the current install and then manually remove the PVC and ns. Also, note that Kubeclarity does not support adding more scanners after deployment. So choose your scanner wisely ;-). I will add this note to the documentation.
Checklist

[ ] Architecture Design Records have been added as adr/*.md and appended to list in adr/_index.md, if applicable.
[x] The values-schema.yaml file and test/** fixtures have been updated to reflect code changes, if applicable.
[x] The OpenApi Schema from redkubes/otomi-api project is compatible with definitions from values-schema.yaml file, if applicable.
[x] Helm releases are meeting otomi's baseline security policies, if applicable.
[ ] Helm chart and helmfile changes are tested against upgrade scenario, if applicable.

will upgrade to openclarity


:art: Enhance the organization’s branding by adding a project logo as the profile picture.

🎨  Add project Logo:

[x] Design or select a suitable project logo. @zorp
[x] Upload the logo to the organization’s profile on GitHub.

Please ensure that the logo is clear and visually appealing at various sizes.

Logo created and added.


Remove support for component

According to component2jspm, there are several drawbacks of component such as that there is no more development activity. Its users are migrating to other tool (among others, to jspm).
Removing support for component means that we don't need to have and support component.json.

:+1:


rustfmt suddenly stopped working, won't format anymore

Out of nowhere, rustfmt has stopped working for one of my projects. It doesn't work in vscode with rust-analyzer, it doesn't work with cargo fmt on either stable or nightly in a terminal, and it doesn't work invoked on its own with rustfmt file. If there's syntax errors in the file it will complain, but otherwise it does nothing. rustfmt --check on a file that needs formatting returns success. I updated with rustup update after it broke and it didn't change anything. Please help.
rustfmt 1.7.0-stable (82e1608d 2023-12-21)
rustfmt 1.7.0-nightly (d5fd0997 2024-01-22)

@maia-s thanks for reaching out. Can you please put together a minimal reproducible example that someone can run rustfmt on to reproduce the issue. Without that there's not much anyone can do to help. Please also provide details about any configuration options that you're using.

I understand, but if I try to make a minimal reproducible example rustfmt works on it again. Is there a way for me to diagnose this somehow?

It seems to be related to having a lot of bounds on a trait.

If you can't reproduce the issue with a simple snippet can you put together a small test repo that illustrates the issue and send a link to that?

I'll try. I'll let you know if I make any progress on that.
I've isolated the issue to traits depending on one particular trait in this crate, but the trait in question has bounds from the entire crate, and currently I can only reproduce rustfmt not working in one file. That file uses the exact same construct as other files in the crate, but those other files work now. The problematic file also has another issue (not rustfmt related, I think) that causes rustc to be unable to infer the type of Self unless I leave out one particular associated type bound (again, the same construct works in other files). I have no idea what's going on there, but maybe whatever causes that also causes rustfmt to fail.

Luckily rustfmt doesn't require its input to compile, it just needs to parse as valid rust code.
fn some_function() {
    if let Some(x) = some_variable_thats_no_defined {
        // code
    }
}

So no need to recreate things exactly. You can use dummy names to get things down to a reproducible test case.

Thank you! That information helped a lot. The problem is actually caused by having a comment in the list of trait bounds. This snippet is as minimal as I could get it while still reproducing the problem:
trait Trait:
    //
    Bound
{}

Any part or contents of this trait won't be formatted.

Moving the comment to before : (moving that to the next line) has the same effect. Moving the comment to before Trait causes rustfmt to duplicate everything before the {} and then format it

So removing the comments fixed your issue? If so then this might be a duplicate of #2055

Yes, looks like it. That explains why some other comments I wrote had disappeared, too
Do you know if there's been any progress on that? I see there's a pull request that fixes it (and the duplication issue too), but it seems abandoned

Unfortunately I don't think so. I took a look at #5059, and at first glance it doesn't seem like the easiest PR to review. It might be better to try a different approach to solve this issue.

For now I'm going to close this as a duplicate.


Improve diagnostic story for build and reconcile diagnostics

This issue summaries the current diagnostic / problem marker story and outlines implementation changes to improve todays story.
Current Implementation
The current implementation is based on a diagnostic service which manages diagnostic objects generated by different participants (please note that for the discussion I use the API visible type names. Internally the names might be different). A diagnostic literal has the following attributes:
/**
 * Represents a diagnostic, such as a compiler error or warning. Diagnostic objects
 * are only valid in the scope of a file.
 */
export interface Diagnostic {

    /**
     * The range to which this diagnostic applies.
     */
    range: Range;

    /**
     * The human-readable message.
     */
    message: string;

    /**
     * A human-readable string describing the source of this
     * diagnostic, e.g. 'typescript' or 'super lint'.
     */
    source: string;

    /**
     * The severity, default is [error](#DiagnosticSeverity.Error).
     */
    severity: DiagnosticSeverity;

    /**
     * A code or identifier for this diagnostics. Will not be surfaced
     * to the user, but should be used for later processing, e.g. when
     * providing [code actions](#CodeActionContext).
     */
    code: string | number;
}

In addition to these properties a diagnostic object has an owner which uniquely identifies the owner/producer of a diagnostic literal. In VS Code's API the owner can be specified when the creating a diagnostic collection (see: createDiagnosticCollection(name?: string): DiagnosticCollection). If no name is provided VS Code generates a unique name.
Diagnostic objects are created for a given resource, which is identified by its Uri. In the diagnostic service the diagnostic objects are keyed along two dimensions: the 'uri' and the 'owner'. So you can for example delete all diagnostic objects for a given uri (for example when a file gets deleted) or you can delete diagnostic objects for a given owner across all resources (for example when the producer of these diagnostic object want to clear them all).
The model of a producer allows that different extensions can produce diagnostic objects for resources. ESLint is an example, which when installed validates JavaScript files and produces diagnostics for it. In additional VS Code's internal JavaScript language service produces diagnostic objects as well.
This sound pretty good already: so what is the actual problem with that story. The problem shows up when we look at the lifetime of the diagnostic objects and need to decide when they are valid and when they become invalid.
To illustrate the problem consider the following setup for a JavaScript workspace:

a task (provided through VS Code's task system) that runs ESLint over the whole project and validates every JavaScript file and produces diagnostic objects for it. The task piggy bags on a gulp file that does the actual eslint execution. The task must be rerun to produce an updated set of diagnostic objects. Conceptually these are build problems.
an installed ESLint extension (https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) that validates the JavaScript on type. Conceptually these are live/reconciled problems. The content on disk is still different which is especially important for language were the compiler produce output files (e.g. C#, TypeScript).

To keep things easy for now we assume that both ESLint checkers use the same configuration options (e.g. that produce the same set of diagnostics for the same JS file).
The user opens the workspace and does the following:

triggers the build via the task system. Errors are reported on files and the errors are navigatable in an error list.
selects a file and opens it in the editor. The user expects that the problems reported on the file are immediately visible.
the user fixes the problem. User expects that the problem at least disappears from the editor. It is to be discussed what should happen with the error in the error list.
the user saves the file and closes it. The error should disappear from the error list as well.

Actually VS Code behaves like this right now. However for the price of being wrong in the following scenarios:

Same as above
Same as above
Closes the file without fixing the problem and removes it from the working set (which we be automatic with the new tab design).

In these steps the errors disappear from the system although they still exist.
Another case tricky case is when the build system produces a different set of diagnostic objects then a language service. Given the different tool chain used for builds and language services this is not a rare scenario. So we at least need to inform the user about this.
Proposed Implementation Changes
The problem could be addressed by only allowing one provider for diagnostics of a given source. In the above example that would mean that either the build diagnostics need to come from the ESLint extension or that the task system produces the reconciled diagnostics and that that provider ensures consistency on the diagnostics. This sounds not very practical given the fact that there are already a lot of projects out there with a build story based on an open tool chain.
Therefore we propose the following implementation changes:

diagnostic objects carry information whether they got created by a reconciler or a builder.
if present we 'prefer' reconcile diagnostics over build diagnostics per owner/producer. However we will make it clear to the user that there are build errors as well which are currently filtered.
when a file gets closed we remove its reconcile diagnostics (if any exist). The interesting question is what to do with existing build errors for that file. If no reconcile errors for the same owner/producer were reported (even not an empty set) then we fully restore the build errors. If reconcile errors were reported for the same owner/producer we will restore the build errors however we will make it clear that they might be outdated (for example by graying the diagnostic icon)

We also discussed whether we can auto merge build and reconcile errors. However given the asynchronicity of VS Code this would require a lot more infrastructure and API (diagnostic would need to carry a document version, we would need to request diagnostics for a specific version, ...). In addition merging is still questionable if the build tool chain is different than the reconcile tool chain.

@alexandrudima please give it a read.

Closing since this got outdated.


Add new rules to allow collection of region information

Signed-off-by: Joshua Packer<EMAIL_ADDRESS>
These permissions are needed to allow the ClusterClaims controller to read the region from the ClusterDeployment.Spec.Platform..Region  parameter.

/cc @zhiweiyin318 @ldpliu

Bug Reference: https://github.com/open-cluster-management/backlog/issues/16456

/approve
/lgtm


Got "Stack level too deep" errors uploading files after upgrading to 6.15.0

After upgrading from 6.14.0 to 6.15.0, Active Storage file uploads in a Rails <IP_ADDRESS> app (on Ruby 2.7.2) started failing.
The upload code is basically just
invoice.documents.attach(params[:invoice][:documents])

See below for logs (the time stamps will differ because the below was pieced together from separate runs).
We get the impression that New Relic and rack-mini-profiler get into an endless loop, causing the error. Downgrading New Relic fixed it.
2021-01-25T10:22:43.639186+00:00 app[web.1]:
2021-01-25T10:22:43.639348+00:00 app[web.1]: SystemStackError (stack level too deep):
2021-01-25T10:22:43.639371+00:00 app[web.1]:
2021-01-25T10:22:43.639455+00:00 app[web.1]: app/controllers/invoices_controller.rb:32:in `attach_documents'
…
2021-01-25T10:21:53.890829+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/patches/net_patches.rb:9:in `block in request'
2021-01-25T10:21:53.890829+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/mini_profiler/profiling_methods.rb:46:in `step'
2021-01-25T10:21:53.890829+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/patches/net_patches.rb:8:in `request'
2021-01-25T10:21:53.890830+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:52:in `block (2 levels) in request_with_newrelic_trace'
2021-01-25T10:21:53.890830+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/tracer.rb:371:in `capture_segment_error'
2021-01-25T10:21:53.890830+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:51:in `block in request_with_newrelic_trace'
2021-01-25T10:21:53.890831+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent.rb:507:in `disable_all_tracing'
2021-01-25T10:21:53.890840+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:50:in `request_with_newrelic_trace'
2021-01-25T10:21:53.890840+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/patches/net_patches.rb:9:in `block in request'
2021-01-25T10:21:53.890841+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/mini_profiler/profiling_methods.rb:46:in `step'
2021-01-25T10:21:53.890841+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.0/lib/patches/net_patches.rb:8:in `request'
2021-01-25T10:21:53.890841+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:52:in `block (2 levels) in request_with_newrelic_trace'
2021-01-25T10:21:53.890842+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/tracer.rb:371:in `capture_segment_error'
2021-01-25T10:21:53.890842+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:51:in `block in request_with_newrelic_trace'
2021-01-25T10:21:53.890850+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent.rb:507:in `disable_all_tracing'
2021-01-25T10:21:53.890850+00:00 app[worker.1]: /app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/instrumentation/net.rb:50:in `request_with_newrelic_trace'
…

Trying to repro in dev – haven't gotten the actual upload to fail in dev (yet?) but seeing this in the logs:
/home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `initialize_dup': stack level too deep (SystemStackError)
#<Thread:0x000056350780d7d8 /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/threading/agent_thread.rb:12 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        10377: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/threading/agent_thread.rb:14:in `block in create'
        10376: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:723:in `block in start_worker_thread'
        10375: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:696:in `deferred_work!'
        10374: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:677:in `catch_errors'
        10373: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:697:in `block in deferred_work!'
        10372: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent.rb:507:in `disable_all_tracing'
        10371: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:698:in `block (2 levels) in deferred_work!'
        10370: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:943:in `connect'
         ... 10365 levels...
            4: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:831:in `block in initialize'
            3: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:1401:in `port='
            2: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `unencode'
            1: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `dup'

Trying to repro in dev – haven't gotten the actual upload to fail in dev (yet?) but seeing this in the logs:
/home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `initialize_dup': stack level too deep (SystemStackError)
#<Thread:0x000056350780d7d8 /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/threading/agent_thread.rb:12 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        10377: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/threading/agent_thread.rb:14:in `block in create'
        10376: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:723:in `block in start_worker_thread'
        10375: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:696:in `deferred_work!'
        10374: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:677:in `catch_errors'
        10373: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:697:in `block in deferred_work!'
        10372: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent.rb:507:in `disable_all_tracing'
        10371: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:698:in `block (2 levels) in deferred_work!'
        10370: from /home/henrik/.devbox/code/bookie/gems/gems/newrelic_rpm-6.15.0/lib/new_relic/agent/agent.rb:943:in `connect'
         ... 10365 levels...
            4: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:831:in `block in initialize'
            3: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:1401:in `port='
            2: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `unencode'
            1: from /home/henrik/.devbox/code/bookie/gems/gems/addressable-2.7.0/lib/addressable/uri.rb:463:in `dup'

Hello @henrik. Taking a look at this, it appears to be related to the compatibility issues between Module.prepend and monkeypatching. You pointed out that removing that require on rack-mini-profiler fixes the problem, and one of those is prepend_net_http_patch. This is what first caught my attention as being related to the prepend VS monkeypatching situation.
So, before  6.14, our Net::HTTP instrumentation used monkeypatching exclusively.
In 6.14, we introduced another way to instrument Net::HTTP, using Module.prepend. We added a config option prepend_net_instrumentation to control this behavior so users can decide which style of instrumentation to use. Additionally, we also set the default for this option to true, using prepend by default to instrument Net::HTTP.
Using prepend by default caused a number of users to experience errors due to various other gems using monkeypatching. Changing the default behavior of the agent in a way that caused unexpected errors is something we decided should be saved for our next major release instead. So for our 6.15 release, we changed this default to false, so it now uses monkeypatching by default again.
The option to use prepend is still available by adding the following config option to your newrelic.yml
prepend_net_instrumentation: true
I believe adding this should solve this error for you.
Hopefully this helps to explain the differences here in 6.14. Please let me know if you run into any issues or have any questions.

Hello @henrik. Taking a look at this, it appears to be related to the compatibility issues between Module.prepend and monkeypatching. You pointed out that removing that require on rack-mini-profiler fixes the problem, and one of those is prepend_net_http_patch. This is what first caught my attention as being related to the prepend VS monkeypatching situation.
So, before  6.14, our Net::HTTP instrumentation used monkeypatching exclusively.
In 6.14, we introduced another way to instrument Net::HTTP, using Module.prepend. We added a config option prepend_net_instrumentation to control this behavior so users can decide which style of instrumentation to use. Additionally, we also set the default for this option to true, using prepend by default to instrument Net::HTTP.
Using prepend by default caused a number of users to experience errors due to various other gems using monkeypatching. Changing the default behavior of the agent in a way that caused unexpected errors is something we decided should be saved for our next major release instead. So for our 6.15 release, we changed this default to false, so it now uses monkeypatching by default again.
The option to use prepend is still available by adding the following config option to your newrelic.yml
prepend_net_instrumentation: true
I believe adding this should solve this error for you.
Hopefully this helps to explain the differences here in 6.14. Please let me know if you run into any issues or have any questions.

Hello @henrik, Thanks again for filling the issue.  I'm checking in if you have considered the suggestion from @tannalynn to set prepend_net_instrumentation: true.  If you did,  could you share if it resolves the problem that you saw?

Thank you for that thorough response, and apologies for not getting back to you sooner.
We ended up just changing
gem "rack-mini-profiler", require: [ "prepend_net_http_patch", "rack-mini-profiler" ]

to
gem "rack-mini-profiler"

which made this error go away. Haven't noticed any issues since with either lib, so we're happy with that :)
I'll close this issue (assuming you don't mind) but if anyone else runs into it and finds their way here, and can't make the change we did, prepend_net_instrumentation: true seems like a great thing to try.


Added "private": true to package.json

This PR adds "private": true to package.json in all templates like it was discussed in #897

@rosieks,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Thanks @rosieks!


Big number or wasted renders, performance optimisation

Hi guys, I noticed bad performance when rendering 30+ slick carousels on my web.
Using Perf I noticed big amounts of unnecessary/wasted render triggers:

It might be good idea to add couple shouldComponentUpdate methods or use PureComponent where applicable.
Thanks so much for this great library.

Referenced commit solves the problem.


Is there a way to sell or remove items purchased?

The items that add things over time are pretty annoying to use for space age given you need to empty your inventory to fly. Maybe a toggle to disable that effect on all items? I'm going through the code now to make those changes myself. It definitely was awesome pre SA but now it's a minor annoyance.
Or maybe a shift+click to disable those items? Whatever solution you see fit (including none if you want!)

Oof just realized this is part of the items portion of the mod, not yours. My bad!


spotify: icon is broken

Issue description
Installed .desktop file contains absolute path to an icon, which is not available:
Icon=/usr/share/spotify/icons/spotify-linux-128.png

I suggest to change this line to:
Icon=spotify-client

The desktop environment should correctly guess the file extension.
Another, possibly unrelated issue is that I don't see the spotify directory in $XDG_DATA_DIRS variable.

cc @eelco @ftrvxmtrx @sheenobu @mudri

@prusnak, do you feel taking a stab at a PR?

Will be fixed via https://github.com/NixOS/nixpkgs/pull/48208


Add syntactic sugar for top-level merges

So calls can go from
aria.combobox.combobox_target.(aria: { expanded: params[:query].present? })
and become
aria.combobox.combobox_target.aria(expanded: params[:query].present?)
This should work for data too:
aria.combobox.combobox_target.data(action: "turbo-load@document->combobox#reset")
Also should be combinable ala combobox_target.aria(expanded: true).aria(description: "hey").data(action: "yup")
@seanpdoyle what do you think about this? I just used GitHub's online editor but I can flesh this out more later.

with aria and data being predefined

Would defining those methods directly, without incorporating method missing, suffice?
def aria(**attributes)
  merge(**attributes)
end

def data(**attributes)
  merge(**attributes)
end

I like the idea of methods backed by nested keys, but I'm struggling to think up a use case outside of aria- and data- prefixed HTML attributes. Is there an example you have in mind?

@seanpdoyle yeah, this looks perfect. I also can't think of other use cases besides aria and data.
Let me take a swing at updating this.

@seanpdoyle here's my stab at that, I didn't quite know where in the test file to place the tests. I figured since merge is already tested, I just made a combined one to test the chaining and deep-merging. Slightly more integration like.

Thank you!


Add special HVV blob shapes and colours

As per this page, HVV uses some special shapes which you might want to include.
Bus lines are generally displayed as an elongated hexagon, while ferries use a trapezoid.

So it would be nice to replace rounded with something like shape

On the topic of HVV specialties, there is also some colour shenanigans going on.
As you can see at nimmbus.de Fahrplanbuch, some lines do not have solid block background, but rather an outline and characters in one colour, with a contrast filler.

As you can see at nimmbus.de Fahrplanbuch, some lines do not have solid block background, but rather an outline and characters in one colour, with a contrast filler.

I don't know if thats already a bit too specific and a bit overkill. Some edge cases are very difficult (looking at you, Munich's U7/U8), but I think for the first few thought I would define shapes without considering outlines/special colors in texts

Also, HVV RE/RB lines do not seem to have any blob, how would one support transparent background?
Maybe by not stating any colour?

For that, I'd just would not add them to the list as they are "text only"

Yea, sounds like a plan.
shape: pill, hexagon, rectangle, trapezoid, ...
The inverted ones look to be confined to temporary services or on-demand services.

Shapes are now included


extract: semver aware

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

It's related to #6793.

Thanks for the PR @figroc! A few questions for now.

@MikeMcQuaid Would you take another look?

GitHub Actions CI / tests (macOS-latest) (pull_request) Failing after 22m

I can't see the detailed logs. Not sure what happened. The tests ran ok on my macOS.

@figroc I think that was a GitHub Actions bug. If you git rebase you should be able to see now (as there's a conflict anyway).

I've stripped all the trailing if ARGV.debug? from odebug calls. Let me know if that is not appropriate.

Thanks so much for your contribution!  You rock, @figroc!


Fetching update-center.json tends to time out

Recently fetching update-center.json has been very flaky for us. The timeout is currently the default (10 seconds). Bumping this up to 30 seconds seems to solve the issue for us.

Why does merging a PR to my fork close the issue in the parent? Crazy GitHub...

This is fixed via https://github.com/geerlingguy/ansible-role-jenkins/pull/252


Adding project members as not project creator is not working

Setup

Rancher version: 2.6.3
Browser type & version: Firefox

Describe the bug

I cannot add new project member even if I have Manage Project Members role assigned to the user.
I map my users from keycloak oidc, but it doesn't work with local users too.
This doesn't work in the rancher cli tool neither.
To Reproduce

Create project with namespace
add another user (test2) as member
add custom role Manage Project Members for this user (test2)

Result
After logging in as test2 you have access to the project but you cannot add any other members to it.
I guess the Add button should appear or something
Expected Result

User1 should be able to add members to project if he has Manage Project Members role assigned
Screenshots

Project configuration from creator point of view:

Project configuration from member with Manage Project Members role point of view:

the problem here.—>

Couldn't reproduce in 2.7-head (around 2.7.1), possible resolved by https://github.com/rancher/dashboard/pull/5664 / https://github.com/rancher/dashboard/issues/5417 from 2.6.5. Will mark as resolved in the next release for QA to validate

v2.7-9f1e0435bb45e104ba897c5c329e1f23735843d9-head
Provision rancher with version : v2.7-head
Reproducible Steps:

Login as Admin
Create Cluster, project with namespace
Add another user (su-all) as member
Add custom role Manage Project Members for this user (su-all)

Now, Logged in as the user ‘su-all’

Open namespace and project
Check for the ‘Members’ and Add button to add users

Actual:

The user is NOT seeing the Add button to add other users as a Member
The Add button is displaying/enabled once the user is click on ‘Edit Config’ button

This is working as expected and I m closing the card.
Validated below Test cases:

Validated with different users
Validated on different browsers
Validated on different modes (Dark and Auto)

AddUserbutton.webm