Recent update causes latest Rust time crate to report old vuln

I encountered this wrt https://github.com/github/advisory-database/blame/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json , because time is a very common Rust crate.
Suddenly over the weekend, the latest version of the crate started having vulns reported by it on api.osv.dev.
i.e. curl -d '{"version": "0.3.20", "package": {"name": "time", "ecosystem": "crates.io"}}' "https://api.osv.dev/v1/query"
https://osv.dev/vulnerability/GHSA-wcg3-cvx6-7396 shows the results in a web format.
https://github.com/github/advisory-database/commit/b010a6579e41bb2c39988e2477c173d8cecd9ada seems to be the cause.
I see it is removing many last_affected, but in the case of time GHSA-wcg3-cvx6-7396, it is only adding an empty "fixed".
The JSON contains
"database_specific": {
        "last_known_affected_version_range": "< 0.2"
}

This feels a bit like https://github.com/github/advisory-database/issues/470.
This record should have a last_affected of 0.2.22 according to https://github.com/time-rs/time/blob/v0.2.23/CHANGELOG.md#compatibility-notes , or maybe fixed in 0.2.23.

Hey @jayvdb we should have that fixed for you! Thanks for letting us know.
Do you want to test it on your end and confirm before I close this issue?

99dbb638e89 did updates to fix the last_affected for most records, but deleted GHSA-wcg3-cvx6-7396 without explanation in the commit.
Interesting that https://github.com/advisories/GHSA-wcg3-cvx6-7396 still exists, and doesnt yet reflect that it was modified an hour ago.

The solution was to delete "GHSA-wcg3-cvx6-7396"?

🤔 yeah, was not expecting that when we resynched the data. The rest of the advisories from that batch reverted properly. I'll try synching GHSA-wcg3-cvx6-7396 again. Apologies about the data issues here. We're doing some cleanup of the code that handles converting advisories to OSV JSON files and discovered a regression yesterday.

@jayvdb good news, bad news. I was able to confirm that the bug you initially reported (fixed versions showing up blank and last_affected getting moved to database specific meta data) was indeed fixed like we thought it was. But, there's another bug that's totally unrelated that's causing GHSA-wcg3-cvx6-7396 to be unprocessable leading to it being deleted. I'm working on that now but may not have it resolved until tomorrow.

No worries @chrisbloom7 .  osv-scanner has ability to ignore vulns, and we've already used it for this problem.  Keen to remove the ignore rule, but another day or two wont hurt.
I am a bit surprised there are not more people "here" somehow making their voice heard about this, given there are 2000 at https://crates.io/crates/time/reverse_dependencies (that '2000' seems suspect - very round, maybe the list is trimmed) - this issue should be effecting almost every Rust program that does anything interesting.
Are Rust devs not using osv-scanner or GHSA via other means? Or do they all have https://github.com/advisories/GHSA-wcg3-cvx6-7396 in their ignore lists already and this didnt notice this recent regression? (If anyone else is effected by this, please :+1: the issue; don't comment unless you've something useful to add.)

@jayvdb https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json has been restored

@chrisbloom7 , thanks for bringing it back as https://github.com/github/advisory-database/blob/da022ccd8/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json
At the moment, osv-scanner is still reporting the latest time crate as vuln to this GHSA.  Maybe it hasn't sync'd yet.  There systems dont appear to show a sync timestamp for each data source.
However in the JSON, the first affected range is "introduced": "0.1" without a "fixed", but having a database specific "last_known_affected_version_range": "< 0.2".  I fear that without a "fixed", this GHSA is still going to seen by osv-scanner as affecting the fixed versions of the crate.
And the following appears three times in the JSON - surely there is no value in having repeated entries in the JSON:
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "time"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0.2.7"
            },
            {
              "fixed": ">= 0.2.23"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "< 0.2.23"
      }
    },

Yeah, so... 😳 I fixed the wrong bug. Sorta. I mean I fixed some bugs that were definitely bugs, but I missed the bigger one. That's also been fixed now and you'll see that https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json has been updated again to remove those bad affected packages. I think we've got everything back where it should be now. Thanks for staying on top of this!

regarding:
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0.1"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "< 0.2"
      }

Let me check in with one of the curators. I know we've been talking about a similar issue on another advisory.

osv-scanner now works without this record being ignored!  yay, thanks to all who helped.
It's been five days since https://github.com/github/advisory-database/commit/b010a6579e41bb2c39988e2477c173d8cecd9ada, and nobody else in Rust world noticed / cared enough to give feedback here. :/


error MSB3030: Could not copy the file "........\arm64-apple-ios-simulator.private.swiftinterface" because it was not found.

Many times when i want to build a package the build fails with error:
error MSB3030: Could not copy the file "C:\Users\samos\.nuget\packages\kebechet.maui.microsoftclarity.ios\2.0.0\lib\net8.0-ios17.2\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.private.swiftinterface" because it was not found.
Issue created: https://github.com/xamarin/xamarin-macios/issues/21111
Probably it is caused by MAX_PATH limit:
https://github.com/dotnet/maui/issues/17828
https://developercommunity.visualstudio.com/t/Allow-building-running-and-debugging-a/351628

Workaround:
Remove from your local nuget storage all files in folder: kebechet.maui.microsoftclarity.ios\2.0.0\lib\net8.0-ios17.2\Maui.MicrosoftClarity.iOS.resources\Clarity.xcframework\ios-arm64_x86_64-simulator\Clarity.framework\Modules\Clarity.swiftmodule\arm64-apple-ios-simulator.private.swiftinterface

Should be fixed by:
https://github.com/Kebechet/Maui.MicrosoftClarity/commit/7a108731c9cbcf5beb0c58fc77c5caa1f09e98a8


Difference in runtime behavior of decorators between commonjs and either systemjs or amd

TypeScript Version:  2.1.6
function myDecorator(decorated : any) : void {
    console.log(decorated);
}

@myDecorator
class MyClass {}

Expected behavior:
When transpiled to es5 using any of the module strategies, the log statement will be reached when code is run. No instantiation of the class is necessary. The behavior should be identical no mater what module strategy has been employed.
Actual behavior:
In commonjs the log occurs at runtime as is. In systemjs and amd the whole thing resides in the describe or register and block and the log statement is not run without instantiation of the class.
Here is SO question based on this

But these are the semantics of SystemJs and AMD modules. the module is not executed until it is loaded. hence the "A" (Asynchronous) in AMD.


Farcasterd syncer types

Can you rebase this so we can run the improved CI against it?

Codecov Report

Merging #583 (a8af97d) into main (9b8ce02) will decrease coverage by 0.0%.
The diff coverage is 0.0%.

@@           Coverage Diff           @@
##            main    #583     +/-   ##
=======================================
- Coverage    9.2%    9.2%   -0.0%
=======================================
  Files         34      34
  Lines      10738   10783     +45
=======================================
  Hits         991     991
- Misses      9747    9792     +45

Impacted Files
Coverage Δ

src/farcasterd/runtime.rs
0.0% <0.0%> (ø)

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 9b8ce02...a8af97d. Read the comment docs.


Review Rulesets and add first party Detekt extensions

Motivation
Got a build failure with Detekt 1.22.0 - https://github.com/TWiStErRob/net.twisterrob.sun/pull/170
* What went wrong:
Execution failed for task ':component:widget:detektReleaseUnitTest'.
> Run failed with 3 invalid config properties.
  	- Property 'style>ForbiddenPublicDataClass' is deprecated. Rule migrated to `libraries` ruleset plugin.
  	- Property 'style>LibraryCodeMustSpecifyReturnType' is deprecated. Rule migrated to `libraries` ruleset plugin.
  	- Property 'style>LibraryEntitiesShouldNotBePublic' is deprecated. Rule migrated to `libraries` ruleset plugin.

changed style to libraries but still got an error:
> Run failed with 1 invalid config property.
        - Property 'libraries' is misspelled or does not exist.

looked for how to include "libraries" ruleset and found nothing.
What's in this PR?

Update README.md to link to marketplace and give an easy copy-pasteable example for all 3 custom rulesets.
Add links to their documentation for each marketplace item (if available).
Document rulesets which are not included by default.
Review all third party marketplace items and add missing rules.
Surface unpublished Detekt extensions at the bottom.
Few smaller fixes

Note: please excuse my React, these are the first lines I've ever written. Might need some touchup.

Still not clear how to avoid this???
        - Property 'libraries' is misspelled or does not exist.

Especially when using the maven plugin, NOT gradle. See my issue — https://github.com/Ozsie/detekt-maven-plugin/issues/169.
This issue states "provide a clear examples", but where can I find them?

Based on the scope in your above dependency, it's added to the wrong classpath. You added it to the runtime of your code, but it needs to be present on the classpath of the build when the Detekt plugin is executed. I commented on the original issue in the Maven plugin, let's continue there.


removed CmakeLists.txt

fixes issue #2

