tests: update deployment.yaml for C++ tests

Please provide a description of this PR:
This PR updates the integration to prepare for tests with gRPC C++

Changed the flag format because C++'s flag parsing library only supports --a=b.
Added a new environment variable TEST_ECHO_IMAGE for echo image, so it can be changed to point to the C++ image

Changed readiness probe to use TCP instead of HTTP when echo image is set because C++ doesn't have an easy way to start an HTTP server

Hi @menghanl. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

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 kubernetes/test-infra repository.

/ok-to-test

@menghanl: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
458f363959ad320688122b180b1ba314ef79b945
link
true
/test unit-tests_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
458f363959ad320688122b180b1ba314ef79b945
link
true
/test unit-tests_istio

integ-distroless_istio
458f363959ad320688122b180b1ba314ef79b945
link
true
/test integ-distroless_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
458f363959ad320688122b180b1ba314ef79b945
link
true
/test integ-distroless_istio

unit-tests_istio
40f6ad1a096663bb7f483b7bd58b58332c32b7e4
link
true
/test unit-tests_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
40f6ad1a096663bb7f483b7bd58b58332c32b7e4
link
true
/test unit-tests_istio

integ-distroless_istio
40f6ad1a096663bb7f483b7bd58b58332c32b7e4
link
true
/test integ-distroless_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

integ-pilot-istiodremote_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

integ-pilot-istiodremote_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote_istio

integ-pilot-istiodremote-mc_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote-mc_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

integ-pilot-istiodremote_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote_istio

integ-pilot-istiodremote-mc_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote-mc_istio

integ-cni_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-cni_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

integ-pilot-istiodremote_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote_istio

integ-pilot-istiodremote-mc_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote-mc_istio

integ-cni_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-cni_istio

integ-pilot-multicluster_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-multicluster_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@menghanl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-distroless_istio

integ-pilot-istiodremote_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote_istio

integ-pilot-istiodremote-mc_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-istiodremote-mc_istio

integ-cni_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-cni_istio

integ-pilot-multicluster_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot-multicluster_istio

integ-pilot_istio
b46758aaebdefbf9c79df2a42bc18a455847723e
link
true
/test integ-pilot_istio

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 kubernetes/test-infra repository. I understand the commands that are listed here.


Fix/empty address detection

Try out this version of the Hiro Wallet - download extension builds.

This PR changes the logic slightly to go 1 by 1 when looking for empty address space.
Future improves would include adding a persistent highest known index.

Nice improvement :)


X509_dup() should better copy the cached (non-ASN.1) data

