Bug in the Equals method of SpreadReference causes slow execution times

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
The equals methods were copied from another place so the object type is incorrect, causing it to always return false.
As a consequence, the OperationCompiler.ResolveFragmentSpread method always not finding the SpreadReference in the context.Spreads, and adding another vaule to this dictionary.
The fix is very simple, just fix the equals methods of SpreadReference to be:
        public bool Equals(SpreadReference other)
        {
            return Path.Equals(other.Path) && Spread.Equals(other.Spread);
        }

        public override bool Equals(object? obj)
        {
            return obj is SpreadReference other && Equals(other);
        }

instead of:
        public bool Equals(SelectionReference other)
        {
            return Path.Equals(other.Path) && Spread.Equals(other.Selection);
        }

        public override bool Equals(object? obj)
        {
            return obj is SelectionReference other && Equals(other);
        }

Notice there that in addition to the changes of the object type, there is the change of: Spread.Equals(other.Spread).
Steps to reproduce
Use a query with fragments on a field that can be of some different sealed types.
Debug the OperationCompiler.ResolveFragmentSpread method, and see it always adds to the context.Spreads dictionary.
If there are a lot of types the first query execution will have a slow compilation time (for every different query).
Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
12.7.0

This issue was fixed with 13.9.8 and 14.0.0


Works on pod v 1.8.3, doesn't work on pod v 1.9.1

Hitting this error while running pod install in v1.9.1
[!] Invalid Podfile file: uninitialized constant Pod::Target::BuildType
Did you mean? Pod::BuildType.

pod ‘FSCalendar’, :build_type => :dynamic_framework

I need to downgrade it to 1.8.3 and it works again.
Putting the instructions here on how to downgrade in case anybody needs it
Check cocoapod version:
gem which cocoapods
sudo gem uninstall cocoapods
sudo gem install cocoapods -v 1.8.3 -n /usr/local/bin
pod deintegrate
pod install

You can also follow my instruction here to fix the problem and use version 1.9.1

Fixed in v0.0.7 via https://github.com/joncardasis/cocoapods-user-defined-build-types/commit/c9077a02f2b79e208b84a1da13a048131f5c92d6. The resolution will work for 1.8.3 and 1.9.1


updated link to Yahoo's open source website

Motivation
The current docs pointed to yahoo.github.io, which we decommissioned a while ago. I propose pointing this to the new webpage at opensource.yahoo.com.
Modifications
I just changed the URL
Verifying this change

[ ] Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
No
Documentation

Does this pull request introduce a new feature? (yes / no)
No

run java8 tests
run integration tests

run Java8 tests

run  Integration Tests

run java8 tests
run integration tests

run java8 tests

Any suggestions for how to update the link? I just want to repoint it to a site with content (opensource.yahoo.com). Thanks.

@gyehuda your change is great. those comments are used for triggering CI tests. currently our ASF jenkins CI is not stable. so we have to re-trigger CI tests. sorry for the confusion.


Values for Currency, gas type and gas energy unit are forgotten

Hi,
With the latest fix it is possible to enter these values again in the integration. But they don't stick and the fields are empty again after page refresh/revisit and after reload of the integration.
Edit: Also the heating dropdoen for Operation shows no values anymore.

I can add, that in an automation that changes the settings of the ch, I cannot set hvac mode anymore.
Under hvac_mode, no options are shown while under preset_mode, the 4 options are still available.
Any likewise experience?

Anyone?

@bsjouke Is this still an open issue?

Hi,
all values under Preset and Operation appear again, and the hvac mode can be selected in automations. So that's fine.
what is mentioned in the title of this issue, is still unresolved:

Ariston currency can be selected but is not saved, thus empty if the device settings page is opened again
Ariston elec cost is greyed out and apparantly replaced by Ariston elec cost 1 just below it
Ariston gas cost is greyed out and apparantly replaced by Ariston gas cost 1 just below it
Ariston gas energy unit can be selected but is not saved, thus empty if the device settings page is opened again
Ariston gas type can be selected but is not saved, thus empty if the device settings page is opened again

You can delete the greyed out entities:

Ariston elec cost is greyed out and apparantly replaced by Ariston elec cost 1 just below it
Ariston gas cost is greyed out and apparantly replaced by Ariston gas cost 1 just below it

The fix is coming for:

Ariston currency can be selected but is not saved, thus empty if the device settings page is opened again
Ariston gas energy unit can be selected but is not saved, thus empty if the device settings page is opened again
Ariston gas type can be selected but is not saved, thus empty if the device settings page is opened again