Also make a PR against fix-hpx branch

@SAtacker have made changes in pr: #4


missing scrap options

Would be great if you added some of the missing scrap options like twohanded & conductive etc

Would be great if you added some of the missing scrap options like twohanded & conductive etc

oh wait, i though about them and forgot them ! thanks you for reminding me it

^^^^^ I am really excited for this change :)

Could we also get the option to play an audio file when the player interreacts with it while holding it? (Clicks while holding it)

Could we also get the option to play an audio file when the player interreacts with it while holding it? (Clicks while holding it)

planned in future, a lot to do for now, i can't prioritize this addition


fix(table): pass disabled property to OverflowMenuItem

Summary

summary_here

Change List (commits, features, bugs, etc)

items_here

Related Issues

Closes IBM/carbon-addons-iot-react#345

Acceptance Test (how to verify the PR)

tests here

:tada: This PR is included in version 1.68.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-beta.9 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add integration tests and other tweaks for filebeat

Apart from adding some integration tests and more templating tests I also made a few other changes:

Added a default working filebeat config into the default values.yaml. This means the default install without any changes will result in logs being sent to the default elasticsearch chart.
Switched the livenessProbe to a curl since httpGet cannot check localhost. We could bind the monitoring API to a non-localhost port but this has security implications
Added integration tests for the oss release of Filebeat/Kibana and Elasticsearch. I did this mostly because I wasn't 100% sure if the monitoring port was available in the oss release. And added it for the other charts to make sure features don't get introduced that would break the oss version.
Added a readinessProbe that checks it can connect to its output. The livesnessProbe will restart filebeat if it isn't responding, and this will prevent upgrades from happening if the new configuration can't connect to its output. And also makes it easy for monitoring tools (like the data we get from metricbeat) to detect if a filebeat container is not healthy.
Fixed various name collisions. A few resources had a hardcoded "filebeat" name which would conflict if multiple filebeat instances were deployed to the namespace. When would this happen? One example is our integration testing, however I can also imagine blue/green deploy strategies or use cases where multiple filebeat daemonsets are deployed to the same cluster and namespace.
Added "namespace" to the hostPath that is being mounted. To make sure there are no conflicts if filebeat is deployed in two different namespaces with the same release name.

it's probably worth a minor note in the filebeat chart's README

Agreed! I think adding this to a Usage notes and getting started section like the Elasticsearch readme makes the most sense.
Potentially giving an example of how to configure one of the other many filebeat ouputs could also be useful. But hopefully an example of how to configure filebeat.yml for Elasticsearch and add the right environment variable should be enough.

I can PR that later though.

🙏


Portable Teleporter not saving settings

The portable teleporter always opens on the public tab, instead of the one used last. Would be nice if it could store the last used tab, maybe even the last used Frequency so that if you want to transport back  there again you would only have to hit the teleport button. But even only saving the tab that was last used would be a huge benefit.

Being someone who uses the portable teleporter a lot this would be useful especially when i'm digging on the moon and run out of oxygen i could quickly teleport back to earth and not lose all my health trying to go through my teleporter list trying to find one of the teleporter frequencies i have on earth

Done! Portable Teleporters now bind to their owner and save the last used frequency.


bmat error: reshape() takes from 1 to 2 positional arguments but 3 were given

Describe the bug
Since cvxpy 1.5.0 our of function (in DIPY) using bmat are failing.  Not sure what was the change and how to update the code.
all was working with 1.4.4.
To Reproduce
import cvxpy as cp
import numpy.testing as npt
import numpy as np

def test_basic_test():
    V = np.arange(1, 7)[:, np.newaxis].astype(float)
    R = np.array(
        (
            [1, 4.24264069, 3.53553391],
            [4.24264069, 2, 2.82842712],
            [3.53553391, 2.82842712, 3],
        )
    )
    if V.shape[0] == 6:
        V = V.T

    f = 1 / np.sqrt(2)

    T = cp.bmat(
        [
            [V[0, 0], f * V[0, 5], f * V[0, 4]],
            [f * V[0, 5], V[0, 1], f * V[0, 3]],
            [f * V[0, 4], f * V[0, 3], V[0, 2]],
        ]
    )
    npt.assert_array_almost_equal(T.value, R)

Expected behavior
No errors like previous version of cvxpy.

The fix should be done in #2542. Either you can downgrade NumPy to < 2.1 or try installing from cvxpy master.
Let us know if this fixes the issue!

Thank you for your feedback. Closing,


Add some additional OLOGIC bits.

This adds a couple features, but most importantly it documents some that were mistakenly associate with the 030 IOB fuzzer, which was fixed in #970.

Kokoro broken again? Can't view the log...

Kokoro is broken because of https://github.com/SymbiFlow/prjxray/issues/972


Make it repeatable

Not sure if I'll need to integrate with repeat.vim or if I can just make it work naturally. Investigate!

This operator modifier is such a great idea! Any progress on making it repeatable?


AMP Minecraft attempts to use /tmp/ for downloads

AMP should probably use a a directoy such as ~/.ampdata/tmp/ in case of failure to /tmp/
I O
Access to the path "/tmp/tmp5d9c81f7.tmp" is denied.
Thrown by the 'Core' plugin while performing the 'UpdateApplication' method.
Related Link: Get help for this issue
v<IP_ADDRESS>, built 23/04/2018 03:00

Users should have read/write access to /tmp/ and /var/tmp/ on a standard Linux system. The only restriction a standard Linux system should have on /tmp/ is the 'sticky bit' to stop users touching files belonging to other users. Users not being able to write to /tmp/ would cause issues in many applications, not just AMP.

That does not appear to be the default for Ubuntu 16.04 or maybe its OVH's image?  Either way its been corrected to match the permissions on my 18.04 instance which works correctly.


Add prototype for improved healthcheck services

Add initial prototype of some k8s friendly healthcheck services
See https://github.com/odpi/egeria/discussions/7686

Initial version now merged


1.13

Close #10
Close #9
Fix https://github.com/conda-forge/pytorch-cpu-feedstock/issues/148

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Thank you for this!


Add Aiken eval to Validator type to be used by all .plutus scripts

Currently the CMLValidator type (name not final) doesn't have an execute implementation because we need to give it some way to evaluate locally.
Aiken provides a way to evaluate (and even cost) locally. We 100% should use it at least for evaluating Plutus scripts locally.

I'm working on this rn. Feels like a good feature to include to help bridge the gap with the Aiken dev.

It's work...ing.... kinda. We have it implemented, but there are some weird bugs with the ScriptContext that hasn't been solved.

I've noticed that this is only relevant on the test network sides. Where we're using BlockFrost, we don't need to do checks. Now, we may still want to, in order to save on comms or something.
The correct architecture here isn't clear to me yet. I think ideally, we'd have a check phase that is independent from the issuance phase. At least for the CML client, they are more tightly coupled because the checks just come for free.
Not ideal, but I don't know the correct solution.

I believe this is fixed here: https://github.com/MitchTurner/naumachia/pull/77


🚀 Feature: Add a dark/light toggle theme button in navbar

🔖 Feature description
Add a dark/light toggle theme button in navbar
🎤 Screenshot
No response
🔄 Additional Information
No response
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

assign


Group button actions for inline chat at the bottom

I recently added a custom "apply and rerun" button for fixTestFailure, but it's a bit ugly when displayed alongside an edit. It would be nice if it were displayed with the default buttons along the bottom.

The "accept/discard" buttons will already apply to the last response, so I don't think putting the button from the participant there would be a big change. Perhaps the button is only moved there if there's no response text afterwards?

The "accept/discard" buttons will already apply to the last response

Nope, it will apply the combined edit of all responses.

so I don't think putting the button from the participant there would be a big change

It's not about change (tho we have plans to change up those bottom buttons a lot) but about correctness. Extensions can have stream.markdown('click here'); stream.button(...); stream.markdown('or click here'); stream.button(...) and in cases like that we cannot move/reposition the buttons. There might a case for the final button but it also be confusing and hard to predict

it will apply the combined edit of all responses.

I think that's surprising behavior! If I'm in chat and trying to refine the prompt over multiple messages/edits, I would expect that to apply the last, final edit, not all of that.

There might a case for the final button but it also be confusing and hard to predict

Yea, the 'final button' case is what I was thinking

I think that's surprising behavior! If I'm in chat and trying to refine the prompt over multiple messages/edits, I would expect that to apply the last, final edit, not all of that.

I hear you but undo'ing previous edits will not allow you to iterate on a partially correct snippet, like

add a log statement
change it to error severity
upper-case the important bits

In such cases we keep the edits applied and tell the LM something like  "the following code is the result of the following exchanges" so that it does more changes to refine bits. It usually replaces everything which effectively means "apply final edit" but it must not be like that, the reality is edits on top of edits form the final result