This is a follow-up on https://github.com/openssl/openssl/pull/23043:
@vdukhovni: (https://github.com/openssl/openssl/pull/23043#discussion_r1457745827)
I see this was already merged, but I am curious why it is that absence of lazily-computed data causes observable behaviour differences. If that's the case, perhaps the real issue is not in documentation, but API semantics.
When the computed data is missing, the relevant thread should lock the object and recompute the missing data. Or else, the data should automatically be computed as part of X509_dup().
Why should users need to know about these sort of rather subtle behaviour differences?
@DDvO: (https://github.com/openssl/openssl/pull/23043#discussion_r1457787283)
Indeed to me it was a pretty intricate API pitfall that X509_dup() does not copy everything.
https://github.com/siemens/libsecutils/pull/57 contains details on where it showed up.
@vdukhovni: (https://github.com/openssl/openssl/pull/23043#discussion_r1457817390)
Perhaps we should ensure that X509_dup() and/or CRL_dup() always compute the auxiliary cached information, so it is always pre-computed as part of decoding a certificate, this is perhaps something that should happen at the d2i layer. And then dup can just be i2d, followed by d2i or equivalent.
I am not fond of having to document warts...

I fear that the doc change done in  #23043 was still needed at least for the older OpenSSL versions
(where we presumably won't touch the semantics of X509_dup()).

Yeah, we need to be careful here in terms of backwards compatibility. I would call this a feature and thus #23043 was necessary anyway.


Remove gov v1beta1 router from simapp

Description
Don't Review R4R Only For E2Es

closes: #4671
I ran the v8 upgrade locally, and everything passed. I will run the upgrade test on the PR once the image is built.

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

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #4714 (9ff989d) into main (3db1681) will increase coverage by 0.07%.
Report is 8 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4714      +/-   ##
==========================================
+ Coverage   79.65%   79.73%   +0.07%
==========================================
  Files         187      187
  Lines       13195    13195
==========================================
+ Hits        10511    10521      +10
+ Misses       2253     2246       -7
+ Partials      431      428       -3

Files Changed
Coverage Δ

modules/apps/27-interchain-accounts/types/keys.go
100.00% <ø> (ø)

...27-interchain-accounts/controller/keeper/keeper.go
90.74% <100.00%> (+0.11%)
:arrow_up:

.../apps/27-interchain-accounts/host/keeper/keeper.go
87.12% <100.00%> (+1.73%)
:arrow_up:

modules/apps/27-interchain-accounts/module.go
49.50% <100.00%> (+0.50%)
:arrow_up:

modules/apps/transfer/keeper/keeper.go
93.28% <100.00%> (+1.45%)
:arrow_up:

modules/core/keeper/keeper.go
92.00% <100.00%> (+0.33%)
:arrow_up:

... and 1 file with indirect coverage changes

ref: https://github.com/cosmos/ibc-go/issues/4671#issuecomment-1729330581


ARROW-6580: [Java] Support comparison for unsigned integers

In this issue, we support the comparison of unsigned integer vectors, including UInt1Vector, UInt2Vector, UInt4Vector, and UInt8Vector.
With support for comparison for these vectors, the sort for them is also supported automatically.

@emkornfield @pravindra any thoughts on this?

Codecov Report

Merging #5405 into master will increase coverage by 1.25%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5405      +/-   ##
==========================================
+ Coverage   88.53%   89.78%   +1.25%
==========================================
  Files         849      732     -117
  Lines      119744   112059    -7685
==========================================
- Hits       106020   100617    -5403
+ Misses      13370    11442    -1928
+ Partials      354        0     -354

Impacted Files
Coverage Δ

cpp/src/arrow/util/compression_bz2.cc
0% <0%> (-57.36%)
:arrow_down:

cpp/src/arrow/util/compression_bz2.h
0% <0%> (-50%)
:arrow_down:

cpp/src/arrow/dataset/file_parquet.h
50% <0%> (-37.5%)
:arrow_down:

cpp/src/arrow/util/compression_zstd.cc
79.43% <0%> (-13.09%)
:arrow_down:

cpp/src/arrow/python/flight.cc
88.81% <0%> (-8.08%)
:arrow_down:

cpp/src/arrow/util/io_util.cc
71.66% <0%> (-4.81%)
:arrow_down:

cpp/src/arrow/dataset/file_parquet.cc
95.58% <0%> (-4.42%)
:arrow_down:

cpp/src/arrow/filesystem/s3_internal.h
90.74% <0%> (-3.71%)
:arrow_down:

cpp/src/arrow/dataset/test_util.h
91.02% <0%> (-3.66%)
:arrow_down:

python/pyarrow/tests/test_table.py
96.5% <0%> (-3.12%)
:arrow_down:

... and 328 more

Continue to review full report at Codecov.

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


Throttle pending job starts in scheduler

The scheduler should throttle job creation on a per-host basis to prevent thundering herd issues. New jobs should only be submitted to a host when there are less than N currently starting.

We already throttle jobs at the flynn-host level. This should be done through a one-by-one deployer.


can you add a feature to scrap the indicator or strategy script?

instead of scraping the metadata of the indicator can we scrap the pine script in the open sourced ones?

I don't understand what you mean! Is it a question or a suggestion?

please describe it more.

i mean scrapping the public scripts

i mean scrapping the public scripts

I am not expert at tradingview tools. please send an example link to check if it is possible.


DevOps Module: Add body in the task callback API

Add the possibility of returning the actual task status and additional information in the callback call to ODM. Currently, it's only possible to STOP the task without the ability to declare the status (it's assumed it has been completed successfully).
Below is a proposed structure for the body to be added to the callback call:
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Callback API",
  "type": "object",
  "properties": {
    "errors": {
      "type": ["string", "null"]
    },
    "results": {
      "type": ["object", "null"],
      "properties": {},
      "required": []
    },
    "status": {
      "type": "string",
      "enum": ["PROCESSED", "FAILED"]
    }
  },
  "required": [
    "status"
  ]
}

The "results" attribute can be used to return additional information generated by the task to ODM, such as pipeId, name, outputs generated by processes, and so on.
Let me know what you think.
Thanks,
Giandomenico

First draft (with "results" as String) pushed on branch 102-devops-module-add-body-in-the-task-callback-api


Fix/release

attempting to fix the build and release process

Expected release notes (by @Shesekino)
fixes:
hopefully fixing the build process (be6edfd)
trigger release (094ff7f)
others (will not be included in Semantic-Release notes):
4e5b725 dsad

Expected release notes (by @Shesekino)
fixes:
trigger release (f321cb6)

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


initialize must be called before partial_fit calls

This can be trouble with cloning.
Example, with a pytest.raises to show where the error occurs:
import skorch
from skorch import NeuralNetClassifier
from torchvision.models import resnet18
from sklearn.base import clone
from sklearn.datasets import make_classification
import torch.nn as nn
import torch
import pytest

class Simple(nn.Module):
    def __init__(self, d=10):
        super().__init__()
        self.layer = nn.Sequential(nn.Linear(d, 2))

    def forward(self, x):
        return self.layer(x)

d = 20
X, y = make_classification(n_features=d, n_classes=2)
X = X.astype("float32")

m = Simple(d=d)
m1 = NeuralNetClassifier(m, batch_size=256, optimizer=torch.optim.Adam)
m1.partial_fit(X, y)
assert m1.initialized_

m2 = clone(m1)
m2.set_params(optimizer=torch.optim.SGD, optimizer__momentum=0.1)
assert m2.initialized_
with pytest.raises(AttributeError):
    m2.partial_fit(X, y)
m2.initialize()
m2.partial_fit(X, y)

I ran into this in https://github.com/mrocklin/dask-ml/pull/2, but had a hard time remembering exactly why I needed it when creating this example. Hopefully this uncovers the issue.

Thank you for bringing this to our attention.
I replicated your example but found that the line m2.set_params(optimizer=torch.optim.SGD, optimizer__momentum=0.1) was unnecessary to trigger the error. Is there a particular reason why you added that line?
Regarding the problem, it seems that the callbacks are uninitialized after cloning. When I empty the callbacks_ attribute, the fit works. Why that happens I haven't figured out yet. Possibly, this requires a deeper look at clone (using deepcopy works, for instance). I will dig deeper when I have more time.
Regarding the solution, just calling initialize() on each partial_fit is not possible. initialize() resets the module, which is exactly what we don't want when we call partial_fit. We maybe could call initialize_callbacks() only, but this will probably also not work because some callbacks may rely on keeping their states between partial_fits.
PS: Our partial_fit differs semantically from sklearn's partial_fit, which always runs but one epoch. In skorch, partial_fit is the same as fit except that the network is not re-initialized. This difference was not by design but since it's very practical and for backwards compatibility reasons, we might keep it that way.

@stsievert Could you please explain what your use case and expectation is? As far as I can tell, sklearn usually resets the estimator after clone. With skorch NeuralNet this is not the case but that usually doesn't matter because a subsequent fit call will reset the estimator by calling initialize. Therefore, NeuralNet works with grid search et al. as expected.
When you clone NeuralNet, its callbacks are initialized anew, like any sklearn estimator. Thus, when you call partial_fit which circumvents initialize, the callbacks are not "ready" and the error is raised. As said earlier, we could initialize the callbacks but depending on the use case, this may not be desired, hence my question.

I'm closing this issue; all signs point to the issue I thought not being an issue (which is different than the issue I showed in the first post). In my actual application, removing the initialize call after clone appears to work.
Here's my actual use case:
import skorch
from skorch import NeuralNetClassifier, NeuralNetRegressor
from torchvision.models import resnet18
from sklearn.base import clone
from sklearn.datasets import make_classification
import torch.nn as nn
import torch
import pytest

class Simple(nn.Module):

    def __init__(self, d=10):
        super().__init__()
        self.layer = nn.Sequential(nn.Linear(d, 1))

    def forward(self, x):
        return self.layer(x)

class Net(NeuralNetRegressor):
    steps = 0

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # Raises TypeError if other parameters set in __init__
        # (which is why `steps` is outside __init__)
        #  self.steps = 0

    def partial_fit(self, *args, **kwargs):
        self.steps += 1
        print("calling pf with steps =", self.steps)
        super().partial_fit(*args, **kwargs)

    def score(self, X, y):
        X = skorch.utils.to_tensor(X, device=self.device)
        y = skorch.utils.to_tensor(y, device=self.device)

        y_hat = self.predict(X)
        y_hat = skorch.utils.to_tensor(y_hat, device=self.device)
        loss = super().get_loss(y_hat, y, X=None, training=False).item()
        print(f"steps = {self.steps}, loss = {loss}")
        return -1 * loss

d = 20
X, y = make_classification(n_features=d, n_classes=2)
X = X.astype("float32")
y = y.astype("float32").reshape(-1, 1)

model = Simple(d=d)

m1 = Net(model, criterion=torch.nn.MSELoss, optimizer=torch.optim.Adam)

m2 = clone(m1).set_params(optimizer=torch.optim.SGD)
assert isinstance(m2.optimizer_, torch.optim.SGD)
m2.partial_fit(X, y)
m2.score(X, y)

m3 = clone(m1).set_params(optimizer=torch.optim.RMSprop)
assert isinstance(m3.optimizer_, torch.optim.RMSprop)
m3.partial_fit(X, y)
m3.score(X, y)


Removes Typography per Jackie's request

Notion card link(s)

React: Add privacy policy link in footer;

Description (Proposed changes, additional context, chosen approach/alternative approaches, gotchas, etc)

Jackie just asked for minor tweaks - see comments in notion card.

Steps for reviewer(s) to reproduce/test

Just take a look at the footer for Boston (no privacy policy) & Normative (has privacy policy dummy link to Normative's website).

Seems like mostly content changes so no feedback
Although I like that the periods are no longer in the links 😍


Feature/update accessibility collector doc

Accessibility Collector wiki update (issue #419).
Description
I added version of the AccessSniff used and removed "beta" information since the collector now uses stable sniffer.

I hereby agree to the terms of the AET Contributor License Agreement.

For the future - it is best to update docs together with changes in the code, so #430 is a good place to contribute wiki pages update.


Backend and UI for login / Signup page and the profile page where the login user data will show and responsiveness of the website

Description :-
🔲 Backend for Login/Signup Page:
Implement the server-side logic for user authentication.
Create APIs for user registration and login.
Ensure secure password storage and authentication.
🔲 UI for Login/Signup Page:
Design a user-friendly and visually appealing login/signup form.
Include input fields for email/username and password.
Add validation checks for input data.
Implement error handling for incorrect login/signup attempts.
🔲 Profile Page:
Develop a profile page where users can view their data.
Retrieve user-specific information from the database.
Display user details such as name, email, profile picture, etc.
🔲 User Data Display:
Dynamically populate the profile page with user data.
Ensure only authorized users can access their own profiles.
Allow users to edit and update their profile information if necessary.

🔴 Please assign this issue to me.
I bring 1.5+ years of expertise as a MERN Stack developer to the table. 🚀 I am committed to implementing all the features outlined in this issue. My goal is to transform the website with captivating animations and ensure it's fully responsive across all devices. 🎨💻
I'm excited to contribute to this open-source project and am ready to take on the responsibility of hosting the backend and database. This move will enhance our project's performance by seamlessly integrating backend connectivity.
I look forward to getting started and making a meaningful impact on this project. 🌟 Thank you for the opportunity to collaborate and contribute to its success. 🤝

I thought about it. but where we can store it?

we will store it in cloud.mongodb it is free cloud space provide by Mongodb AWS cloud service you can give all responsibility for safe and secure backend to me I will make this project into best dynamic project. Please assign to me make a trust to me.

Wouldn't it be better to create another folder within this same project just for the back-end? so people only open Pull requests or issues on the back-end or front-end ?

Already I am pushing /PR the backend part in another branch only.

@Vijaykv5  please assign i already started work on the feature/issue.

Already I am pushing /PR the backend part in another branch only.

You meant new branch and new folder right just like @juninhokaponne  mentioned

@harshalhonde21 Are you still working on it?

@Vijaykv5 if there is no response from his part can you assign this feature to me i think we could leverage netlify serverless functions for this feature


Introduction: schema vs. data

"Understanding OCSF" discusses personas at a high level, but in order to be "agnostic to storage format, data collection and ETL processes", an additional level of communication detail is required.  Being agnostic requires defining what information is collected, stored and transformed without regard to the data formats used to represent that information.
Current:

The author persona is who creates or extends the schema.
The producer persona is who generates events natively into the schema.
The mapper persona is who translates or creates events from another source to the schema.
The analyst persona is the end user who searches the data, writes rules or analytics against the schema, or creates reports from the schema.

The author works directly with the schema as described.  But producers, mappers and analysts work with data that corresponds to (can be validated by) the schema.
Proposed:

The producer persona is who generates event data that is defined by (is valid according to) the schema.
The mapper persona is who translates events from another source into data defined by the schema.
The analyst persona is the end user who searches, writes rules or analytics for, or creates reports from data defined by the schema.

A communication diagram would show personas exchanging documents or messages, or in NIEM terminology, "Information Exchange Packages (IEPs) are the actual messages that carry data and are exchanged between stakeholders."  The schema itself is not a persona or communication endpoint, it is used by them when validating data or writing analytics.

Welcome improvements - I'll update and repost.  However I think someone had a suggestion to convert to a .md format and then it would be easier to keep things up today, via PRs etc.


mbedtls2 support

polarssl-1.* is known as mbedtls-2.* now. Could you please fix the build against mbedtls2?
Here is dirty hack that builds umurmur against mbedtls:
https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/umurmur
(see mbedtls2.patch)

i just merged #71. Could you verify if that does the job?

looks fixed, thank you


Installation documentation improvements

After reading through the documentation and most of the code, it's still not obvious to me how to create the DynamoDB table for storing my Helm values 🙁 . It looks like the load subcommand is what I should be using to create the table, but this accepts "a json file of releases", and I'm not quite sure how to generate that from Helm.
There's some chance I'm just being dense, but it would be nice to have some more specific information in the README with regard to how to get this working from scratch.
Thanks!

Hi David


vm: fix indentation

An issue from https://github.com/ethereum/pyethereum/pull/813
Traceback (most recent call last):
  File "run_statetest.py", line 13, in <module>
    from ethereum.messages import apply_transaction
  File "/usr/lib/python3.6/site-packages/ethereum-2.1.0-py3.6.egg/ethereum/messages.py", line 19, in <module>
    from ethereum import vm
  File "/usr/lib/python3.6/site-packages/ethereum-2.1.0-py3.6.egg/ethereum/vm.py", line 238
    if sys.version_info.major == 2:
                                  ^
TabError: inconsistent use of tabs and spaces in indentation

Checks passing, I'll merge this since the current head does not pass even basic test. Alternative is to revert https://github.com/ethereum/pyethereum/commit/ff838b50d55d4d31948adc926ed6eb264bf9fe97


CIV-11541 Bilingual check for notifications

Before creating a pull request make sure that:

[x] commit messages are meaningful and follow good commit message guidelines
[x] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-11541
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Do we definitely want to skip the Notify RPA steps as well?


Error in step 3.2 - Add OData V2 Support

Hello Experts,
I'm getting error in step 3.2 - Add OData V2 Support.
Created the server.js file /srv folder and did npm start.
After this command I'm getting error which I have attached.
Kindly help in resolving the issue.
Regards,
Vinod Iyer
error_log_3.2.txt

Hello Experts,
Error got resolved now.
Closed the workspace and opened again.
Closed all the terminal windows and opened new one and executed the command. Worked fine.
Regards,
Vinod Iyer

Glad to hear that its working for you now.


Using NullLogger types from Logging.Abstractions

aspnet/Logging#571
@Eilon

Travis/AppVeyor failing here?

Because of the conflicting types. It'll pass on the CI

Ah got it!


这是否是一个 Bug？

[X] 我已经确认我要报告的是一个 Bug

这个问题是否已经存在？

[X] 我已经确认这个 Issue 没有被报告过

Alova 版本
3.0.0-beta.3
前端框架
React
问题描述
报以下错误：
ERROR in<EMAIL_ADDRESS>1:0-41
Module not found: Error: Can't resolve './function' in 'E:\艺施胡\my-app-react\node_modules\@alova\shared\dist'
Did you mean 'function.js'?
BREAKING CHANGE: The request './function' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where
the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in<EMAIL_ADDRESS>1:0-80
Module not found: Error: Can't resolve './model/FrameworkState' in 'E:\艺施胡\my-app-react\node_modules\@alova\shared\dist'
Did you mean 'FrameworkState.js'?
BREAKING CHANGE: The request './model/FrameworkState' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where
the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in<EMAIL_ADDRESS>2:0-225
Module not found: Error: Can't resolve './vars' in 'E:\艺施胡\my-app-react\node_modules\@alova\shared\dist'
Did you mean 'vars.js'?
BREAKING CHANGE: The request './vars' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where
the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

期望的表现
No response
复现链接
No response
复现步骤

npm install alova@beta
编写alova请求代码
通过react-scripts start启动项目即报错

系统信息
No response
补充说明
No response

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

fixed in<EMAIL_ADDRESS>


Jest is not a function error

In our Next js project, we use your package so that the selectors respond when there is a change. But our tests give the following error. How can we solve this?
TypeError: (0 , _proxyMemoize.default) is not a function
Packages details:
"next": "^13.0.2"
"redux": "^4.2.0"
"react-redux": "^8.0.2"
"next-redux-wrapper": "^8.0.0"
"reselect": "^4.1.6"
"proxy-memoize": "^1.2.0"

Seems #42 is related.

I don't understand how to fix the problem

It's not solved, unfortunately. A workaround is to add "^proxy-memoize$": "<rootDir>/node_modules/proxy-memoize/dist/wrapper.cjs" in jest moduleNameWrapper.
Please continue discussion in #42.


Implementing graph convolutional neural networks

Given the recent popularity of graph convolutional neural networks (i.e. https://github.com/tkipf/gcn), would it be worth implementing a swift paradigmatic version? I have a semi-working version, but would defer to those more knowledgable in these things.

That would be a great addition. It's something that I know a few people were exploring, but we don't have any formal examples in the repository yet.
The integration of graphs and tensor operations is somewhere that we believe Swift can really shine, so anything you'd be willing to contribute would be very much appreciated.


Wrong handling of sophisticated CRON schedule

Expected Behavior
We have a new workflow that should be effectively disabled during PROD deployment until the development is fully completed. To achieve that, we specify a CRON schedule 0 0 29 2 1. The idea is:
The next execution date for this crontab entry would be February 29th of the next leap year which falls on a Monday. According to the calendar, that should happen in the year 2032 so we have plenty of time to complete the development.
Actual Behavior
In fact, for some reason Temporal CRON schedules that differently

I've tried checking the sleep period manually and it does not correspond to the CRON specified. Is there some integer overflow?
> date -d 'now + 6604 hours 52 minutes 13 seconds'
Mon 05 Feb 2024 02:13:18 AM EET

Steps to Reproduce the Problem

specify a CRON schedule 0 0 29 2 1
schedule some workflow
take a look at expected date

Specifications

Version: v1.9.0 web
Platform: Linux

Thank you for reporting this issue.
It seems that there might be a problem with the Temporal Cron Schedule parsing logic, as the expected execution date is not what the CLI is showing.
I recommend you to use the temporal schedule create command with  --calendar, --interval, or --cron options to set the desired schedule.  This allows you to create a schedule that will execute on the desired date.
If you are still encountering the issue, please provide the following information:

The exact version of the Temporal CLI that you are using.
The output of the temporal schedule describe command for the schedule in question.
Any other relevant logs or debugging information.

This information will help us to diagnose the problem and provide you with a more specific solution.

Thank you for reporting this issue.
The issue appears to be related to the way Temporal CRON schedules are handled. We are aware of this issue.
Based on the documentation, Temporal does not use the traditional CRON implementation, instead it uses a more reliable and robust approach.
Temporal does not guarantee that the CRON implementation will be compatible with other CRON implementations.
You may want to consider using the Schedule API instead of CRON, which provides a more robust and feature-rich scheduling mechanism.
More information can be found here: https://docs.temporal.io/workflows#schedule
You may also want to take a look at the Temporal CRON implementation: https://github.com/temporalio/temporal/blob/master/common/service/history/events/event_converter.go

Thank you for reporting this issue!
I can see you're observing an issue with Temporal's CRON schedule implementation where the computed next execution time doesn't align with your expectations, particularly for leap years. It seems like the computed next execution time is not considering the leap year properly.
The date command you used to manually calculate the next execution time appears to be correct, but the Temporal server's CRON implementation is different. You've also tried to debug the issue by manually computing the next execution time and comparing it with the one Temporal calculates, and the discrepancy is quite significant.
To investigate the discrepancy, I'd need some additional information:

Please share your Temporal server version. You mentioned "v1.9.0 web," but I need the exact version.
Could you provide more context about your workflow and the specific CRON schedule you're using? This would help understand the full picture and potentially narrow down the cause.
Are you using the Temporal server directly or a hosted Temporal Cloud environment? This will help me provide more targeted assistance.

Once I have more details, I'll do my best to find a solution or provide a workaround for this issue.


[BUG]: War factions is empty

Link to faulty endpoint
/api/v1/war
The name of your client/application
https://github.com/sebsebmc/helldivers-history
Request information
Factions currently responds with [] and no actual data
Steps to reproduce
curl -H "Accept-Language: en-us" https://helldivers-2-dotnet.fly.dev/api/v1/war
What is expected?
Something like ["Humans", "Terminids", "Automatons"]
What is actually happening?
{"started":"2024-01-23T20:05:13Z","ended":"2028-02-08T20:04:55Z","now":"1970-02-24T10:33:40Z","clientVersion":"0.3.0","factions":[],"impactMultiplier":0.012120398,"statistics":{"missionsWon":112362781,"missionsLost":11913252,"missionTime":119763643969,"terminidKills":9386109258,"automatonKills":3204924753,"illuminateKills":28,"bulletsFired":82143992697,"bulletsHit":83056767905,"timePlayed":119763643969,"deaths":407118779,"revives":2,"friendlies":56219002,"missionSuccessRate":90,"accuracy":100,"playerCount":245023}}

### System Info

_No response_

### Any additional comments?

_No response_

Thanks for the detailed issue.
Should be fixed in this PR.


This is no longer a universal wheel

If you run python setup.py bdist_wheel, you will get py2-py3 .whl files.
I think it's become a Python 3-only package since #600 as the PyPi meta data was updated to say so.
See: https://packaging.python.org/guides/distributing-packages-using-setuptools/#universal-wheels

Coverage remained the same at ?% when pulling e3634875b88dd7535e33e68cdcc768c96e9310c9 on benjaoming:py3only into 4fe1854ee30e24adfc57884342517bbf506d0cd9 on jazzband:master.

Coverage remained the same at ?% when pulling e3634875b88dd7535e33e68cdcc768c96e9310c9 on benjaoming:py3only into 4fe1854ee30e24adfc57884342517bbf506d0cd9 on jazzband:master.

This also addresses #601


Language Change , preferredLocale BUG

I've tried to example for changing preffered local but locale is not changing such as if i select a language it stays old one.

Okay it can be close because im emberassed, and your website looks wrong info there :)
There's missing 'BREAK' in switch case :)


Add license

Closed by https://github.com/datafusion-contrib/datafusion-tui/commit/e08cf12b18e22dc24d71cf86d7d9ce5c7fda1862


[Feature Request] Allow configuration of distance increments

It would be great to be able to specify when and how color coding of a measured path applies. - This feature would be relevant for systems, that allow more than two times the base movement per round (e.g. Pathfinder 1 with Unchained Action Economy or Warhammer 4e - Run Action for sprinting).
I could imagine having a list of range increments, supporting constant values and formulas referencing actor properites (such as base movement). - This feature would make this module applicable to a very broad range of systems and system variants.

Added to CONFIG.elevationruler.SPEED in v0.8.10. You can now add an unlimited number of speed categories in the config, as well as custom speed functions if necessary.
If you have a specific system(s) in mind, feel free to open a Git issue describing how speed for that system should work. I can add it to the defaults.


hubble/relay: Fix certificate reloading in PeerManager

This change fixes an issue with the PeerManager that can lead to Relay being unable to reconnect to some or all peers when the client certificate expires or the Certificate Authority is replaced.
Before this change, when the client certificate changes, we did not redial or update the exiting gRPC ClientConns. When the old certificate becomes invalid, (expiring, changed CA, or revoked) The connection will eventually fail with a certificate error.
However, the gRPC ClientConn is not closed, but treats the certificate error as a transient failure and will retry connecting with the old credentials indefinitely.
In most cases this will cause the relay health checks to fail. Relay will restart and successfully reconnect to all peers. However, if a new peer joins between the certificate being updated and the connections failing, Relay may keep on running in a degraded state.
This issue was introduced by #28595. Before that change, Relay aggressively closed and re-dialed ClientConns on any error, mitigating this problem.
We fix this issue by wrapping the provided gRPC transport credentials and updating the TLS configuration whenever a new TLS connection is established. This means every TLS connection will use up-to-date certificates and gRPC ClientConns will be able to recover when their certificate changes.
Fixes: aca4d42ce80d ("hubble/relay: Fix connection leak when reconnecting to peer service")
Please ensure your pull request adheres to the following guidelines:

[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.

/test

Hit flake that should be fixed by https://github.com/cilium/cilium/pull/31381  Rebasing on main

/test


What is CPX file

Run Command to clear space:
curl "http://<IP_ADDRESS>:9333/vol/vacuum?garbageThreshold=0.0001"
However, the background log reported an error:
E1120 13:28:11 50415 volume_grpc_vacuum.go:66] cleanup volume 109: remove /mnt/bjshdata/weedfs-waipian-quanguo-back/weedfs215/data/109.cpx: no such file or directory
What is CPX file? Will it affect the clean space?

you can ignore it.

btw: your version is too old.

you can ignore it.

hello，Thank you for your reply！！！
Why do I perform a curl "http://<IP_ADDRESS>:9333/vol/vacuum?garbageThreshold=0.0001", the disk space increases instead of decreasing.

you can ignore it.

hello，Thank you for your reply！！！
Why do I perform a curl "http://<IP_ADDRESS>:9333/vol/vacuum?garbageThreshold=0.0001", the disk space increases instead of decreasing.

At the end of the command, disk space increases instead

you can ignore it.

hello，Thank you for your reply！！！
Why do I perform a curl "http://<IP_ADDRESS>:9333/vol/vacuum?garbageThreshold=0.0001", the disk space increases instead of decreasing.

At the end of the command, disk space increases instead

curl "http://<IP_ADDRESS>:9333/vol/vacuum?garbageThreshold=0.00001"
{"Topology":{"DataCenters":[{"Free":876,"Id":"DefaultDataCenter","Max":1000,"Racks":[{"DataNodes":[{"EcShards":0,"Free":876,"Max":1000,"PublicUrl":"<IP_ADDRESS>:8083","Url":"<IP_ADDRESS>:8083","Volumes":124}],"Free":876,"Id":"DefaultRack","Max":1000}]}],"Free":876,"Layouts":[{"collection":"","replication":"000","ttl":"","writables":[126,120,122,123,121]}],"Max":1000},"Version":"8000GB 1.50"}

seems some bugs. upgrade first.


Import Video snippets in a more useful manner

Video snippets are currently imported as files with a link from the Journal Entry.
Is there a better way to make videos available? Maybe as tiles?

V10 provides a video page within Journals.


kafka(ticdc):  fix panic issue when sasl enabled by config file

What problem does this PR solve?

Issue Number: close #9669
What is changed and how it works?
check if the LargeMessageHandleConfig is nil first
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
 `None`.

/test cdc-integration-mysql-test


Display info about upcoming booking

Acceptance criteria:

a user can use the input to search in static FAQs
no breadcrumb navigation, no categories, just list of matching FAQ is displayed

https://marvelapp.com/7iihb90/screen/39265596

When I logged in, it showed me this:

I do not know if this is not because I have no booking. I'm probably going to need a test account.
Meggy

I found some mistakes. Such as, the layout of the screen was not completed, the title "Help" is written on the main page, not in FAQ. You can see this in the screenshot.

Secondly, sign out, select other bookings, outbound and return were not in bold font type like in zeplin.
Next, there was a plane between two destinations. I think, that it was not in zeplin. There is just an arrow.
Demo v.

Prototype v.

The last one, the width of the box where the outbound or return is shown, was not correct and there was a line at the bottom which should not be there.
It was tested in _https://introduce-smart-faq.fe.staging.kiwi.com/en/_
Thank you,
Meggy

Thanks Magda :) You are right about this points at https://introduce-smart-faq.fe.staging.kiwi.com/en/ .
However I think the latest version is at https://kiwicom.github.io/smart-faq/ and it should be tested there. Take into account that in that URL we've got a problem with the spinning plane loader ( it is not spinning :sweat_smile: ).
Also regarding the arrow vs plane icon between destinations, we are still waiting for a new release of the icons library, so cannot add the arrow yet.
As for the outbound/return box, can you test that this is correct in that URL pls?

Hmm,  of course, I can. But @jalbertsr wrote me that I can test at https://introduce-smart-faq.fe.staging.kiwi.com/en/ but no problem. I will test at https://kiwicom.github.io/smart-faq/  😄

You are right, he just told me as well, my bad. :) I think https://kiwicom.github.io/smart-faq/ will be more up-to-date in general. I guess we can talk about this on the next meeting.

Ok, so I was testing at https://kiwicom.github.io/smart-faq/ and I discovered some small mistakes. I read that icons will be new.  The different icon was in "blue" textbox, see on the screenshot.
Demo v.

Prototype v.

and icon of exit "x" was bigger than in the prototype v.
Appart from icons, there were other mistakes. Like "FULL FAQ site" and "Sing out" was not in line.
Demo v.

The next one, "Upcoming booking" and "What can we help you with" was not in line. I think, that "upcoming booking" should be a bit higher.
Demo v.

Prototype v.

Only in Opera, "Full FAQ site" and the icon was not in line.
Demo v.

The last one, again I saw this in another issue. The icon "magnifier" was not in the middle of the box.
Demo v.

Prototype v.

I do not know If that was part of this issue, but I write this: some subcategories of FAQ were out of the box.
Thanks,
Meggy 😄

Thanks @MagdalenaAlmanova,
A few doubts just to make sure what bugs have been fixed since you saw them and which need to be addressed:

Regarding the Upcoming booking and What can we help you with alignment. What design/prototype are you basing it with? I don't see them aligned in this design

The *Full FAQ site" + "Sign out" mis-alignment. I see it fine in my browser

Will fix the Magnifier mis-alignment tho, that is still present!

This will be edited.
Thank you for your answer, about the first question: It was an old "prototype v.". I think that it is Ok now. :)
But I cannot sing in, it showed me the white page. I am going to try it tomorrow.
M.

Yep I think the URL https://introduce-smart-faq.fe.staging.kiwi.com/ is not updated yet, it's also giving me problems.

ok


Fix Chef-15 Habitat Builds

Description
This PR brings the chef-15 branch into alignment with master's approach to building, testing, and promoting Habitat artifacts.
Signed-off-by: Christopher A. Snapp<EMAIL_ADDRESS>Types of changes

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

Checklist:

[X] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[X] All commits have been signed-off for the Developer Certificate of Origin.

@christopher-snapp How's this one coming along?

@tas50 I think this PR is ready for review now that we chased down the last remaining failure by bringing the executables tag over from master

Congrats. You battled Ruby and won

🎉 💪


(PUP-5395) Fix problem with lookup_options not found in module

A check for qualified name in modules prevented lookup of the
'lookup_options' key in a module. This commit adds that check and
a test that verifies that lookup_options declared in environment
and module are merged and used.

BTW: What happens if you call the lookup function with the key lookup_options ?

I am fine with the rest - but curious what the intended result is of a lookup call, and wonder if there should be a test for that.

A lookup of 'lookup_options' will be handled as any other lookup which means that it will be found in global and environment scope but not in module scope (since it's not prefixed with a module name).
The lookup will do what it always does and start with a "meta" lookup of the key. It doesn't matter that the key is 'lookup_options'. If there is a merge instruction for the 'lookup_options' key, then it's applied during the actual data lookup. It will not affect the meta looup.

That behavior when looking up "lookup_options" is a bit odd. It would have been less surprising if it actually looked up "lookup_options" in every module and produced a hash of all the options. Naturally this would only be done when looking up lookup_options. This behavior is useful for debugging purposes. Think this deserves its own ticket (where this problem can be discussed and a decision made).

For the record, "if it actually looked up "lookup_options" in every module and produced a hash of all the options" would IMO be very surprising given that it never happens in a real situation. No module will ever merge its "lookup_options" with another module.


'Skip to content' not adjusting to mobile screens in devtools (brave)

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[X] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
Note: Exists in all docusaurus projects during development and after building.
In devtools, after changing the width of the screen, the 'skip to content' element still exists in screen.
This is the docusaurus template in CodeSandBox (It also exists in my repo and all the websites using docusaurus).

The element disappears after focusing.
This issue only exists in Brave Browser. All the major browsers tested works fine.
Reproducible demo
https://docusaurus.sse.codesandbox.io/
Steps to reproduce

Go to site using Brave Browser
Open devtools
Change width

Expected behavior
The 'skip to content' element should not appear on screen unless it is focused.
Actual behavior
In Brave Browser, the 'skip to content' element always appears when changing screen for the first time.
Your environment

Public source code: https://codesandbox.io/s/github/facebook/docusaurus/tree/main/examples/classic
Public site URL: https://docusaurus.sse.codesandbox.io/
Docusaurus version used: 2.0.0-rc.1
Environment name and version (e.g. Chrome 89, Node.js 16.4): Brave Browser Latest Version

Self-service

[ ] I'd be willing to fix this bug myself.

If it only happens in Brave (and I don't use it) do you have basic idea about why it happens? I personally don't want to spend much time debugging it.

If it only happens when devtools are open, maybe we don't care much?
Does it happen for brave mobile users?
Does it happen if you reduce the window width manually without the devtools?

Maybe this is issue is targeted for specific people use brave, I guess.
It only happens when opening devtools (mobile screen).
It does not happen when manually changing the screen.
Maybe this is too minor.


[flutter_conductor] Automate the release process with a CLI tool

Key Results
P1

[x] Flutter Conductor can package and release a build to the dev channel.
[x] Flutter Conductor can package and release a build to the beta channel.
[x] Flutter Conductor can package and release a build to the stable channel.
[x] Flutter Conductor has been successfully used to release a dev release by two SWEs not on the release team, and a beta release by a SWE not on the release team.

Used for 2 dev releases, not a beta release

[x] Flutter Conductor can auto-generate PR descriptions.
[x] Flutter Conductor can dry-run cherrypicks to the beta and stable branches.

P2

[ ] Flutter Conductor can sign the engine binaries.
[ ] Flutter Conductor can update iOS prebuilt utilities
[ ] Flutter Conductor can access the Cocoon API to validate devicelab builds.

blocked by cocoon backend support for release branches, https://github.com/flutter/flutter/issues/72466

[ ] Flutter Conductor should allow tracking manual changes that don't map to upstream commits
[ ] Flutter Conductor should support making engine-only cherrypick releases for internal customers https://github.com/flutter/flutter/issues/89673

Additional

[x] tool should update .ci.yaml's enabled_branches fields on the first release of a new candidate branch
[ ] branching recipes/builder config
[ ] Finding the Dart version that rolled internally at go/dart-version
[ ] Identifying the range of engine hashes with this Dart version
[ ] Identifying the range of framework hashes with the above engine range
[ ] Checking the LUCI dashboards to ensure that the candidate build passes all tests.
[ ] Notifying the release and internal Google roller the framework hashes in the roller chat.

Take version number and determine candidate branch:
git branch --remotes --contains $(git rev-parse "$TAG") | grep 'flutter-[0-9]+.[0-9]+.-candidate.[0-9]+'

A UI should support creating/tracking manual fixes that don't map directly to an upstream commit

@christopherfujino are we still working towards the goals in this issue?

No, this is stale. The action items that are still planned are being tracked elsewhere, and the rest are obsolete. I will close this bug now.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/99085

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/99280

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/99384

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/109410

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/109830

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/114437


18 we need to make the robot strafe

Before issuing a pull request, please see the contributing page.

No longer need this


Chroma: Rust highlighting fails with raw multiline string not terminated by semicolon

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.98.0+extended linux/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
Yes
Here is a screenshot of the issue:

Note how the string highlighting continues past the end of the function. Changing it to end with a semicolon fixes it:

This may just be an issue with the underlying Chroma library, but I figured I would start here since Hugo is how this issue was surfaced.

To get a fix for this, you need to open up an issue in the Chroma issue tracker: https://github.com/alecthomas/chroma/issues

This has been resolved upstream. Just waiting for a new release...


Show artist claimed minutes in their dashboard

Artists should be able to see how many claimed and unclaimed minutes they have.
This should be displayed within the dashboard.

Closed with #60


SHARK does not launch, 'index' unhandled exception.

Thanks. I've marked this version as broken for now and am working on a fix.


Review Github External Collaborator expiry dates

We currently don't have an automated process for review of expiry dates.
We should carry out a manual review until automation is in place.

Done.


Beta dependency tracking executes watchers with inconsistent values

Version
2.5.17-beta.0
Reproduction link
https://jsfiddle.net/w5d9gqmo/3/
Steps to reproduce
In provided example:

open console
hit increment
observe computed value evaluations in console

In vue terms:

create dependency structure with many paths to the same watcher (A->B, B->C, A->C)
Notify leaf watcher about change (data change)
Observe too eager synchronous updates of watchers on every intermediate change

What is expected?
All updated computed values are executed once and with correct dependant values.
twoCounts evaluated to: {count: 2, countPlusOne: 3}

What is actually happening?
Computed values are executed multiple times with all intermediate dependency values.
twoCounts evaluated to: {count: 2, countPlusOne: 2}
twoCounts evaluated to: {count: 2, countPlusOne: 3}

The issue is clearly caused by this commit: https://github.com/vuejs/vue/commit/653aac2c57d15f0e93a2c1cc7e6fad156658df19
I did some debugging and found the cause.
Dependencies are notified synchronously about the watcher update in the notify loop, but the updating watchers might be accessed too early with stale value and no information about necessary recomputation.
I attempted a fix by splitting Dep.notify into two phases with separate loops for dirtify and update. It worked for simple situations where there is triangle of dependencies (countPlusOne in the example), but it stops working when the graph is any more complicated (paths are larger than 1). This is illustrated by countPlusTwo computed in the example.
Possible full fix would involve either traversing the full dependency graph to dirtify all deep dependants first, or collecting the the array of dependants of my dependants like in previous implementation.

As a sidenote:
This commit also causes bugs in the DatePicker component of element-ui.
https://circleci.com/gh/sodatea/regression-test-prototype/79

This has been reverted in 6b1d431a89f3f7438d01d8cc98546397f0983287.
The original intention of the change was to avoid unnecessary re-renders when a computed property's dependencies changed,  but the computed value remains unchanged. However, it requires computed properties with dependencies to become "eager", and re-evaluate synchronously whenever one of its dependencies change. This leads to the issue described here.
Chained computed properties are pretty common, and most likely more common than the case we originally tried to prevent (computed property deps changed but value remains same). Most importantly, the original behavior does not lead to duplicated computation even in the worst case scenario, while the now-reverted behavior could lead to potentially much more wasted CPU cycles. So we are reverting this change.

Most importantly, the original behavior does not lead to duplicated computation even in the worst case scenario, while the now-reverted behavior could lead to potentially much more wasted CPU cycles. So we are reverting this change.

While that's probably true statistically, it's still unfortunate for situations where a computed property does some heavy calulation over and over because a previous computed property often updates, but always returns the same value.
I guess in these situations the user must do some manual caching in this computed props, or use a memoized method instead?

it's still unfortunate for situations where a computed property does some heavy calulation over and over because a previous computed property often updates, but always returns the same value

Yes, this was exactly the situation I reported in #8540 (before seeing that it was a duplicate). I was trying to use computed props as an elegant way to cache intermediate results.
The actual behavior was surprising to me, and there may be others out there who are constructing their computed props as "intermediate caches" with expectation of better performance than they're getting due to incorrect belief about re-compute behaviors.

I guess in these situations the user must do some manual caching in this computed property, or use a memoized method instead?

Yes, this is what I'll need to do instead. Would love if eventually this memoization behavior was built in to computed props!

FYI our use-case was to prevent certain calculations from happening on rapid events. For example:
{
  data() {
    return {
      width: 0, // updated on every resize event
    }
  },
  computed: {
    isMobile() { return this.width < 400; },
    dynamicStyle() {
      if (this.isMobile) {
        // expensive stuff
      }
      // expensive stuff
    },
  }
}

@indirectlylit You can accomplish this by caching the state by yourself.
  data() {
    return {
      width: 0, // updated on every resize event
      isMobile: undefined, // let it be handled by "immediate" watch
    }
  },
  watch: {
    width: {
      immediate: true,
      handler () {
        this.isMobile = this.width < 400
      }
    }
  },
  computed: {
    dynamicStyle() {
      if (this.isMobile) {
        // expensive stuff
      }
      // expensive stuff
    },
  }
}

Note that this illustrates the most generic pattern, but in your case you can probably just update isMobile inside the resize event anyway (and you probably should, less code and much simpler solution).
This is almost equivalent to what the previous buggy dep tracking was doing - making an eager recompute. This is that way because every watch or render (template code) is essentially forcing it's recomputation on any change, in other words it's always eager. On the other hand, the computed value is always waiting until explicitly requested, in other words it's always lazy. I personally find that much simpler to reason about.
If I could propose any potential solution to that, I think it might be viable to add something like lazy: false as an additional computed option, which would effectively translate to the pattern above.
Like so:
// this is a proposal, not a working code
computed: {
 isMobile: {
   lazy: false,
   get () { return this.width < 400; }
 }

Thanks @Frizi!
Yup, adding data and watchers was exactly what I ended up doing.
The example above was a simplification of our actual use-case; you can see the full code change here for context.
I appreciate that this might be a case where implementation details (lazy vs eager evaluation) might need to bubble up to the Vue API and be exposed in some way.
In an ideal world though what I'd love is kind of a combination that gets used under-the-hood: eagerly set 'dirty' flags without recomputing, and lazily recompute dirty values when requested.
(I don't know enough about the dep tracking in internals in Vue to know how feasible this is in practice...)

Possible full fix would involve either traversing the full dependency graph to dirtify all deep dependants first, or collecting the the array of dependants of my dependants like in previous implementation.

re-reading your original issue, I see this is very similar to what you already said :)


[FEATURE REQUEST] Enable deleting floating instances

Describe the problem you're trying to solve in your project
I'm not trying to solve a problem in my project; it's just something that can become a problem.
When painting vegetation onto a mesh that later changes, instances can end up floating in the air.
But as the brush is projected onto ground, it cannot reach those instances anymore to clean them up.
Describe a feature you consider and how it will help you
I guess there could be multiple ways to solve this.
-The most hardcore way (that substance painter afaik uses to reapply edits to a changed mesh): remember each brush stroke and add an option to replay the sequence of actions.
-The most naîve option: reproject instances of a selected type a specific distance downwards.
-Or more viable options:
-Make the brush (sphere) detachable (and in detached state positionable via transform-gizmos) with a button to apply on click
-Add an automated way to delete instances that are a certain radius apart from potential ground or other geometry in general
Describe alternatives you've considered
Not using an addon for foliage placement
Describe how you imagine it would work. With code, pseudo-code, diagram or a drawing
I think each option already kind of explains itself

Okay, so here are the options:

Implement a full-blown selection tool (see circle select in Blender) and delete the selected instances.
Add a 'remove flying instances' button, that performs a raycast to instance origin to see if there's ground underneath and deletes the instances.

Option 1 seems the most proper one. Buuuut it might be beyond the scope of a 1.1.0 version. I will assign it for now, but I might move it to 2.0.0 instead (which will probably happen once Godot 4.0 is released and stable)

So, the prototype I made looks good.

This algorithm creates a square brush view frustum
Iterates over octree nodes
Unprojects inidividual objects on the screen
Finally it rejects those outside the circle area (since frustrum tests use a square shape)

An actual implementation will take some time though.


A question: I cant set redis db_number in the config file

As  the title showed, If I set a db_number for redis in the config.toml file, I would get an error msg from the server:"dial tcp: address tcp/6379/1: unknown port".

Could you show me your DSN of Redis? I will investigate on it later.

Could you show me your DSN of Redis? I will investigate on it later.

redis://localhost:6379

Hi, @anphy. I tried cache_store = "redis://localhost:6379/1" in my configuration and there is no problem.

Hi, @anphy. I tried cache_store = "redis://localhost:6379/1" in my configuration and there is no problem.

Can you try inserting a feedback with api and see what the sever will print?

This issue seems irreproducible. Feel free to reopen it if you need more help.


Flight SQL is slower

I have recently been running flight sql API to do some database querying on my ubuntu version 20.04.6 lts sever machine. Following all the steps on this repository I managed to build the executable using cmake and ran some queries with duckdb. The first time I did this was with the flight sql version 13 and duckdb version 0.8.0. Everything ran well in the end and the querying speeds were really fast compared to traditional ODBC with MySQL server. Now I have upgraded my ubuntu version to 22.04.3 lts to use with the new version 15 of flight sql. This new version is also using a newer version duckdb, 0.9.0. I downloaded the executable for linux from this repository and ran it. Doing the same queries I did previously I noticed slower speeds with this new version. I don't know if it has to do with the newer version of duckdb or ubuntu or is something else entirely. I also released this executable is far heavy than the one I built with cmake for version 13. My version 13 flight sql was 2.4mb in size but this newer already compiled executable is about 80mb in size, a big difference.
Any ideas as to why things are slower now with this upgrades? Am now getting the same speeds sometimes even slower speeds than using ODBC with MySQL server when querying.

Hey @BrandonNgwa - what kind of queries are you running?  Are they large OLAP-style queries?  Do you fetch a lot of data, or just a few rows?
We switched to a statically linked executable recently (like DuckDB has) - that builds all of the dependencies into it (Arrow, DuckDB, SQLite, etc.) - which makes it larger.  The plus side is that you don't have to have any of the dependencies installed, the downside is a larger executable.
We'll run some benchmarks on my side to see how tpc-h performs...

Hello prmoore77, thanks for your reply. I don't think am running any OLAP-style queries but yes I am fetching large amounts of data. Am using a simple SELECT statement with a LIMIT clause to retrieve a certain number of records in batches from from a table in my duckdb database. Then I record the time it takes to get each batch. This are the batches, [ 100000, 500000, 1000000, 2000000, 3000000, 4000000, 5000000, 6000000, 7000000, 8000000, 9000000, 10000000]. I have ran this a couple of times since flight sql version 12, speeds where good but I don't know why now its a bit slower with the upgrades.
To give you an example here are my execution times
This when I ran the script on my ubuntu server machine where everything is installed. This was using flight sql version 13 with all the dependencies and on ubuntu 20.04.6 lts
Query for 100000 records executed in 0.78 seconds
Query for 500000 records executed in 2.78 seconds
Query for 1000000 records executed in 2.74 seconds
Query for 2000000 records executed in 4.21 seconds
Query for 3000000 records executed in 5.63 seconds
Query for 4000000 records executed in 7.32 seconds
Query for 5000000 records executed in 9.14 seconds
Query for 6000000 records executed in 9.71 seconds
Query for 7000000 records executed in 11.48 seconds
Query for 8000000 records executed in 13.46 seconds
Query for 9000000 records executed in 15.12 seconds
Query for 10000000 records executed in 16.99 seconds
This are the speeds now having upgraded my ubuntu to 22.04.3  to run with the new flight sql executable plus all the dependencies.
N records	Run 1	Run 2	Run 3	Run 4	Run 5	Average
100000	2.18	2.13	2.2	1.69	2.01	2.04
500000	3.6	2.94	2.85	2.66	2.82	2.97
1000000	7.59	4.05	4.39	4.64	5.55	5.24
2000000	24.69	21.5	21.9	20.78	22.03	22.18
3000000	27.66	28.15	28.2	27.62	27.93	27.91
4000000	30.09	29.29	29.43	28.4	28.96	29.23
5000000	30.77	31.45	30.66	29.81	30.02	30.54
6000000	32.44	32.74	32.67	32.93	31.2	32.40
7000000	38.77	35.49	35.97	37.08	35.94	36.65
8000000	43.16	42.98	43.96	44.16	40.56	42.96
9000000	52.25	47.45	45.07	47.09	44.65	47.30
10000000	52.86	52.85	51.09	50.84	50.22	51.57
Don't know why thinks are slower now.
Also I get now why the executable is much bigger. Overall is an advantage since you don't have to install the dependencies now.

Hi - a few questions:

Are you fetching from a different client computer?
If so, has the network speed between your client/server changed?
Are you using the Flight SQL ADBC or JDBC driver?  If so - what version(s)?
Are your tests using the older version repeatable on the same infrastructure?

Thanks.

I log into my remote sever from my pc using ssh and run all the queries on the server itself.
The network speeds were mostly the same for when I was testing with the old versions and with the newer versions.
I am using adbc-driver-flightsql  0.9.0
Yes the test were ran on the same infrastructure with my server machine having the same exact specs.
The main thing that changed was I that I upgrade from ubuntu 20. to 22. to be able to use the new executable of flightsql

I tested TPC-H SF1k on my end - and I didn't find performance degradation from my previous tests (before static linking).  That being said, I don't fetch large result sets.
There could be a slow down in some of the various components related to fetching perhaps - in the Arrow Flight server side, or the ADBC client, perhaps that you are observing.
I'll attempt to benchmark that on an older version of the server executable to see the impact on my end.  It may take a while, however - as I have some other urgent priorities at present...  Thanks for reporting the issue.

Ok I appreciate all the feedback. I will run some more test on my side to campare

No problem.
Thank you for all the feedback.
I will run some more test on my side to try to narrow down the problem.

hi @BrandonNgwa - a lot has changed (Arrow and DuckDB versions, etc.) in the codebase since this issue was opened.  I will close this one for now.  Please open another one if you continue to have the issue.  Thanks.


Floor plan image URL invalid

Floor plan image URL changed in the GDG-Nantes/Devfest2023 repo.
We need to fix it in the Confeti's import script.

Feel free to open a PR. Or I can do it too if you know the new url.

@martinbonnin done : https://github.com/joreilly/Confetti/pull/877

@martinbonnin sorry the PR was wrong. Here's the new one :
https://github.com/joreilly/Confetti/pull/878

Fixed with https://github.com/joreilly/Confetti/pull/878 🎉