Thanks!

greyed out entities are deleted and not showing anymore.
I'll let you know the result of the fix once it's there.

I can confirm that this mornings update fixed the currency/gas energy/gas type config setting.


Incompatibility with Leiningen 2.8.1

Issue extracted from here:

@ikitommi: After updating to to lein 2.8.1 ancient fails.

Hi, and sorry for the REALLY BAD description. After updating to lein 2.8.1, ancient failed but the after manually updating the version from 0.6.10 to 0.6.14 the problem got resolved.

This can be closed. And thanks for the awesome plugin!

Good to hear this is resolved! This seems to have been an instance of #80 and the plugin upgrade would have been my next recommendation. :)


Remove unused imports

r? @Mark-Simulacrum
(rust-highfive has picked a reviewer for you, use r? to override)


Unable to install svc-cat/catalog using Helm

Bug Report
What happened:
Following this document, I executed this command but it failed.
$ helm install catalog svc-cat/catalog --namespace catalog
Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

What you expected to happen:
svc-cat/catalog is successfully installed.
How to reproduce it (as minimally and precisely as possible):
See "What happened".
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T23:41:24Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

service-catalog version:
Cloud provider or hardware configuration:
Do you have api aggregation enabled?

Do you see the configmap in kube-system?
Does it have all the necessary fields?

kubectl get cm -n kube-system extension-apiserver-authentication -o yaml and look for requestheader-XXX fields

Install tools:

Did you use helm? What were the helm arguments? Did you --set any extra values?

Are you trying to use ALPHA features? Did you enable them?

Hi @oke-py
the problem is that the last release do not support the K8s in version > 1.16
Here is the pr which was fixing that issue: https://github.com/kubernetes-sigs/service-catalog/pull/2753
I will try to do the release this week to solve such problems.
As a temporary workaround, you can just install Service Catalog from master:
# clone repo
git clone https://github.com/kubernetes-sigs/service-catalog.git

cd service-catalog

# install with sc image build from the latest commit on master
helm install charts/catalog \
    --set image=quay.io/kubernetes-service-catalog/service-catalog:v0.3.0-beta.2-16-g52979db \
    --name=service-catalog \
    --wait

if you want to can also use --set image=quay.io/kubernetes-service-catalog/service-catalog:canary to use latest master.

I got it. Thanks!

When a new release is scheduled please as this problem is blocking ?

Hi @oke-py
the problem is that the last release does not support the K8s in version >= 1.16
Here is the pr which was fixing that issue: #2753
but this is not only available on master. I will try to do the release this week to solve such problems.
As a temporary workaround, you can just install Service Catalog from master:
# clone repo
git clone https://github.com/kubernetes-sigs/service-catalog.git

cd service-catalog

# install with sc image build from the latest commit on master
helm install charts/catalog \
    --set image=quay.io/kubernetes-service-catalog/service-catalog:v0.3.0-beta.2-16-g52979db \
    --name=service-catalog \
    --wait

if you want to can also use --set image=quay.io/kubernetes-service-catalog/service-catalog:canary to use latest master.

I tried to install the release using the above suggestion and helm install failed. Any idea what's went wrong?

Hi @rajshkr
could you share the error message?
maybe it was because of today's quay.io outage 😞

Check https://status.quay.io/ for more info

Hi @rajshkr
could you share the error message?
maybe it was because of today's quay.io outage 😞

Check https://status.quay.io/ for more info

Yes.  I tried now and it is working now. Have deployed service catlog and minibroker as well.  I am now seeing a different issue when creating a service instance
kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/master/contrib/examples/walkthrough/mini-instance.yaml
svcat describe instance -n test-ns mini-instance
Name:        mini-instance
Namespace:   test-ns
Status:      OrphanMitigation - Provision call failed: service instance "7ed9d8f1-e024-4747-be77-4bfeb825ff9d" failed to provision @ 2020-05-20 04:04:37 +0000 UTC
Class:       mariadb
Plan:        10-1-26
Parameters:
param-1: value-1
param-2: value-2
Bindings:
No bindings defined
Another observation
svcat describe plan 10-1-26 --scope cluster
Error: unable to list cluster-scoped plans (field label not supported: spec.externalName)