I demoed this flow in standup and the button position was the first comment I got 😛
I think the 'final button' is probably good behavior. That is, showing all buttons since the last markdown content in the 'footer' area. Followup messages or text after the button would cause it to be rendered in its current location. I can try to PR this if you think it makes sense.

I know you are on a mission to make this particular flow work but I think it's too early and too "one-off" to make changes like this, esp considering the redesigns we have planned


Write a Python program to print numbers from 1 to n

Description
Write a Python program to print numbers from 1 to n
Input  : 5
Output : 1 2 3 4 5

How to contribute

Save the solution in print-numbers-from-1-to-n.py file
Add print-numbers-from-1-to-n.py file in program/print-numbers-from-1-to-n folder

!assign

Hey @cushonz, this issue is already assigned to @anandfresh !!!
Please choose another issue.
Thanks for your interest in contributing to this project.


No module named 'basicsr'

I get the following error with GFPGAN, it's installed in sister directory as per instructions.
>> Error loading GFPGAN: Traceback (most recent call last):   File "c:\users\anibu\stable-diffusion\ldm\gfpgan\gfpgan_tools.py", line 28, in run_gfpgan     from gfpgan import GFPGANer   File "C:\Users\anibu\GFPGAN\gfpgan\__init__.py", line 2, in <module>     from .archs import *   File "C:\Users\anibu\GFPGAN\gfpgan\archs\__init__.py", line 2, in <module>     from basicsr.utils import scandir ModuleNotFoundError: No module named 'basicsr'
However, when I pip install basicsr it says that everything is satisfied completely. I went through instructions and re-installed gfpgan, still doesn't work.

Yep. Did that three times. All dependencies satisfied. No errors when
installing.
On Mon, Sep 12, 2022, 12:02 blessedcoolant @.***> wrote:

Did you setup the entirety of GFPGAN correctly .. ? Go to the directory
where your GFPGAN is copied and do the following. Make sure the virtual
environment that you setup for the Dream Script is active when you are
doing this.
pip install basicsr
pip install facexlib
pip install -r requirements.txt
python setup.py develop
pip install realesrgan
—
Reply to this email directly, view it on GitHub
https://github.com/lstein/stable-diffusion/issues/515#issuecomment-1243504101,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AT2HWAFVCYZ6MSWXNGXXNK3V535UDANCNFSM6AAAAAAQKHYGXY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Yep. Did that three times. All dependencies satisfied. No errors when installing.

Can you check if you are able to perform inference directly using the GFPGAN inference scripts without any errors?

We have refactored our GFPGAN implementation since you had this error. I'm going to close this now - please create a new issue if you still have this problem on the main or development branch.


Automate aws-sdk-go upgrades for ACK

There should be an automation which updates aws-sdk-go in ACK core libraries, runs tests and creates pull requests
Design decisions will include
a) How to trigger the aws-sdk-go update in ACK core libraries? Periodic or Event driven?
b) Presubmit tests that validate whether aws-sdk-go update will break existing functionality in service controllers?
c) How to automatically create PRs for aws-sdk-go update in service controllers

/lifecycle frozen


Issue with inferencing on a tensorrt model (converted from yolo_nas_s)

💡 Your Question
I am experiencing difficulties when attempting to perform inference on a TensorRT model. I have come to the conclusion that the fine-tuning hyper-parameters listed under ''Quantization Aware Training Yolo NAS on Custom Dataset Notebook' are not enough to retrieve a well quantized tensorRT model for the given dataset. Could you provide more documentation on hyper-parameter tuning relating to quantization aware training?
Thank you!

https://github.com/Deci-AI/super-gradients/issues/1288

Hey @Atm-ninetyseven @ChuRuaNh0
Thanks for opening an issue for SG. I'm gathering some feedback on SuperGradients and YOLO-NAS.
Would you be down for a quick call to chat about your experience?
If a call doesn't work for you, no worries. I've got a short survey you could fill out: https://bit.ly/sgyn-feedback.
I know you’re super busy, but your input will help us shape the direction of SuperGradients and make it as useful as possible for you.
I appreciate your time and feedback. Let me know what works for you.
Cheers,
Harpreet


ci: more-dependabot

What
ci: more-dependabot
Not sure if it's actually desirable

Codecov Report

Merging #3906 (66c76c1) into develop (d8a5fb5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #3906   +/-   ##
========================================
  Coverage    10.68%   10.68%
========================================
  Files          270      270
  Lines        13428    13428
========================================
  Hits          1435     1435
  Misses       11993    11993

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

I would set the frequency to weekly, as it gets really noisy really fast

This sounds a lot like ChatGPT 🤔

As an AI model language I am still learning open food facts 😊
On Fri, Apr 28, 2023, 12:24 PM Marvin Möltgen @.***>
wrote:

This sounds a lot like ChatGPT 🤔
—
Reply to this email directly, view it on GitHub
https://github.com/openfoodfacts/smooth-app/pull/3906#issuecomment-1527111625,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALUTZZ3ZKVMK5WRKWAB4IXTXDNWC7ANCNFSM6AAAAAAXJLSIWU
.
You are receiving this because you commented.Message ID:
@.***>

@adilwahla please stop using AI models to review pull requests.

Dear neither I have approved nor disapproved this PR & this can only be
done by someone who have write access to Open Food Facts
On Fri, Apr 28, 2023, 2:32 PM VaiTon @.***> wrote:

@adilwahla https://github.com/adilwahla please stop using AI models to
review pull requests.
—
Reply to this email directly, view it on GitHub
https://github.com/openfoodfacts/smooth-app/pull/3906#issuecomment-1527270325,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALUTZZ7T5JFWWMU2TIV2NA3XDOFD3ANCNFSM6AAAAAAXJLSIWU
.
You are receiving this because you were mentioned.Message ID:
@.***>

I swapped everything to Monthly @M123-dev @VaiTon


Why is the detection_image rate so much higher than the camera image rate ?

I am having trouble understanding the rates reported by 'rostopic hz':
rostopic hz /raspicam_node/image/compressed
subscribed to [/raspicam_node/image/compressed]
average rate: 0.622
	min: 1.608s max: 1.608s std dev: 0.00000s window: 2

rostopic hz /raspicam_node/image
subscribed to [/raspicam_node/image]
average rate: 4.635
	min: 0.200s max: 0.235s std dev: 0.01266s window: 5

rostopic hz /darknet_ros/detection_image
subscribed to [/darknet_ros/detection_image]
average rate: 43.037
	min: 0.013s max: 0.030s std dev: 0.00303s window: 43

rostopic hz /darknet_ros/bounding_boxes
subscribed to [/darknet_ros/bounding_boxes]
average rate: 42.849
	min: 0.020s max: 0.030s std dev: 0.00164s window: 42

So the compressed image messages are under 1 hz.  I imagine a few frames are bundled into one message and sent together.  When they are decompressed the image rate is nearly 5hz.  That makes sense, but why is the detection image rate so much higher than the image rate ?  Is darknet_ros pointlessly running the detector nearly 10 times on the same image ?  The bounding boxes are arriving at about the same rate as the detection images (there is only 1 box per image), and inspecting them shows about 10 repetitions of the same bounding box data.  Isn't this wasting a lot of GPU work and watts ?  Is there anyway to ask darknet_ros to run once per video frame ?
My equipment is Raspberry Pi 3b + Pi cam V2 sending compressed images to a desktop with a GTX 1080 ti running the image decompression and darknet node.

There are a few of posts concerning this behaviour. I have looked at the code but I do not understand it well. Nevertheless I have managed to implement a 'fix' that appears to work.
I have a 1080ti GPU and I found that identical bounding boxes were being published around 5 times for each video frame (camera running at about 10fps). GPU usage was about 87%. After implementing the fix bounding boxes are published at the frame rate from distinct frames. GPU usage dropped to 26% or less. GPU Memory usage unchanged.
I am sure that a much more elegant solution could be produced by somebody who actually understood the code. I have never published code on Github and am not sure what I need to do to release the fix for inspection by a wider audience. If anybody is interested I can send them the code.

There are a few of posts concerning this behaviour. I have looked at the code but I do not understand it well. Nevertheless I have managed to implement a 'fix' that appears to work.
I have a 1080ti GPU and I found that identical bounding boxes were being published around 5 times for each video frame (camera running at about 10fps). GPU usage was about 87%. After implementing the fix bounding boxes are published at the frame rate from distinct frames. GPU usage dropped to 26% or less. GPU Memory usage unchanged.
I am sure that a much more elegant solution could be produced by somebody who actually understood the code. I have never published code on Github and am not sure what I need to do to release the fix for inspection by a wider audience. If anybody is interested I can send them the code.

If you want to submit your fix, just fork this project, apply your changes and create a pull request.
Otherwise, you may simply discuss in this issue the modifications you've made, provided they're simple enough.

@elpidiovaldez Can you at least fork the project and implement the fix, even if you don't want to create a PR?

@fiorano10 @leoll2 This discussion seems to have moved to issue #150.  I have given my changes in that thread, and there is another fix which has been proposed there too (but it did not work for me).

@elpidiovaldez I saw that too, I’ll implement your fix and update you.

@fiorano10 cool !  It might be worth trying the other fix too.  It seems to be simpler to implement since you only need to check out 1 file.  It did not work for me, but I have a bad case - a slow camera with a storming gpu.

@elpidiovaldez I have made a PR for your fix, I'll test both fixes tomorrow, and update you. Thanks!


Echo HTTP trailers in addons/dumper

As the title says, the dumper addon should also print HTTP trailers. This should be quite straightforward to add, so I'm leaving this for someone less experienced with mitmproxy development to pick up. :)
If you're at it, please add a test!

@mhils I have tried to fix the mentioned issue in my PR #4234 Please review it :+1:


Extension issue

Issue Type: Bug
Extension Name: python
Extension Version: 2021.10.1317843341
OS Version: Windows_NT x64 10.0.19043
VS Code version: 1.61.0

:warning: We have written the needed data into your clipboard. Please paste! :warning:

Duplicate of #1773.


✨(app) create a redis-sentinel application

Purpose
we choose to use the redis-operator
(https://github.com/spotahome/redis-operator) to deploy a redis
configured with sentinel. Only one OpenShift object is used and deployed as a
Service.
Proposal

[x] implement the redis-sentinel app

Even tho, we will need a new PR allowing to use Redis sentinel in edxapp (see worker probes).

In fact we need to fix edxapp workers probes that would be broken if we switch to redis sentinel. See https://github.com/openfun/arnold/blob/master/apps/edxapp/templates/services/cms/_dc_base.yml.j2#L96

This should be done in an other PR ? This PR just target the creation of a new app

This PR just target the creation of a new app

Ok so the only solution I found for now is to transform the command with this:
celery -A lms.celery inspect ping -d celery@{{ celery_worker.name }}.%$(hostname)

WDYT @sampaccoud @jmaupetit

@lunika I would say that if we want the edxapp healthcheck to validate that redis is working it should be done via the edxapp healthcheck endpoint? But I'm not really aware of existing probes :man_shrugging:

@lunika I would say that if we want the edxapp healthcheck to validate that redis is working it should be done via the edxapp healthcheck endpoint? But I'm not really aware of existing probes man_shrugging

This probe is not used by the wsgi application but by very worker deployed.

Then we should add a small management command in edxapp that checks the redis connection (with or without sentinel depending on the settings the same way as Celery or django-redis-session are connecting to redis...). I would make a simple command that writes a value to redis and reads it again... WDYT?

Loading a management command with the edxstack is too heavy for a health check. That was our first attempt and it proved to be unusable.

Ok so the only solution I found for now is to transform the command with this:
celery -A lms.celery inspect ping -d celery@{{ celery_worker.name }}.%$(hostname)

WDYT @sampaccoud @jmaupetit

Have you tried it with time in a worker pod to evaluate its responsiveness.

$ time celery -A lms.celery inspect ping -d celery@lms-default.%$(hostname)
-><EMAIL_ADDRESS>OK
        pong

real	0m1.211s
user	0m0.992s
sys	0m0.620s

Did you run it multiple times (at least 3) to check execution time "standard deviation"? IMO 1.2s is not acceptable for such probe.

Did you run it multiple times (at least 3) to check execution time "standard deviation"? IMO 1.2s is not acceptable for such probe.

Yes I run it multiple time and this is one the best time I have.

So it's a dead end.


Poetry pyproject.toml wheel dependencies fails to generate

Having the following pyproject.toml file
[tool.poetry]
name = "example"
version = "0.1.0"
description = ""
readme = "README.md"
authors = []

[tool.poetry.dependencies]
python = "3.9.10"
torch = [
  {markers = "platform_machine == 'aarch64'", url = "https://download.pytorch.org/whl/torch-1.12.1-cp39-cp39-manylinux2014_aarch64.whl" },
  {markers = "platform_machine == 'x86_64'", url = "https://download.pytorch.org/whl/cpu/torch-1.12.1%2Bcpu-cp39-cp39-linux_x86_64.whl" },
]

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

and the following poetry.lock file
# This file is automatically @generated by Poetry 1.4.0 and should not be changed by hand.

[[package]]
name = "torch"
version = "1.12.1"
description = "Tensors and Dynamic neural networks in Python with strong GPU acceleration"
category = "main"
optional = false
python-versions = ">=3.7.0"
files = [
    {file = "torch-1.12.1-cp39-cp39-manylinux2014_aarch64.whl", hash = "sha256:6cf6f54b43c0c30335428195589bd00e764a6d27f3b9ba637aaa8c11aaf93073"},
]

[package.dependencies]
typing-extensions = "*"

[package.source]
type = "url"
url = "https://download.pytorch.org/whl/torch-1.12.1-cp39-cp39-manylinux2014_aarch64.whl"

[[package]]
name = "torch"
version = "1.12.1+cpu"
description = "Tensors and Dynamic neural networks in Python with strong GPU acceleration"
category = "main"
optional = false
python-versions = ">=3.7.0"
files = [
    {file = "torch-1.12.1%2Bcpu-cp39-cp39-linux_x86_64.whl", hash = "sha256:870bc47b880fb0488ea5b665bf76fc8df76a55a5cd48917501bf4597e1af6b2e"},
]

[package.dependencies]
typing-extensions = "*"

[package.source]
type = "url"
url = "https://download.pytorch.org/whl/cpu/torch-1.12.1%2Bcpu-cp39-cp39-linux_x86_64.whl"
[[package]]
name = "typing-extensions"
version = "4.5.0"
description = "Backported and Experimental Type Hints for Python 3.7+"
category = "main"
optional = false
python-versions = ">=3.7"
files = [
    {file = "typing_extensions-4.5.0-py3-none-any.whl", hash = "sha256:fb33085c39dd998ac16d1431ebc293a8b3eedd00fd4a32de0ff79002c19511b4"},
    {file = "typing_extensions-4.5.0.tar.gz", hash = "sha256:5cb5f4a79139d699607b3ef622a1dedafa84e115ab0024e0d9c044a9479ca7cb"},
]

[metadata]
lock-version = "2.0"
python-versions = "3.9.10"
content-hash = "b7d2a1b2bf6dddd0bb2fa76dc0a38338509d62e901e7daec4839b316a015fe69"

with the following BUILD.bazel file
load(
    "@jvolkman_rules_pycross//pycross:defs.bzl",
    "pycross_lock_file",
    "pycross_poetry_lock_model",
    "pycross_target_environment",
)

_linux_x86_64 = [
    "@platforms//os:linux",
    "@platforms//cpu:x86_64",
]

pycross_target_environment(
    name = "python_linux_x86_64",
    abis = ["cp39"],
    platforms = [
        "linux_x86_64",
        "manylinux2014_x86_64",
    ] + [
        "manylinux_2_%s_x86_64" % str(i)
        for i in range(17, 25)
    ],
    python_compatible_with = _linux_x86_64,
    version = "3.9.10",
    visibility = ["//visibility:public"],
)

pycross_poetry_lock_model(
    name = "predict_lock_model",
    poetry_lock_file = "poetry.lock",
    poetry_project_file = "pyproject.toml",
)

pycross_lock_file(
    name = "predict_lock",
    out = "predict_lock.bzl",
    lock_model_file = ":predict_lock_model",
    target_environments = [
        ":python_linux_x86_64",
    ],
)

and running
bazel build //predict:predict_lock

results in the following error
INFO: Invocation ID: efb054fe-51cd-4e9f-a8ff-a1a6a3681f81
INFO: Analyzed target //predict:predict_lock (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /workspaces/data-platform/predict/BUILD.bazel:34:26: Action predict/predict_lock_model.json failed: (Exit 1): poetry_translator failed: error executing command (from target //predict:predict_lock_model) bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator --poetry-project-file predict/pyproject.toml --poetry-lock-file predict/poetry.lock ... (remaining 2 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
Traceback (most recent call last):
  File "/home/devcontainer/bazel/output_base/sandbox/processwrapper-sandbox/9/execroot/data_platform/bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.runfiles/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.py", line 298, in <module>
    app.run(main, flags_parser=parse_flags)
  File "/home/devcontainer/bazel/output_base/sandbox/processwrapper-sandbox/9/execroot/data_platform/bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.runfiles/rules_pycross_pypi_deps_absl_py/site-packages/absl/app.py", line 308, in run
    _run_main(main, args)
  File "/home/devcontainer/bazel/output_base/sandbox/processwrapper-sandbox/9/execroot/data_platform/bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.runfiles/rules_pycross_pypi_deps_absl_py/site-packages/absl/app.py", line 254, in _run_main
    sys.exit(main(argv))
  File "/home/devcontainer/bazel/output_base/sandbox/processwrapper-sandbox/9/execroot/data_platform/bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.runfiles/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.py", line 258, in main
    lock_set = translate(args.poetry_project_file, args.poetry_lock_file)
  File "/home/devcontainer/bazel/output_base/sandbox/processwrapper-sandbox/9/execroot/data_platform/bazel-out/aarch64-opt-exec-2B5CBBC6/bin/external/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.runfiles/jvolkman_rules_pycross/pycross/private/tools/poetry_translator.py", line 133, in translate
    pinned_package_specs[pin] = parse_constraint(pin_info["version"])
TypeError: list indices must be integers or slices, not str
Target //predict:predict_lock failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.288s, Critical Path: 0.16s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

Reading the error message and reading the code it looks like the poetry_translator.py doesn't like two things:

Currently it's being passed a list instead of a string / dict
If it's passed a dict it requires the dict to contain the version key

Thanks. I haven't tried to reproduce the issue, but just looking at the error and what you've provided I'm guessing that I don't handle this syntax:
torch = [
  {markers = "platform_machine == 'aarch64'", url = "https://download.pytorch.org/whl/torch-1.12.1-cp39-cp39-manylinux2014_aarch64.whl" },
  {markers = "platform_machine == 'x86_64'", url = "https://download.pytorch.org/whl/cpu/torch-1.12.1%2Bcpu-cp39-cp39-linux_x86_64.whl" },
]

The translation step assumes the simpler format, e.g. torch = "=1.2.1". I'll have to take a closer look to see if this more complex form can be supported.

I am having the same issue with a dependency defined as:
tensorflow = [
    {version = "2.16.1", platform="linux", extras=["and-cuda"]},
    {version = "2.16.1", platform="darwin"},
]


Minor regression in Impeller tesselation benchmark

https://flutter-flutter-perf.skia.org/e/?begin=1692993908&end=1693119751&keys=X9507b4496e98127ed3f341199b2f2323&selected=commit%3D36500%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DMoto_G__4_%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253D90th_percentile_frame_rasterizer_time_millis%252Ctest%253Danimated_blur_backdrop_filter_perf__timeline_summary%252C&xbaroffset=36500
This occurred on an Engine roll with only 1 PR in it: https://github.com/flutter/engine/pull/45094

cc @bdero

Is that the right benchmark link?

It looks like it is doing better with the new fix: https://flutter-flutter-perf.skia.org/e/?begin=1693246401&end=1693275728&keys=X482a7810cfb443f67edcbab15e03f59b&selected=commit%3D36531%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Daverage_cpu_usage%252Ctest%253Ddynamic_path_tessellation_perf_ios__timeline_summary%252C&xbaroffset=36532

Nice! It looks like we were able to keep the "zero overhead" promise without ifdefs after all. :) Closing this out.