Hi @rajshkr
which svcat version are you using? It looks like an old one.
Btw. Today we released the 0.3.0 Service Catalog version which supports the k8s 1.18.
I also tested that flow with the k8s 1.18 using kind (kind create cluster --image="kindest/node:v1.18.2") and I spot one issue.
Currently when you are executing:
kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/master/contrib/examples/walkthrough/mini-instance.yaml

you are creating mariadb with old version which does not support k8s 1.18.  Here is pr to fix that bug: https://github.com/kubernetes-sigs/service-catalog/pull/2812
Currently, you can just execute:
kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/92a74067df77e5112107a39dacd3a839d342a1db/contrib/examples/walkthrough/mini-instance.yaml

Hi @cmoulliard
ICYMI: The new release is available, here you can find more info :) https://kubernetes.slack.com/archives/C232SF3TK/p1590424684027100

It works!
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.6", GitCommit:"d32e40e20d167e103faf894261614c5b45c44198", GitTreeState:"clean", BuildDate:"2020-05-20T13:16:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-30T20:19:45Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl create ns catalog
namespace/catalog created

$ helm install catalog svc-cat/catalog --namespace catalog
NAME: catalog
LAST DEPLOYED: Tue May 26 14:27:03 2020
NAMESPACE: catalog
STATUS: deployed
REVISION: 1
TEST SUITE: None

I did a test successfully

Hi @rajshkr
which svcat version are you using? It looks like an old one.
Btw. Today we released the 0.3.0 Service Catalog version which supports the k8s 1.18.
I also tested that flow with the k8s 1.18 using kind (kind create cluster --image="kindest/node:v1.18.2") and I spot one issue.
Currently when you are executing:
kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/master/contrib/examples/walkthrough/mini-instance.yaml

you are creating mariadb with old version which does not support k8s 1.18. Here is pr to fix that bug: #2812
As a workaround use that command (after merging my pr this workaroud will be not needed):
kubectl create -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/92a74067df77e5112107a39dacd3a839d342a1db/contrib/examples/walkthrough/mini-instance.yaml

Please ping me on k8s slack (nick: mszostok) if you will have any other prroblems

I upgraded to 0.3.0 of svc and used the supported version of mariaDB. It worked as a charm!!


Update Depreciated Pillow Methods

Using latest pillow antialias method Resampling.LANCZOS
Using latest pillow getsize method getlength

I've implemented this if you think it will suffice, since getsize was depreciated in 9.2
                if PIL.__version__ >= "9.2.0":
                    width = font.getlength(content)
                else:
                    width, _ = font.getsize(content)

making all the necessary adjustments and reopening this


Set flag when fit hasn't converged

Currently there is only a warning printed by proxmin when the fit hasn't converged. It would be useful to set an internal flag in such cases.

This is a good idea. Doing it properly requires an update to proxmin, which currently doesn't inform if the optimizer has converged. That's an omission that we will remedy. Once that's in place, it'll be simple to report that flag.

I don't think that proxmin needs an update, if the number of iterations is equal to max_iter then the solution didn't converge. That's the only check that proxmin currently does. While we could put a flag in proxmin to check for this I don't think there is a reason to. It's very rare that it would converge on exactly the last iteration.

That's the simple solution, yes. However, proxmin knows the current errors for every component, which might be useful to return. This would be much lighter than the full traceback and provide decent diagnostics. I prefer that solution, which would also allow to make the convergence test.

I fixed this with a proxmin update, which is thus required (v0.5.2)


/feedbacker2/caching: page shows data in half of the screen

/feedbacker2/caching: page shows data in half of the screen

done


chore(deps): versions

keeping in draft, will merge next v8 release

i think SDK v0.50.5 was tagged wrong or something. Getting this same issue with the ibc-rate-limit repo I am upgrading.

v0.50.6 SDK in a few weeks will get the patch in to fix


Error on master.yaml?

I'm not sure, but why this has a '-' ?
https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/master.yaml#L124
UPDATE:
It fails when one enable this. But this is needed for a restart?

In system, prepending a command with - means it can error and not break the execution. In this case, if a container named kubelet doesnt exist, Docker will return an error code !=0 but the unit execution continues. Without the -, if the container doesn't exist, the unit execution is cancelled.


Add a new value $nil

Since json documents can contain null values, elvish ought to have a corresponding value so that from-json and to-json won't lose information. Currently, from-json converts null to an empty string, while to-json represents an empty string as an empty string.
I suggest naming the special value $nil, though $null is another possibility. It should probably be falsy. And is and eq should be able to detect whether something is $nil as opposed to $false.