Tunercnt

@DanAustinGH - for your review.
This is to,
Track and Correct tuner instance, ceton vs. fhdhr
=> don't use fhdhr instance number, rather ceton itself.

Looks simple and clean.  Merging.
And unrelated, but after a bit of an ebay slap-fest I won a PCIe 6.  Once here I will ponder deeper on how best to handle 2 or more Ceton devices.

Looks simple and clean. Merging.

Thanks! As always, yell if issues 😄.

And unrelated, but after a bit of an ebay slap-fest I won a PCIe 6. Once here I will ponder deeper on how best to handle 2 or more Ceton devices.

Nice! I really do like mine - as you say ... 2 or more devices, also how to auto-get the tuner count. And then the slight "gotcha" of PCIe 😜

I could cheat and just 'clone' the plug-in to a ceton2 and add the 2nd device that way.  But I will look to do it right.  Same with tuner count.  The only two common values are 4 and 6.  We could default to 4 and leave it to the user to increase it if they want.  I should have the new card by Monday, and can start evaluating both feature sets then.

Sounds great!


bug: Navbar Content Overflow Issue

Describe the bug
The content in the navbar is overflowing its container, causing parts of the content to be displayed outside the intended area.
To Reproduce
Steps to reproduce the behavior:

Navigate to the page with the navbar.
Observe that some of the navbar content extends beyond the container boundaries.

Expected behavior
The navbar content should stay within its container and not overflow or extend outside of it.
Screenshots or GIFs

Info (please complete the following information):

Browser : chrome
Version : 128.0.6613.120

Additional context
I’d be happy to help address this issue if needed. Please let me know how I can assist.

@devsargam, could you please check this issue? thanks.

This is not a issue for current version please check

The latest version is not deployed

@devsargam
Is there any way to check the latest version?
So that we don't open unnecessary issues.

@NeerajReddyK I will deploy this eod

@NeerajReddyK I will deploy this eod

In [apps/web/components/Categories.tsx]

Remove: w-2/3


Older link under download button

On the page is downloaded older version (2.1.6) of Vue
https://github.com/vuejs/vuejs.org/blob/master/src/v2/guide/installation.md

Just updated! Thanks.


Transparent background

Hi, thanks for your work is there a way to left the transparent background active?

I would give tint_background_colors and highlight_ignore_patterns a go, and see if that helps at all. The colors for your background would be Normal and NormalNC.

Sorry, I didn't even give you the entire context.
I'm trying using 3 plugins together catppuccin, nvim-transparent and tint.
After all is fully load if I run the command from nvim-transparent require('transparent').toggle_transparent(true) (you can see that on the video at the bottom).
I tried as you suggested the highlight_ignore_patterns but no luck. I assume that is a fight between the 3 plugins resetting the background of the NormalNC.
The configuration:
--Bottom of my init.lua
-- Colors
vim.t_Co = 256
vim.opt.syntax = 'enable'
vim.opt.colorcolumn = '80'
vim.opt.hlsearch = true
vim.cmd.colorscheme "catppuccin-mocha"
vim.opt.termguicolors = true -- set termguicolors to enable highlight groups

-- Transparent background
vim.g.transparent_enabled = true

--- Catppuccin theme config
require("catppuccin").setup({
    transparent_background = vim.g.transparent_enabled,
    show_end_of_buffer = true, -- show the '~' characters after the end of buffers
    term_colors = true,
    integrations = {
        -- For plugins integrations (https://github.com/catppuccin/nvim#integrations)
        cmp = true,
        gitsigns = true,
        nvimtree = true,
        telescope = true,
        notify = true,
        treesitter = true,
        treesitter_context = true,
        ts_rainbow = true,
        overseer = true,
        illuminate = true,
        neotest = true,
        native_lsp = {
            enabled = true,
            virtual_text = {
                errors = { "italic" },
                hints = { "italic" },
                warnings = { "italic" },
                information = { "italic" },
            },
            underlines = {
                errors = { "underline" },
                hints = { "underline" },
                warnings = { "underline" },
                information = { "underline" },
            },
        },
        indent_blankline = {
            enabled = true,
            colored_indent_levels = true,
        },

    },
})

-- Dim inactive window
require('tint').setup({
    tint_background_colors = false,
    tint = -45, -- Darken colors, use a positive value to brighten
    saturation = 0.5, -- Saturation to preserve
    highlight_ignore_patterns⋅=⋅{⋅"WinSeparator",⋅'NormalNC',⋅'Normal'⋅},
});

-- On window enter retrigger transparent background
vim.api.nvim_create_autocmd({ "WinEnter", "WinLeave", "WinNew", "VimEnter" }, {
    pattern = { "*" },
    callback = function()
        require('transparent').toggle_transparent(true)
    end,
})

And this is a video with the behaviour:
https://user-images.githubusercontent.com/833030/215108196-0e80a971-1c16-41e6-815d-2aff4cecf30c.mp4

I believe what is happening here is that nvim-transparent functions purely off of what is returned by :highlight, looking for the groups it has listed and "ensuring" (via various randomly scheduled callbacks) that the bg highlight for them is NONE.
With the way you have your configuration setup, this is what is happening:

Load catppuccin colorscheme
Load tint, which will save off the tinted version of your color schemes current Normal color

Then when you initially split the window, I'm not sure why your autocommand above does not trigger the same thing as :TransparentEnable, as this just calls require("transparent").toggle_transparent(true) - which is exactly what your autocommand is doing.
Regardless, when you manually call :TransparentEnable, it is triggering doautocmd colorscheme, which will trigger tint to reload its "tinted" namespace and pick up the now transparent background color from catppuccin (overridden by transparent).

No idea why but ir worked 😄 thanks!!!!!!

Let me know if I need to clarify anything, but the reason why is noted in my comment above. TLDR: tint pulls from your active colorscheme to determine how to tint things, so you need to make sure your colorscheme is setup correctly (in your case by using transparent to set the bg highlight attributes to NONE) before calling tint.


Feature/issue 149 aws sdk version 3

Same as https://github.com/justeat/JustSaying/pull/210 this time targeting the develop branch.

Thank you very much, this is now the develop branch :)


Refactor gradient parametrization, remove adjoint

Replaces https://github.com/dynamiqs/dynamiqs/pull/455 (see description there) by @gautierronan. The idea to merge gradient and solver options is from @abocquet (a long time ago 😋).
Strings are not valid JAX types, so I chose a boolean flag autograd=True/False for diffrax solver as a temporary solution.

If we use autograd=True/False, I am really not in favor of this solution. This is not a binary problem whatsoever, and it hides the fact that we use a widely different gradient for diffrax and non-diffrax solvers.

Replaced by #460.


Selection bar not updating after rzSliderForceRender (fixed)

After some debugging I found the problem. rzSliderForceRender was calling thrHigh() even when not using range slider.
I guess this is a better fix than the previous one (#48)

Will it also work when rz-slider-always-show-bar is set ?
Calling thrHigh() calls updateSelectionBar() which updates selection bar.

I am using it with rz-slider-always-show-bar="true", and it works as expected. Since thrLow() calls updateSelectionBar() that's enough.


Changing the hover colour

Hi Team,
the following two items do not change the hover colour when you move the mouse over them: First Row Middle and Second Row Middle. The colour remains the same. It works for all other items.
Kind regards
Paul

Hi @erppaul would you be able to provide some more information like the configuration profile and the tested version? Currently we cannot reproduce this issue, we internally use those buttons and are changing color when hovering fine.


UserControl how to use AlertDialog?

Description
I definition a UserControl, but use AlertDialog isn't popup.

Code example to reproduce the issue:
import flet as ft
from flet import (
Column,
Container,
Text,
Row,
colors,
TextField,
AlertDialog,
)
class FletUserControl(ft.UserControl):
'''
用户控件的操作只能在用户控件中进行
'''
def init(self, height: int, width: int):
super().init()  # 不加上会提示"AttributeError: 'FletUserControl' object has no attribute '_Control__attrs'" 错误
self.height = height  # 主窗口的高
self.width = width  # 主窗口的宽
self.lv = ""
def build(self):
    dlg = AlertDialog(
        title=Text("请输入数字"), on_dismiss=lambda e: print("Dialog dismissed!")
    )  # 弹出对话框

    def open_dlg(e):
        """打开对话框"""

        self.dialog = dlg
        dlg.open = True
        self.update()
        print("执行！")

    def textbox_changed(e):
        """输入框TextFiled改变触发"""
        try:
            float(e.control.value)
        except ValueError:
            open_dlg(e)

    return Column(
        [
            Row(
                [
                    Container(
                        content=Column(
                            [
                                Text("参数设置", size=16),
                                TextField(
                                    label="额定电流",
                                    height=self.height * 0.05,
                                    on_change=textbox_changed,
                                ),  # 文本输入框
                                TextField(
                                    label="循环次数",
                                    height=self.height * 0.05,
                                    on_change=textbox_changed,
                                ),  # 文本输入框
                            ],
                        ),
                        width=self.width * 0.45,
                        height=self.height * 0.30,
                        padding=5,
                        border_radius=5,
                        bgcolor=colors.BLUE_100,)
                ]
            ),

        ]
    )

(paste your program here)

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):
Flet version (pip show flet):
(paste your output here)

Operating system:

Additional environment details:

You defined well your dialog but didn't add it to the page itself.
Try this in your open_dlg function
self.page.dialog = dlg
self.page.update()

You defined well your dialog but didn't add it to the page itself. Try this in your open_dlg function
self.page.dialog = dlg
self.page.update()

thanks, very good!
But i has some doubt the UserControl and root page has different page? I see the official example, some place use self.update(), that is only update the UserContol right?

I think so, self.update() updates UserControl only. You can get access to the main page if you pass it as a parameter like this.
class TestComponent(ft.UserControl):
	def __init__(self, page):
		super().__init__()
		self.page = page

	def build(self):
		dlg = AlertDialog()

                return #returns your control

and from the main function I can pass page
def main(page: ft.Page):
	content = TestComponent(page)
	page.add(content)

ft.app(target=main)

thanks!


Revert "Change WorkerInterface so prewarm returns a promise."

Reverts cloudflare/workerd#2863

Reverting due to sentry issues


⚠ SmartAtlantic ERDDAP has degraded performance