Yeah, let's do that. It can also serve as a good initial value for variables when Elvish starts requiring explicit declaration of variables.

Fixed in f6bdd0e079dfe79185ee2642e6995e404972191e.


Lower analyseMaxAge limit for Local Market Analysis

With the loan rates fluctuating a lot recently I've found myself loving the bot - until about a month ago I was using a 2 year old version and I was delighted to find that it had been expanded with many features I'd have loved and not known how to do myself as a very amateur coder.
I played with Local Market Analysis (LMA) a little bit but ended up turning it off because I found that the volatile rates meant that it was leaving coins un-loaned for much longer than I would like when rates had spiked for a day.
However, I do still see rates spike downwards temporarily, then my loans get swooped at a low rate when they come back up.
I've set my analyseMaxAge to "1" and lendingStyle to "10" but I would like to be more aggressive over a shorter time period to catch spikes but adjust quickly if things are really dropping. Would this be possible?

I suggest you check out the macd branch.

Yip, please do check out the macd branch @Wegerich , ping me if you have any trouble getting it working.
You should notice much better lending rates and percentage lent out.

How do I access that? Can you post a link please? I'm not well versed with github.
Thank you @laxdog

Yea, it's on page on my fork. I started it before I was a member of this organisation.


chore: upgrade charts

updated chart jx3/jx-pipelines-visualizer from 1.1.5 to 1.1.6

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign hferentschik
You can assign the PR to them by writing /assign @hferentschik in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test gsm

vault
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test gsm

vault
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test vault

tls
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test tls

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test gsm

tls
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test tls

vault
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test vault

tls
d36f16fb9cafbdd25977861b640b22a69198bab2
link
/test tls

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest


No filename track info shown

Just had the same tracks in museeks and it detected filenames fine, ICHM detected none.

I have no plans for filenames to be processed in any way. Keep your tags clean or use another audio player, iCHM is not designed for this use case, sorry.


Fix doctest in README.

Fix the doctest in the README.md

Motivation
Tests should pass, not fail.

Current dependencies on/for this PR:

main

PR #1   👈

This comment was auto-generated by Graphite.


Support the following functions

Internationalization support
Standard terms, dictionary definition, mapping
Column-Level Lineage   SQL Parsing
Asset analysis

@caiyt2001 Thanks for raising the issue. It would be great if you can add more details such as what you mean by "Asset Analysis"

@caiyt2001 I have created an issue to track support for internationalization via #5496

Internationalization support
Tracked in #5496
Standard terms, dictionary definition, mapping
Glossaries and Tags have been added for this purpose
Column-Level Lineage   SQL Parsing
Column-level lineage is now supported
Asset analysis
Not clear what this is. @caiyt2001 you can open a new issue with details.


When do you plan to release pre-trained models?

I also request pre trained models, thank you!

+1


Dark mode is incomplete

Very minor: The theme advertises a dark mode, but it's incomplete?

Currently, I've overriden the black theme with the existing light theme because I believe we need some design work to figure out the dark theme properly considering accessibility and usability. I will leave this issue open but won't address it just now.


forge build with extra output files doesn't re-run for cached files

Component
Forge
Have you ensured that all of these are up to date?

[x] Foundry
[x] Foundryup

What version of Foundry are you on?
forge 0.2.0 (059aa45 2023-11-07T08:20:43.711020000Z)
What command(s) is the bug in?
forge build
Operating System
macOS (Apple Silicon)
Describe the bug
I ran forge build on a project and then later ran forge build --extra-output-files abi but no .abi.json files were generated.
I was able to workaround this by forge clean then forge build --extra-output-files abi.

I see, I think the issue here is that we don't invoke the ArtifactOutput handler if the artifacts are unchanged @Evalir
https://github.com/foundry-rs/compilers/blob/f00eef81a91a393bf92eb13d47a5221f5e50162f/src/artifact_output/configurable.rs#L235
which is only invoked when we write (new) artifacts
https://github.com/foundry-rs/compilers/blob/f00eef81a91a393bf92eb13d47a5221f5e50162f/src/compile/project.rs#L330-L336
I think we need some check here that applies the extra output files to the unchanged contracts

I am also seeing another potential issue that I am wondering if is related.
We have an interface IWorld that extends another interface IMoveSystem. If we update IMoveSystem and run forge build (on a warm cache with foundry.toml configured to output ABI files), then the IMoveSystem.abi.json is updated but not IWorld.abi.json.

@holic yes, it should fix this as well