In ee6ffdb, SmartAtlantic ERDDAP (https://www.smartatlantic.ca/erddap/index.html) experienced degraded performance:

HTTP code: 503
Response time: 9063 ms

Resolved: SmartAtlantic ERDDAP performance has improved in a93c8dc after 20 minutes.


Implement compression of image and delta layers

I have implemented compression of delta layers using external dictionary. So now when inmem layer is flushed to the disk, we first build (train) dictionary and then compress each  wal record using this dictionary.
Right now:

zstd compression library is used
default compression level is used
Dictionary is built by training on 1024 samples
Maximal size of dictionary is limited by 128kb (zstd documentation recommends that it should be about 100kb)
Dictionary is stored at the beginning of delta_layer (just after the header) and is kept in memory when layer is loaded(can it cause OOM?)

Results are the following:
pgbench -i -s 300:

Compression
Time (sec)
Size (Gb)

none
915
16

image
815
12

image+delta
642
7.1

Please notice that ephemeral files are not compressed and their total size is 6Gb.
Certainly  pgbench generated  data is not right data set for testing compression.
We should find some real data sets.
P.S.
Some tests are not passed for this branch because of bug fixed in #1601

I have performed more detailed investigation of delta compression with dictionary.
First of all I have to notice that dictionary construction is quite expensive operation:
This is what I am seeing in profile:
  69,85%  layer flush thr  pageserver         [.] ZSTD_fillDoubleHashTable
  11,53%  layer flush thr  pageserver         [.] FASTCOVER_buildDictionary.isra.0
   5,63%  layer flush thr  libc.so.6          [.] __memset_avx2_erms
   1,94%  layer flush thr  pageserver         [.] ZSTD_compressBlock_doubleFast_dictMatchState_4
   1,73%  layer flush thr  libc.so.6          [.] __memmove_avx_unaligned_erms
   1,41%  layer flush thr  pageserver         [.] FSE_buildCTable_wksp
   1,04%  layer flush thr  pageserver         [.] FASTCOVER_ctx_init
   0,82%  layer flush thr  pageserver         [.] <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   0,50%  layer flush thr  pageserver         [.] ZSTD_encodeSequences_bmi2
   0,43%  layer flush thr  [kernel.kallsyms]  [k] copy_user_enhanced_fast_string
   0,32%  layer flush thr  pageserver         [.] HIST_countFast_wksp
   0,23%  layer flush thr  pageserver         [.] ZSTD_compressBegin_internal

And so time of flushing data greatly depends on number of samples (wal records) and which dictionary is learned.
I have tries several values for number of samples: 128, 1024, 128*1024.
All experiments are performed with pgbench -s 300. I first initialize database, then wait  until compaction is finished (it takes a lot of time), inspect size of image and delta layers, then run standard pgbench iteration during 1000 seconds and once again wait completion of compaction and check size of layer files.
Results are the following:

samples=128
init: 382.02 s
compaction:  18 min
delta layers: 775Mb
image layers: 388Mb

update: (1000 sec)
tps = 1342.741063
compaction:   53 min
delta layers: 2864Mb
image layers: 853Mb

samples=128*1024
init: 338.68 s
compaction:   36 min
delta layers: 503Mb
image layers: 388Mb

samples=1024
init:
delta layers: 560Mb
image layers: 388Mb

update: (1000 sec)
tps = 1212
delta layers: 2342Mb
image layers: 850Mb
(sorry, not for all items  I have measured time)

So compression allows to save a lot of space (~10x times for synthetic pgbench data) but is extremely slow (~100x more time for compaction).

I have performed more detailed investigation of delta compression with dictionary.
First of all I have to notice that dictionary construction is quite expensive operation:
This is what I am seeing in profile:

69,85%  layer flush thr  pageserver         [.] ZSTD_fillDoubleHashTable

This function is involved with loading the dictionary, not with building it. You can avoid that by creating a Compressor object with the dictionary once, and reusing it. I added a commit to this PR to do that, please check how the speed looks like now.

I have performed more detailed investigation of delta compression with dictionary.
First of all I have to notice that dictionary construction is quite expensive operation:
This is what I am seeing in profile:

69,85%  layer flush thr  pageserver         [.] ZSTD_fillDoubleHashTable

This function is involved with loading the dictionary, not with building it. You can avoid that by creating a Compressor object with the dictionary once, and reusing it. I added a commit to this PR to do that, please check how the speed looks like now.

O, thank you!
I realized yesterday from FlameGraph profile that ZSTD_fillDoubleHashTable is used not during dictionary building but in compression itself. But I didn't think how it is possible to avoid it.
Now the picture is completely different - compaction time is almost the same as for main branch.
It is strange, but with compression level 1 (rather than 0 which stands for default compression level, which is as I know is 3),
compression ration for images is even better:
delta layer size:  561Mb
image layer size: 225Mb (vs. 388Mb before)
So delta compression really seems to be very useful and there is not compromise with performance.

Cool. Next things to investigate:
How much of the benefit do you get with a smaller, 8 kB dictionary? That would be handy, because it would fit in a single page.
How fast is the decompression?
Similarly to the Compressor, you could construct a Decompressor once and reuse it. That's a little harder than with the Compressor, though, because you need to a lock or something to deal with multi-threaded use, and the Compressor objects would take some memory for each layer
I think each compressed block begins with a frame header, which in turn begins with a 4-byte magic constant (see https://github.com/facebook/zstd/blob/dev/doc/zstd_compression_format.md). That's wasteful for small items like WAL records. Could we use the zstd block-level  API, is that exposed in the rust library? Or at least just strip out the 4-byte constant.

With maximal dictionary size 128 kb, size of one prepared context is 630kb,
So it is about 5 times larger than original context.
And average time of context creation is 0.6msec.
With 8kb dictionary size, size of prepared context is 180kb  and creation time 0.1msec.
Storage size:
     delta layers:     560Mb
     image layers:   224Mb

So results are exactly the same as for 128kb context.
But... It is on pgbench data where all changes are the same and it is enough to inspect few records to build perfect dictionary.
So I am not sure what conclusion should we made based on this results?
Looks like it make sense to reduce maximal context size (may be to 64kb or less) and store prepared context (as far as it's size seems to be not proportional to size of dictionary, it has no sense to try to make dictionary size as small as possible).
What is your opionion?

Below are results of comparison prepared vs. non prepared dictionary of different size.
Test (default configuration):
create table t as select generate_series(1,10000000) as pk,(random()*10)::bigint as r10,(random()*100)::bigint as r100,(random()*1000)::bigint as r1000,(random()*10000)::bigint as r10000;
select sum(r100) from t;

dictionary
size (Mb)
insert (sec)
select (sec)

8k
912
26,191
4,481

64k
1076
27,189
4,873

8k prepared
964
21,765
2,847

64k prepared
1094
34,670
2,858

So for some reasons size of delta layers is even smaller for smaller dictionary size.
And preparing of content has high influence on performance especially for selects.
Prepared dictionary is used only for page reconstruction (which is most performance critical,
because otherwise it is constructed for each get_page request).
For reconstruction I failed to make iterator to refer shared dictionary.
So I have to store raw dictionary as well as prepared.
It has almost no influence on performance (since iterator is created once for the whole layers)
and memory footprint (because prepared dictionary is several times larger).
But it is not nice.
I will be pleased if somebody more familiar with Rust can make it work:
Branch:
https://github.com/neondatabase/neon/pull/new/layer_compression_with_prepared_dictionary
Not working version is commented at lines  842-849 of delta_layer.rs

Profile of select workload (decompress)

I added a commit to remove the max limit on decompressed size. Please take a look.

I added a commit to remove the max limit on decompressed size. Please take a look.

Thank you for fixing it. I also thought about eliminating of this limitation, but for some reasons I decided that using experimental features is not acceptable.

I added a commit to remove the max limit on decompressed size. Please take a look.

Thank you for fixing it. I also thought about eliminating of this limitation, but for some reasons I decided that using experimental features is not acceptable.

I did some more refactoring, added comments.
I also did some experiments with skipping the 4-byte "zstd magic" header, but ran into a problem. The upper_bound function doesn't work without the 4-byte header; it assumes that the 4-byte header is present. Looking at the zstd code, I think that's just an oversight. Some functions provide a version that allows specifying the magicless flag, like ZSTD_getFrameHeader_advanced vs ZSTD_getFrameHeader. But not ZSTD_decompressBound. Another approach would be to make a guess at the buffer size, try to decompress, and increase the buffer it if it fails. But the rust zstd wrapper doesn't expose the zstd error code that would allow us to distinguish "destination buffer too small" errors from others. Another approach would be to use the streaming API instead of the bulk API. Or strip out the magic header ourselves, and put it back before decompressing. But I'm conceding defeat on this for now; let's just accept the 4 bytes overhead for now and revisit later.
TODO:

bump up STORAGE_FORMAT_VERSION, since this isn't backwards-compatible
consider making the dictionary smaller and storing it in the first header block

Overall, I'm pretty happy about this now. @knizhnik, can you review the latest version, please. I'm hoping that we could finish those TODOs, rebase, and push this tomorrow (Thursday)

I also did some experiments with skipping the 4-byte "zstd magic" header, but ran into a problem.

As I said, I am against such "hackish" optimizations at least at this stage. But my original intention to address buffer size limit was to prohibit compression of such larger buffers at all. May be I am missing something, but  there should not be  any "popular" wal records stored in repository with size > 2page_size.Yes, walrecordcan contain up to 32 blocks, so COPY should produce walrecords with 328kb FPI blocks. But we do not store such records directly in pageserver and rather split them in individual images.
Another case is commit record with many subtransactions.But once again: we store it as own  ClogSetCommitted records.
So there is seems to be the only case of arbitrary larger wal record: custom logical message. But it seems to be exotic and so if we refuse to compress records larger than i.e. 64kb, it should not have any impact on performance and storage size. The only problem is how to mark record as not compressed.Certainly the most straightforward solution is to reserve one bit for it (as for will-init). Alternatively we can can assume that any object with size > 64kb is not compressed. The problem is that some block with size < 64Kb can be compressed to > 64Kb (if it contains random non-compressable data).

consider making the dictionary smaller and storing it in the first header block
SHould we just make it 8188 (BLCKSZ-4) ?

@knizhnik, can you review the latest version, please.

I agree with most of your changes. The only question is training: in my version records used for training are pinned in memory to avoid double reads. As far as maximal  size of data for training is limited by not so larger value (10Mb), it should not take a lot of memory. But do not need to read data twice. Yes, rereading ~10Mb  also should not cause any influence on performance and most likely this data is still in cache. And your implementation is more elegant. But still...

On 12/05/2022 08:40, Konstantin Knizhnik wrote:

I also did some experiments with skipping the 4-byte "zstd magic"
header, but ran into a problem.

As I said, I am against such "hackish" optimizations at least at this
stage. But my original intention to address buffer size limit was to
prohibit compression of such larger buffers at all. May be I am missing
something, but there should not be any "popular" wal records stored in
repository with size > 2/page_size.Yes, walrecordcan contain up to 32
blocks, so COPY should produce walrecords with 32/8kb FPI blocks. But we
do not store such records directly in pageserver and rather split them
in individual images.
Another case is commit record with many subtransactions.But once again:
we store it as own ClogSetCommitted records.

Another case is the "metadata" keys we store to hold list of relations
and such. They can grow arbitrarily large. In the long run, we should
perhaps split them up into multiple keys if they do..

So there is seems to be the only case of arbitrary larger wal record:
custom logical message. But it seems to be exotic and so if we refuse to
compress records larger than i.e. 64kb, it should not have any impact on
performance and storage size. The only problem is how to mark record as
not compressed.Certainly the most straightforward solution is to reserve
one bit for it (as for will-init).

I already did that actually. There's now a compressed-bit in addition to
the will-init bit.

consider making the dictionary smaller and storing it in the first
header block
SHould we just make it 8188 (BLCKSZ-4) ?

Works for me. It would be nice to do some experiments on how the
dictionary size affects compression ratio with different inputs. But it
would also be nice to just get this in :-). I added an explicit
"dictionary_offset" field to the header, so we can change that later too.

Heikki

I think that pgbench with its artificial data generator and larger fillers and even my compression test with randomly distributed values with different modulo are both very specific workloads, producing very uniform WAL stream. It will be nice to test compression on real data. But right now I decided to measure effect of compression on regression tests (in this case workload is very very different). Results are slightly confusing:

dictionary size
level
delta layer size

none
-
397549568

256
1
200286208

1024
1
204038144

4096
1
222666752

8188
1
222535680

8188
3
234700800

1048572
3
221323264

So looks like training in this case has only negative effect. At least training in first 1024 wal records.
Just as experiment I tried to do random sampling: training on random set of wal records:
        let mut keys: Vec<(&Key, &VecMap<Lsn, u64>)> = inner.index.iter().collect();

		keys.shuffle(&mut thread_rng());
		let mut n_samples = 0;
        for (key, vec_map) in keys.iter() {
            let key = **key;
            // Write all page versions
            for (lsn, pos) in vec_map.as_slice() {
                cursor.read_blob_into_buf(*pos, &mut buf)?;
                let val = Value::des(&buf)?;
                delta_layer_writer.put_value(key, *lsn, val)?;
            }
			n_samples += 1;
			if n_samples == config::ZSTD_MAX_SAMPLES {
				break;
			}
        }
		delta_layer_writer.finish_training();
        keys.sort_by_key(|k| k.0);

        for (key, vec_map) in keys.iter() {
            let key = **key;
            // Write all page versions
            for (lsn, pos) in vec_map.as_slice() {
                cursor.read_blob_into_buf(*pos, &mut buf)?;
                let val = Value::des(&buf)?;
                delta_layer_writer.put_value(key, *lsn, val)?;
            }
        }

It gives much better effect: 167321600 with dictionary size 8188.
So what do you think about random sampling?
Not so clear how to implement it fir compaction.

The same experiments with test_compression (random key distribution):

sampling
dictionary size
level
delta layers size

none
0
-
1888854016

random
8188
1
737558528

random
8188
3
735182848

random
256
1
1105682432

head
8188
1
886824960

head
256
1
1058988032

head
128kb
1
789184512

So now results are more predictable: larger compression level and dictionary size cause better compression ratio.
But  even in this case (when just one table is populated), random sampling works better than taking N first records.

@hlinnaka  I wonder what are your plans concerning this PR?
You said that you want to provide backward compatibility with previous storage format.
As far as I understand your trick with dictionary_offset in delta layer header does half of the work: in old format if will be zero and so dictionary will not be loaded.
But then we should somehow deal with BLOB_COMPRESSED flag.
It is defined as 1 and WILL_INIT as 2. In old version WILL_INIT was 1.
I wonder if we can set BLOB_COMPESSED to 1 << 31 an just change BlobRef class to make references backward compatible?
Certainly it is needed only if we really want to preserve backward compatibility with old format. I am not sure if it is critical (do we have repositories which we want to preserve?)

pgbench -i -s 1000 returns error Destination buffer is too small
Investigating...

I wonder why MAX_VALUE is disk_btree.rs is 0x007f_ffff_ffff and not 0x00ff_ffff_ffff ?
I try to make compression implementation backward compatible and so move  BLOB_COMPRESSED to the last bit (8*5 - 1).
But I got assertion that appended value is too large.
Please also notice, that using two bits from 40 we limit maximal layer size by 256Mb.
It contradicts with you intention to increase have image layers ~1Gb.
And if we increase VALUE_SZ to 6 bytes, then we in any case loose backward compatibility.


sync to live

Docs Build status updates of commit 4f6858e:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/windows-iotcore-docs, working directory: W:\2ctj-s, target branch: live, target branch commit: 1f3760a4f03c5f7713023bfa6bad508c99103a54, source commit: 4f6858e2bdc92e4256e385e5f9861578fadea939.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 754515d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/TOC.md
:white_check_mark:Succeeded

windows-iotcore/learn-about-hardware/HardwareCompatList.md
:white_check_mark:Succeeded

windows-iotcore/learn-about-hardware/iotnxp.md
:white_check_mark:Succeeded

windows-iotcore/windows-iot-core.md
:white_check_mark:Succeeded

windows-iotcore/windows-iot-enterprise.md
:white_check_mark:Succeeded

windows-iotcore/windows-iot.md
:white_check_mark:Succeeded

windows-iotcore/windows-server.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Integration Test - Release - 2018/08/29 07:42:39

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest3 : Thanks for your contribution! The author, @v-caxian, has been notified to review your proposed change.


Is sliding-sync using the same DB as synapse or a new one?

I've created postgres-data DB for my synapse. And I wonder if I should create a new one for sliding-sync or sharing the existing one.

Nvm, I think it's a new DB and I succeed.


fix: match version only in project definition

Description
Update the regular version regex to only match version declarations inside the project function definition.
Related Issue
Fixes #15.
How Has This Been Tested?
Added new test cases and updated the existing ones.
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)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[ ] If my change introduces a breaking change, I have added a ! after the type/scope in the title (see the Conventional Commits standard).

:tada: This PR is included in version 1.0.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


add to favorite

Description
Add a feature to add a template in favorite/wishlist of user
Screenshots
No response

please, assign it to me

@muhammadgalhoum
What's the update?

I'm already about to finish solving this problem and will do a PR ASAP @singhmansi25

in this issue i want a feature to add templates in wishlist

Ok, Please put level 3 on it
Thanks in advanced


rewrite multiple classes with annotations

rewrite 28 classes in syntax/lang/.. and syntax/action/.. with annotations and adjust multiple .ast files

@aykborstelmann all your requests should be fixed, mvn clean install now runs without errors

I just did the squashing and merging for u 👍🏻


Update documentation of SharedDataMiddleware

I was reading the documentation of the middleware.SharedDataMiddleware class and I noticed that the example code snippet is not reflecting the explanation.

Thank you.


fix unescaped '/' in URI

hashes with "/" are wrongfully cut into parts.
This fix clues the substrings back together. It has two requirements though that we need confirmation by @fonsp though:

If the "payload" exists, it is always in parts[end]
the notebookhash always ends with "=" AND no other sub-string (split by '/') of the URI ends with "="

Addresses #46 #42 #45, but instead of changing server configuration as #46, this fixes it within PlutoSliderServer - #46 indicates an issue with "+" as well - but we could not replicate it.
fixed together with @llips

Thanks! Re: #45, I tried adding this patch on top of the static-export-1 branch and that 404 problem still appears.
It did make me realise that the URI's were being escaped twice though, which was the problem over there.
That is, for notebook hash 7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs=
encodeURIComponent("7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs=")
"7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs%3D"

and
encodeURIComponent(encodeURIComponent("7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs="))
"7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs%253D"

which corresponds to Deno needing
http://localhost:8000/bondconnections/7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs%3D
whereas the Python server needed
http://localhost:8000/bondconnections/7uehaeBoJorFiesT4uKI7Rl3bFJcsQwdILATmeaacfs%253D
How to proceed, though, I'm not sure.
Is there simply a way to create hashes which doesn't use special characters that need escaping in a URL?
E.g. is it possible to just use the filename of the notebook instead of a hash of the contents?

Thanks for looking into this! I'll get back to you very soon, January was a bit too busy for me 😅

Hey @behinger ! Thanks for starting this topic! Let me say that it is awesome that you are using PlutoSliderServer, that you were able to fork and fix this on your own, and that you opened a PR to share your fix with the community!!
I think the solution in this PR does not catch all cases, and we still need to think about the problems with URI escaping the other character: + (and = for padding). I started working on the underlying problem in
I worked on this today, see https://github.com/JuliaPluto/PlutoSliderServer.jl/pull/57

Thanks for the warm words! You can close this PR then.
@llips noticed a similar problem when using precompute slider server; we fixed it by providing our own Pluto.jl frontend code: https://github.com/llips/Pluto.jl/commit/e1c8a52211d90d2001f923bd0f9dcafdb2c7392b (the option to do so was not very visible in any documentation, but I understand it is a not-ready-yet-PR & a lot of work. kudos!)
I guess this is the right time to mention this, if you need a more detailed report we can do that too.
Happy to share the outcomes of our work, we (mostly Luis) used the precompute PR successfully; needed some further tweaking in some details. Hope to be able to share it soon

Hey @behinger !
I would love any feedback you can give about using the precompute PR! My main question is: what is it like to develop notebooks that will be precomputed? Do you often write notebooks with too many possibilities? How do you know about this, and how do you solve it?
Would you recommend others to use it? Any tips you would give to people who want to start using it?
Thanks again! -fons

Fixed by #57


Do we need hearing info?

There are spots on the form for hearing information, just like in simpmotion, but the LHI interview doesn't have it.

In the LHI/HotDocs form, the hearing information on FOC 50 is blank. No need to collect this.

Sounds good! I'll close this issue; if it's something we want to add post-MVP we can re-open. I'm not sure how useful it'd be though.


MINOR: fix integration tests

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Starting a few days ago, Kafka integration tests started to fail, with the error "Zookeeper node failed to start". The reason is kafka-run-class.sh can't find java in the PATH. Further investigation shows it is caused by a breaking change in openjdk:8 docker image: https://github.com/docker-library/openjdk/commit/3eb0351b208d739fac35345c85e3c6237c2114ec
The image no longer installs a symlink of java in standard path /usr/bin, but uses ENV directive to specify custom PATH. On the other hand, ducktape use Paramiko to SSH to other docker instances to start ZK, which doesn't source any bashrc, thus not able to find the java.
This PR fixes it by using ForceCommand directive in sshd_config so that the environment variable is set even for Paramiko sessions.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Running integration tests.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@cmccabe could you take a look? (found you because you reviewed my PRs for integration tests before, I apologize if you are not the best person for it)

@harshach

@harshach added some comments, please review. Thanks.

Abandon since the issue was solved by https://github.com/apache/kafka/commit/677713baf3c47add13628ed498ffa11a34d4a5f4


Add input function for training and testing (#9617)

Add input function for training and testing

Estimator is decoupled from Scikit Learn interface by moving into separate class SKCompat. Arguments x, y and batch_size are only available in the SKCompat class, Estimator will only accept input_fn

remove extra comma

Can one of the admins verify this patch?

This is merging a commit from another branch on which the CLA was signed.  Testing and merging.

@tensorflow-jenkins test this please