Pipenv doesn't propagate packages like pip

Issue description
I'm trying to install numpy using pipenv (rather than using the nix package), and I'm getting the following error:
Creating a Pipfile for this project…
Installing numpy…
⠧
Error:  An error occurred while installing numpy!
/bin/sh: /bin/pip: No such file or directory

Full stack trace:
Creating a virtualenv for this project…
⠋Using base prefix '/nix/store/y95dd7cmw2xlf6hvg2j93b227pblpaaq-python3-3.6.4'
New python executable in /home/sidharth/.local/share/virtualenvs/numpy-test-s0o2G1-0/bin/python3.6m
Also creating executable in /home/sidharth/.local/share/virtualenvs/numpy-test-s0o2G1-0/bin/python
Installing setuptools, pip, wheel...
  Complete output from command /home/sidharth/.loca...2G1-0/bin/python3.6m - setuptools pip wheel:
  Collecting setuptools
Exception:
Traceback (most recent call last):
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/commands/install.py", line 324, in run
    requirement_set.prepare_files(finder)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/req/req_set.py", line 380, in prepare_files
    ignore_dependencies=self.ignore_dependencies))
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/req/req_set.py", line 620, in _prepare_file
    session=self.session, hashes=hashes)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 821, in unpack_url
    hashes=hashes
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 659, in unpack_http_url
    hashes)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 853, in _download_http_url
    stream=True,
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/requests/sessions.py", line 488, in get
    return self.request('GET', url, **kwargs)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 386, in request
    return super(PipSession, self).request(method, url, *args, **kwargs)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/requests/sessions.py", line 475, in request
    resp = self.send(prep, **send_kwargs)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/requests/sessions.py", line 596, in send
    r = adapter.send(request, **kwargs)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/cachecontrol/adapter.py", line 37, in send
    cached_response = self.controller.cached_request(request)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/cachecontrol/controller.py", line 111, in cached_request
    resp = self.serializer.loads(request, cache_data)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/cachecontrol/serialize.py", line 114, in loads
    return getattr(self, "_loads_v{0}".format(ver))(request, data)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv_support/pip-9.0.1-py2.py3-none-any.whl/pip/_vendor/cachecontrol/serialize.py", line 176, in _loads_v2
    cached = json.loads(zlib.decompress(data).decode("utf8"))
zlib.error: Error -3 while decompressing data: incorrect data check
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/bin/.virtualenv-wrapped", line 12, in <module>
    sys.exit(main())
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv.py", line 713, in main
    symlink=options.symlink)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv.py", line 945, in create_environment
    download=download,
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv.py", line 901, in install_wheel
    call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/nix/store/ivhiacy4kzk3pn0rkzm8v6358xrdmbaz-python3.6-virtualenv-15.1.0/lib/python3.6/site-packages/virtualenv.py", line 797, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /home/sidharth/.loca...2G1-0/bin/python3.6m - setuptools pip wheel failed with error code 2

Steps to reproduce
nix-shell -p pipenv
pipenv install numpy

Technical details

system: "x86_64-linux"
host os: Linux 4.9.73, NixOS, 18.03pre124015.f59a0f7f1a6 (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.16
channels(sidharth): ""
channels(root): "nixos-18.03pre124015.f59a0f7f1a6"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

@das-g I don't think I got that error! Anyway, I figured out how to make pipenv install wheels instead of building from source, which solved all my problems and also makes installing packages much faster.
I wrote a blog post on how to do this: https://sid-kap.github.io/posts/2018-03-08-nix-pipenv.html.

See https://github.com/NixOS/nixpkgs/pull/38655#issuecomment-398814646

@domenkozar thanks for the update! I've been pretty happy with my FHS env setup, but I'll try in a normal nix-shell to see if the new version fixes the problems I was having.

@sid-kap do you have any updates on this issue?

@baracoder I don't have this problem anymore

then let's mark this resolved!


[Doubt] Can you kindly explain what chunk_length dictates?

How good or bad the output is with change of this attribute? What is the unit (frames, seconds)?
In the default setting of chunk_length=30, I can find a lot of text missing.

hi! the unit is seconds. there should be some warnings printed out in this case - could you give some more specific examples?
btw - I've noticed that this issue can be specific to an audio/video instance and a particular Whisper model. without knowing more info, I'd recommend trying a different one and seeing if the same issue occurs.

Hi, just wanted to check in on this. Any luck with other model sizes/any other questions? Otherwise, I'll close this for now.


Radio Labels should size automatically to RadioLabels Height

The dimensions of RadioGroup from ViewFactory should have Height = 2 (number of example options created).
If changing the RadioLabels and Height is absolute and Height == Number of previous Labels.  Also increase/decrease Height to the new number of labels.

Ah this already the behaviour without any pre check:
https://github.com/gui-cs/Terminal.Gui/blob/7b93f443fe68aa2c713f27486e3cae3184bf3ac0/Terminal.Gui/Views/RadioGroup.cs#L166-L174


Add bk7231 to alios.

Add bk7231 to alios

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.junlong.zhou seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Screencast seems to refer to old version of cci command: Cumulus2

The README refers to this video:
https://asciinema.org/a/91555
The video refers to an obsolete command called cumulusci2.

@jlantz Are your webinar recordings available yet? Should we replace the video link in the readme with those?


Update cli.py

Remove duplicate disable.configure
Change alias for update.configure to "up" to avoid conflict with alias "u" for uninstall.configure

I would prefer keeping 'u' for 'update' and do not have any alias for 'uninstall'
I tend to think that updating is a command you use more often and a short alias could save some time.
THnaks


[Target path is not writable] issue in file.cc

after choosing a vehicle (e.g., mkz_example) in dreamview, I found that some files in modules/calibration/data/mkz_example are copied to destinations defined in 'vehicle_data.pb.txt'.
But, it seems that it fails to copy files to some specific folders such as /home/tmp/ros/share/velodyne/....
can you check this issue?
the followings are error messages I got when run dreamview.
E1211 13:58:57.014475  9172 file.cc:117] Target path is not writable: /home/tmp/ros/share/velodyne_pointcloud/params/velodyne64_height.yaml
E1211 13:58:57.014536  9172 file.cc:117] Target path is not writable: /home/tmp/ros/share/velodyne_pointcloud/params/64E_S3_calibration_example.yaml
E1211 13:58:57.014585  9172 file.cc:117] Target path is not writable: /home/tmp/ros/share/velodyne_pointcloud/params/velodyne64_novatel_extrinsics_example.yaml
E1211 13:58:57.015326  9172 file.cc:117] Target path is not writable: /home/tmp/ros/share/usb_cam/launch/start_leopard.launch
E1211 13:58:57.015368  9172 file.cc:117] Target path is not writable: /home/tmp/ros/share/usb_cam/launch/start_obstacle_camera.launch
nohup: appending output to 'nohup.out'

Please try it again in the latest code and feel free to reopen this issue if it happens again. Thanks.


Kotlin 2.0.0 support :)

Currently, K2 intellij plugin is in alpha, so it is still isn't "primary" version everyone will migrate to. This issue was created for discussion about supporting Kotlin 2.X.X and Kotlin 1.X.X at the same time, or rather migrate to K2.
My ulterior motive: k2 supoprt when? :)

Hi!
As I mentioned in this PR, the migration to K2 is going to be performed with replaсing KSP by compiler plugins, so it takes more time

Bump? Maybe it would be good to consider including KSP support just for one more version? Since Kotlin 2.0.0 is stable now

We decided not to do so, because it would just add more time for the work that will be dropped anyway. Kotlin 2.0 support will come with the next non-bugfix release

Hi!
We started an KMP project and we are using compose for both iOS/android. This almost eliminates all code changes on iOS side. We had to upgraded project to Kotlin 2.0 because we are using multiple modules in our project. In versions lower than 2.0 resources weren't included correctly in build properly.
We need grpc and this library seems like a perfect fit. Is there any estimate when could this be done/released? Any update on this (even inaccurate) would be of great help to us in terms of project planing.
Thx!

Hi, @dpopic-etranet ! 2.0 may be supported in a couple of weeks.

We need grpc and this library seems like a perfect fit.

I just want to mention, that we don't support gRPC yet

I really need this for 2.0.0. Sharing same interface between projects is insanely convenient. But not supporting 2.0.0 makes it impractical to use

Hello. When will this merge be released? Can't wait to use it.

Unfortunately we have had to drop kotlinx-rpc for three reasons:

It does not support Kotlin 2.0 at the latest release
It does not provide JS or WASM targeting, precluding easy use in a common source set which ultimately is used by JS or WASM
At the latest Kotlin, KotlinX RPC has a module called "core" which causes issues with all other modules called "core"

@sgammon can you please explain the issue with the core module? In published artifacts it is called kotlinx-rpc-core

@sgammon thank you anyway for trying it out and providing feedback. It's sad to hear you have to drop it now, but I hope you may give it a change when it is more stable.
About the other issues: 2.0 is coming next week, and Wasm is planned right after. JS is already supported for the clients

@Mr3zee as explained here

@sgammon thank you anyway for trying it out and providing feedback. It's sad to hear you have to drop it now, but I hope you may give it a chance when it is more stable.
About the other issues: 2.0 is coming next week, and Wasm is planned right after. JS is already supported for the clients

Great!

gRPC is WIP, no estimates now, it is a huge topic
I'll make an issue for it


upgrade.RunWithContext fails if task is canceled through context, rather than proceeding in the background

Output of helm version:  (from go.mod) helm.sh/helm/v3 v3.13.3
Output of kubectl version: (from go.mod) k8s.io/cli-runtime v0.29.0
Cloud Provider/Platform (AKS, GKE, Minikube etc.): Minikube
Using the helm go sdk, calling install.RunWithContext
with a context and then cancelling it, the install proceeds in the background, as documented.
However, calling upgrade.RunWithContext with a context and then cancelling it, the upgrade will proceed in the background, but warn "warning: Upgrade "my-test-deployment" failed: context canceled "
The output of helm status my-test-deployment --debug -n hmd-orc is:
NAME: my-test-deployment
LAST DEPLOYED: Wed Mar 13 17:53:15 2024
NAMESPACE: hmd-orc
STATUS: failed
REVISION: 3
TEST SUITE: None

However, the k8s pod, deployment, replicaset, all seem healthy, and everything appears to function correctly after the update. Only the helm release status shows as failed.

This seems not a bug to me, maybe the request of updating resources already been sent to k8s, so the pod become healthy after cancel helm RunWithContext is reasonable.
The canceled context will stop wait of helm, so helm cannot assume the upgrade is success or failed. It can only return the context canceled error.

Although the docs say this, I believe an error is returned with install.RunWithContext as well.
As it should be.
https://github.com/helm/helm/blob/release-3.15/pkg/action/install.go#L415


create docker compose file

Write docker file compose with all dependencies to upload pREST server - simplify and document use for new collaborators

based on the code (development, can be via go run and source mount volume)
based on the docker image (production)

related #388

@avelino we have a docker-compose.yml already so what's the point here?
IMHO for a better user experience we should create a separate repository with a complete demo... something like a tutorial.

@fabriziomello compose was not working (so I opened this issue), correction in the PR mentioned above


feat: process push notifications received outside CIO SDK

[DO NOT MERGE] - THIS PR IS FOR TESTING THE FEATURE ONLY AND WILL BE CLOSED AFTER TESTING
Feature PR: https://github.com/customerio/customerio-reactnative/pull/117
Parent Issue: https://github.com/customerio/issues/issues/9591
Changes

Integrated RNFirebase for Android only, (iOS is incomplete and may not build)
Received CIO notifications using RNFirebase and processed them using methods exposed in feature PR

QA Instructions
Issue Background
Some customers reported their Customer.io push notifications do not work if they have RNFirebase and/or any other push notification service included in their react native app. The problem was only reported for Android apps using our react native SDK.
In this issue, we exposed some methods in our RN SDK so customers can process push notifications from callbacks received using implementation from RNFirebase. This PR in AmiApp integrates RNFirebase and uses exposed method correctly to make all Customer.io push notifications work with it.
Test Build

Install PR.49 builds for testing
The PR has RNFirebase integrated and working for Android only
iOS builds may fail on this branch, but since the PR doesn't make any change to iOS code, it doesn't need to be tested
Test push notifications on Android should not be affected

Areas to Test
This affects all kinds of push notifications on RN SDK (Android apps) with any other push notification service integrated. Here is a list of few areas that we can test to assure it doesn't change any behavior and works as expected:

Simple push notifications with app in Foreground/Background/Killed state when notification is received
Rich push notifications with app in Foreground/Background/Killed state when notification is received
Push notifications using Custom Payload with app in Foreground/Background/Killed state when notification is received
Metrics for all push notifications should be unaffected

Known Issues
Due to limitation in RNFirebase, push notifications sent using our Rich Push Editor may not work when app is in Background/Killed state as they do not include priority in them. We have some discussions going on for this to think about adding priority as a feature for Rich Push Editor. But right now, this can only be added using Custom Payload. The desired json can be built using following steps:

Create rich push notification using editor
Once complete, click the Preview Payload button to copy final json
Switch to Custom Payload and paste the one copied from preview
Modify json object to support priority as mentioned in FCM docs

A sample json for rich push would look like:
{
  "message": {
    "android": {
      "notification": {
        "priority": "high"
      }
    },
    "data": {
      "title": "Title goes here",
      "body": "Body goes here",
      "link": "link://app",
      "image": "link://image"
    }
  }
}

Pull request title looks good 👍!
If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.1.0. This pull request is not a breaking change.
All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!
This pull request title should be in this format:
<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:
<type>!: short description of breaking change

where <type> is one of the following:

feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

docs: - This pull request is making documentation changes, only.

refactor: - A change was made that doesn't fix a bug or add a feature.

test: - Adds missing tests or fixes broken tests.

style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

perf: - Changes improve performance of the code.

build: - Changes to the build system (maven, npm, gulp, etc)

ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

chore: - Other changes to project that don't modify source code or test files.

revert: - Reverts a previous commit that was made.

Examples:
feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter

Need more examples? Want to learn more about this format? Check out the official docs.
Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

Closing this as feature has been merged and the PR is no longer needed


Sometimes all dependencies are considered new

In some situations, a Dependabot PR fails on security vulnerabilities in preexisting. In such a case, the dependency-review-action prints the following: "The number of snapshots compared for the base SHA (0) and the head SHA (1) do not match. You may see unexpected additions in the diff.". For an example PR, see: yonadev/yona-server#1301
This is the output of the action:
Run<EMAIL_ADDRESS>  with:
    comment-summary-in-pr: on-failure
    allow-ghsas: GHSA-4[2](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:2)65-ccf5-phj5
    repo-token: ***
    retry-on-snapshot-warnings: false
    retry-on-snapshot-warnings-timeout: 120
    warn-only: false
The number of snapshots compared for the base SHA (0) and the head SHA (1) do not match. You may see unexpected additions in the diff.
Dependency review did not detect any denied packages
Vulnerabilities
  settings.gradle »<EMAIL_ADDRESS>– Bouncy Castle For Java LDAP injection vulnerability (moderate severity)
    ↪ https://github.com/advisories/GHSA-hr8g-6v94-x4m9
  settings.gradle » org.bouncycastle:bcprov-jdk18on@1.7[3](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:3) – Bouncy Castle For Java LDAP injection vulnerability (moderate severity)
    ↪ https://github.com/advisories/GHSA-hr8g-6v9[4](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:4)-x4m9
  Error: Dependency review detected vulnerable packages.
Licenses
Denied
Dependency Changes
  File: settings.gradle
  +<EMAIL_ADDRESS>  + org.bouncycastle:bcprov-jdk1[5](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:5)on@1.[7](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:7)0
  +<EMAIL_ADDRESS>  + ch.qos.logback:logback-classic@1.4.[14](https://github.com/yonadev/yona-server/actions/runs/8031443103/job/21939907849?pr=1301#step:2:15)
  +<EMAIL_ADDRESS>:
:
Dependency list goes on and on and on and lists all dependencies of the project.

Third time is a charm...

The action failed on the initial PR created by Dependabot
To try and make it pass, I did a @dependabot recreate, but it failed again. Then I logged this issue
I committed a change to the workflow to give write permission on PRs. Then it passed.

I faced the same issue on other PRs, where it also disappeared for some reason, so it occurs more often. Please look into it.

It might have been related to the way the workflow was set up:
  dependency-submission:
    name: Publish dependencies
    needs:
      - build-check-publish
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout src repo
        uses: actions/checkout@v4
      - name: Set up JDK
        uses<EMAIL_ADDRESS>        with:
          distribution: 'temurin'
          java-version: 17
      - name: Publish Gradle dependencies
        uses: gradle/actions/dependency-submission@v3

  review-dependencies:
    name: Review dependencies
    needs:
      - dependency-submission
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - name: Review dependencies
        uses<EMAIL_ADDRESS>        with:
          comment-summary-in-pr: on-failure

The review-dependencies job defines a needs for the submission job, so the data should be available, but it might be that something went wrong in that area.
I've now combined the two:
  dependency-submission-and-review:
    name: Publish and review dependencies
    needs:
      - build-check-publish
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - name: Checkout src repo
        uses: actions/checkout@v4
      - name: Set up JDK
        uses<EMAIL_ADDRESS>        with:
          distribution: 'temurin'
          java-version: 17
      - name: Publish Gradle dependencies
        uses: gradle/actions/dependency-submission@v3
      - name: Review dependencies
        uses<EMAIL_ADDRESS>        with:
          comment-summary-in-pr: on-failure

Let's see whether it still occasionally fails.

I stumbled upon the same issue, sometimes it find nothing:

The number of snapshots compared for the base SHA (0) and the head SHA (1) do not match. You may see unexpected additions in the diff.

Did not try both step in the same job but since the documented way works most of the time..

👋 this is a known quirk of the behavior of Dependency Review—if we don't have the same number of snapshots on each side of the comparison then we can report a lot of misleading additions/removals.
Putting everything in the same job (with dependency-review-action last) is the ideal solution, but you can also set retry-on-snapshot-warnings to true and that should help to prevent this from happening. If you go that route, you may also need to tune retry-on-snapshot-warnings-timeout to be able to accommodate all the related steps.
I'll close this for now, but feel free to let us know again if you see anything unexpected.

Putting everything in the same job (with dependency-review-action last) is the ideal solution

Ok 👍🏻
For the record I was already using retry-on-snapshot-warnings, retry-on-snapshot-warnings-timeout with a fair timeout I believe (5min, way longer than the time it takes for the submission to run).
I retried the failed workflow 3-4 times to no avail. I recreated a new PR with the same changes and it worked first try (without changing the review workflow).
I guess what's frustrating is that I can't tell what's going on, what is published too late? attached to a wrong sha1? 🤷🏻
If it happen again I'll try the method of having both submission & review in the same job (and might dig in the APIs used by the actions to see if I can understand what happen).


One invoice for multiple subscriptions with variable quantity

Let me first explain what we’re trying to achieve. We’re currently creating a SaaS application offering management software in several modules. Organizations are free to choose whatever modules they’d like to use. Prices are calculated based on the amount of users which an organization has.
In short, there’s the following demands:

invoice (the day does not matter, may be a fixed date, may also be variable bases on the day an organization subscribed)
Variable quantity (for every user that registers for an organization, we increment the subscription quantity)
Multiplan (currently we create a new subscription for every chosen module, would be nice to use cashier-stripe’s new feature)

Several solutions to our issues have been provided already, but the combination does not work. We can create a single invoice by running cashier:run on one single day every month (#65 ). All due OrderItems will be processed into one Order.
However, this results in problems when using the quantity feature. Because if the quantity is raised from 2 users to 5 at the end of the month (and the organization hasn’t paid anything yet), this will result in an order for 5 users for the whole month (since prorating didn’t do anything because there was no pre-paid amount to reimburse).
A solution to that problem might be to invoice after every increment/decrement of a subscription, but that doesn’t seem very user friendly to me since they might get an invoice for every day of the month (some organizations change employees very quickly).
Another suggested solution might be the subscription anchor date (#66 ). Every time a subscription increments/decrements charge the organization for the rest of this month. But anchor dates are missing at the moment.
Then there’s one solution I thought of: what if there would be an incrementByCredit/decrementByCredit method to increment the quantity and subtract the costs from the users credit (might get negative). This negative credit will then be invoiced at the first moment cashier:run is being run. In that way, organizations get just one invoice per month and all increments/decrements from that month are nicely prorated so that the organization really only pays for the days that he used a module or had a certain amount of users.
Do you think of any combination of solutions that would fix our problem? I have time to create some new features like multiplan subscriptions, anchoring dates or this new in/decrementByCredit feature. What would you suggest?

Hi!
Have you tried setting the updateQuantity parameter $invoiceNow to false?
The seat prorating will then be invoiced the next time you execute cashier:run instead of directly.

Well I tried that before, but I think I did something wrong, because I've just tried it again and works nicely! Thanks a lot


[streaming] [scala] Exposed environment from DataStream

This is needed for streaming library features, is identical to the batch API.

@StephanEwen @mbalassi Any updates on this PR?

Thanks for the ping. We had an offline conversation with @StephanEwen and decided that the initial approach is sufficient.


Core bug with payload size due to infinite Error stack trace limit

Hi @benvinegar - I'm wondering if this is an issue with raven or something on my end.
I'm using the standard default Express setup with raven's requestHandler middleware, but for some reason I constantly get<EMAIL_ADDRESS>alert: failed to send exception to sentry: HTTP Error (413): undefined errors.  This is a 413 is Payload Too Large error.
Related to #339 and #58.  Since we set Error.stackTraceLimit = Infinity; at https://github.com/getsentry/raven-node/blob/514159d8b2bf173ed70beafba786a1087c7ceaa5/index.js#L9-L10 does this cause this issue?

Is this a raven-node or a raven-js issue? You've linked to raven-node code.

Wow, can't believe I made the same mistake twice here, so many packages.  Will open in raven-node..


Bring back handing the fighting style feat addition.

I didn't make this pull request I'm closing it.


[FR] Extendable exporter management

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Currently we have otlp exporter and some other exporters in developing. However, we found some pain point contributing exporter to the community.
In order to provide an exporter that could be used by different people in different scenario, many params must be added to the configuration. For example:

when working with log exporter, which convert flow_log to plaintext log in one line, the log format is hard to control and match different requirement. It could be in json style, or seperated by ,, or seperated by |. And log content / header field key can be different, like ts=2023-09-13 09:50:00, or ts=2023-09-13 09:50:00.023, or timestamp=16323423432, or datetime=20230913095000.

TLDR: You cannot provide a configuration with unlimited params that flexable enought for all people.
I'm wondering if we could have some design like OpenTelemetry Collector Contrib, which holds a lot of different receiver / processor / exporter: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter
Further more, new exporter could be added via git submodule. I think the following step is preferred, in order to apply specific exporter to the latest DeepFlow release, without putting codes to DeepFlow repo:

git clone DeepFlow repo.
git submodule pull a external / internal / private exporter to the exporter folder, e.g. ./server/ingester/flow_log/exporter/my_wonderful_exporter/
make build
... (push image / restart deepflow server with new image tag)

So, exporters that not universal enough could be hold in private repo / company gitlab, and easily integrate with the latest version of DeepFlow. Those exporter could be managed more easier, and donate to the community at the right time, rather than designing a universal exporter at the very begining but failed.
Use case
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

目前可以参照 otlp exporter 来实现增加新的exporter， 需要增加修改的代码都在 server/ingester/flow_log/exporters/ 下

/exporters.go  增加对新增exporter的启动
/config/config.go  增加新exporter 的配置项
新建目录 xxx_exporter 并实现 exporter.go 中的Exporter  interface


version for vis2

Is a version for vis2 planned?
can you please add some info about the usage?

Hello... the adapter ist still in alpha mode. I have many Ideas for the future of the adapter. It is also planed to bring the Adapter to Vis2. Because the Future is in this VIS.
I'm updating the readme the next few days.

A version for vis-2 is in work and will become an release soon.
https://github.com/Kollos2k/ioBroker.vis-2-shelly


[1.16] Missing adult filter for slaughter factory

Industrial Foregoing Version:
industrial-foregoing-1.16.5-<IP_ADDRESS>-14.jar
Titanium Version:
n/a
Crashlog If Applicable (Upload to pastebin/gist):
n/a
In the 1.16 version of the mod, the mob slaughter factory kills babies, but there is no longer an adult filter to prevent it. It seems the adult filter was removed somewhere along the line as it used to be in the mod. W/o the adult filter, it complicates the process of breeding animals and ultimately getting only the adult offspring slaughtered.

This is not a bug I think.
The Animal Baby Separator machine can now separate baby animals OR adult animals. In the GUI of the machine there is a button you can click  to switch between modes.


feat: provider network mirror protocol with pull-through cache

Implements #21.
This is a rough PR to get the discussion started :)
A list of features from the top of my head

created the mirror module which contains the logic for the pull-through cache
implemented endpoints for all specified operations of the provider network mirror protocol
created core module which should contain core data structs used by multiple modules (e.g. Provider)
created storage module which should contain the storage backends
Added a DirectoryStorage storage backend  implementation in order to test the functionality easily. Only the functionality necessary for the pull-through cache is implemented right now. I'm also not sure if we would like to support that storage backend at all

What we need to sort out:

[ ] how to structure mirrored and uploaded providers? If we want to break backward-compatibility, both could live in /providers, else we would need e.g. /mirror and /providers
[ ] store upstream hashes of archives and distribute them to the clients
[x] add --http-write-timeout flag
[ ] don't use core.Provider as function parameter. Let's be more specific and use variadic functions

How to test the PR:
Run the boring-registry
go run ./... server --storage-directory-path ./local_storage --tls-cert-file localhost.crt --tls-key-file localhost.key

configure the Terraform CLI and run e.g. terraform plan on a terraform stack
provider_installation {
  network_mirror {
    url = "https://localhost:5601/v1/mirror/"
  }
}

Solved with #143


Add SwiftUI Label

Description
Added HILabel in SwiftUI
Missing some border and shadow cases, but can come back to it if encounter those cases

Please resolve all of the following lint violations

Trailing Whitespace Violation
Colon Spacing Violation
Trailing Comma Violation
File Header Violation
Opening Brace Spacing Violation
Void Function in Ternary Violation
Function Body Length Violation
Line Length Violation
For Where Violation

And deprecations

Change Class to AnyObject

Look at the build log for the exact warnings.


Note ide specific behavior with noinspect

In the section "Simply suppress the warning:", the noinspect comment only works in intellij platform IDEs. You probably should note that behavior.

fixed in commit d58738b


Benchmark splits

Hi,
I have got another question: Would you mind providing the seed for splitting the benchmarking datasets (or the splits themselves)?
And also: Did you run all the benchmarkings of the other models on your paper yourself or did you gather the results from the corresponding papers (Table1 and Table2)?
Thanks!

Hi,

All the benchmarks from MoleculeNet (except for QM9) are split by scaffold, which gives you a deterministic split for each database, unlike random splitting. For QM9, we didn't pick a specific seed for splitting. Each individual run uses a different random seed.
We borrow the results from other literature if available and run experiments on our side otherwise.

Best


Change all txt files to markdown

Discord supports markdown highlighting for small file snippets. We should make use of it and use discord's markdown highlighting instead of the current boring txt

Implemented by https://github.com/M-Davies/oghma/commit/2aeebc51d945b86dc08de2d3953b3cb650a87817


Access to request object

Is there a way to access the request object inside the templates? I would like backend access to the request headers for conditionals. I'd prefer not to use JavaScript, and the request is certainly available to Middleman.

It seems the current_page object has some request data (particularly the content type) but not the rest of the headers.

There's a way, but it's not public and will be removed in a future version.
What are you trying to accomplish? Static sites shouldn't be relying on anything in the Middleman dev server.


fixed over flow issues

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
I have fixed the overflow issues in login and signup pages

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Manual testing
[* ] Widget testing
[ ] Unit testing

Checklist

[*] My code follows the style guidelines of this project
[*] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[*] I have made corresponding changes to the documentation
[*] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Congrats @Ayushpanditmoto 🎉, your PR got merged. To be eligible for the swags from ClueLess. Follow this steps.

Star this repository. ⭐

SignIn / SignUp in [ClueLess Website](https://www.clueless.tech/) .

Go to profile section from the top right hand corner.

Comment your profile URL under this comment tagging the person who merged your PR.

That’s it. Follow the leaderboard !
And don’t forget to share your achievement with your friends.

https://www.clueless.tech/profile/admin/31253617
@Roshaen


FIX-#3764: Fix df.loc with scalar out of bounds appends to df

What do these changes do?

Added changes to existing PR by Rehan. Included fixes to original implementation and additional test cases for df.loc.
Original PR: https://github.com/modin-project/modin/pull/3765

[ ] commit message follows format outlined here
[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] signed commit with git commit -s
[ ] Resolves #?
[ ] tests added and passing
[ ] module layout described at docs/development/architecture.rst is up-to-date
[ ] added (Issue Number: PR title (PR Number)) and github username to release notes for next major release

@noloerino @Billy2551 I've converted this PR to a draft because I recall @Billy2551 was going to back to @RehanSD 's originally PR, #3765. @noloerino I think you should port your comments to #3765 .

It looks like the issue for which there was a pull request has already been resolved. Feel free to reopen if needed.


STORM-2343: New Kafka spout can stop emitting tuples if more than maxUncommittedOffsets tuples fail at once

This builds on https://github.com/apache/storm/pull/1832, sorry for the mixed diff
This makes the spout emit failed tuples even when numUncommittedOffsets has reached maxUncommittedOffsets. Previously the spout would fail to progress in that case. I haven't really been able to enforce maxUncommittedOffsets strictly without having to request extra messages from Kafka and throwing them away. The consumer doesn't allow the spout to limit how many tuples it requests dynamically, and I'd prefer that the spout doesn't truncate the list of records it receives.
Instead, maxUncommittedOffsets is now a soft cap on the number of tuples that can be emitted before some must be committed. In some cases (e.g. 10 partitions with 1 failed message emitted on each), the spout will exceed the limit. It should never be by more than 1 maxPollRecords size though.
This also makes KafkaSpoutRetryExponentialBackoff use Storm Time, and it fixes a bug where messages could be lost if they were scheduled for retry at the same timestamp. It also fixes double counting failed tuples in numUncommittedOffsets when retrying, since the counter isn't decreased when the tuple is scheduled for retry.
maxPollRecords is now capped by maxUncommittedOffsets, since if maxPollRecords is higher the spout will exceed the limit on any poll where Kafka can return maxPollRecords messages.

I think it would be best if we merged maxPollOffsets and maxUncommittedOffsets, since having them be different has some undesirable side effects. @hmcl do you have an opinion.
Also this drops support for Kafka 0.9 in KafkaSpoutConfig, since I believe https://github.com/apache/storm/pull/1556 already means that this release won't work with 0.9.

This also changes the exponential backoff formula from currentTime + delayPeriod^(failCount-1) to currentTime + delayPeriod*2^(failCount-1). Multiplying the delay by itself causes the delay to grow extremely quickly, and probably wasn't intended.
It might make sense to add jitter to the backoff as well.

@hmcl I think this is ready for another look when you get a chance.

@srdo Thanks for the note. I will take a look later today.

@srdo is this patch still relevant in face of the other patches that got merged in ?

@hmcl Yes, I believe so. There is still a problem where the spout will stop emitting tuples if more than numUncommittedOffsets tuples have failed.

@srdo what you mean is that if numUncommittedOffsets  > max UncommittedOffsets the Spout should still emit the retries, but not poll new records. Is that it ?

@hmcl yes, more or less.

I think it would be good to get some of the assumptions I've made down in writing, so I just wrote down a more thorough explanation of the issues I think this PR should fix, and what changes I think it should make:
The intention of this PR is to fix an issue where the spout has emitted maxUncommittedOffsets (or more) tuples, and some of them fail, and the spout then hangs because the numUncommittedOffsets < maxUncommittedOffsets check when deciding whether to poll doesn't account for retriable tuples. Blindly polling when there are retriable tuples will fix this issue, but leads to us not being able to bound the number of offsets the consumer has read past the last committed offset.
For an example of a case where we can't put a bound on uncommitted offsets, say that partition 0 has maxUncommittedOffsets + maxPollRecords emitted tuples past the commit offset, and partition 1 has no emitted tuples (or any number below maxUncommittedOffsets, it doesn't matter).
When tuples fail and become retriable on partition 0, the spout would blindly poll for more tuples. If it gets tuples from partition 0 it's okay, since it seeks back to the committed offset for that partition, so it won't go beyond committedOffset + maxPollRecords (since the retry logic seeks back to the committed offset on every poll, the spout can't go more than maxPollRecords beyond that offset). If it gets tuples from partition 1 we're effectively just emitting new tuples while ignoring maxUncommittedOffsets. Since we aren't controlling which partitions the polled tuples may come from, we can't say anything meaningful about a cap on uncommitted offsets. While I think it would probably work out to being capped anyway, due to the consumer consuming partitions round robin (AFAIK), I'd prefer if the spout implementation doesn't make assumptions beyond those guaranteed by the consumer API (in which case we should assume any call to KafkaConsumer.poll could return messages for any assigned non-paused partition).
So the way to fix that issue is to ensure that if we're polling for retriable tuples, we only poll on those partitions that have retriable tuples (i.e. we pause the others when doing doSeekRetriableTopicPartitions, then resume all assigned after calling KafkaConsumer.poll). Pausing the other partitions should only affect that poll cycle, since once retriable tuples get emitted they're no longer retriable, and we won't hit doSeekRetriableTopicPartitions for those tuples again right away. In most polls (no failed tuples, or tuples are failed but not ready for retry), we won't hit the pausing case.
If we pause partitions with no retriable tuples when polling on partitions with retriable tuples, we should be able to guarantee that any partition never gets more than maxUncommittedOffsets + maxPollRecords - 1 past the last committed offset. In the case where there are no failed tuples, we can reach the limit by having maxUncommittedOffsets - 1 emitted offsets, and polling once, getting up to maxPollRecords more. If there are retriable tuples, pausing will stop us from ignoring the maxUncommittedOffsets cap for partitions with no retriable tuples, and the partitions with retriable tuples won't get more than maxPollRecords beyond the last committed offset, since the consumer seeks back to that offset when polling for retriable offsets.
There's a second minor issue I'd like this PR to address:
If maxPollRecords isn't exactly equal to maxUncommittedOffsets, the spout can behave in some undesirable ways.

If maxPollRecords is greater than maxUncommittedOffsets, the maxUncommittedOffsets limit may be exceeded on any one poll. In this case there's no reason to have 2 separate variables, since the net effect is the same as setting maxUncommittedOffsets to be equal to maxPollRecords.
If maxPollRecords is less than maxUncommittedOffsets, there's a risk of the spout getting stuck on some tuples for a while when it is retrying tuples.
Say there are 10 retriable tuples following the last committed offset, and maxUncommittedOffsets is 10. If maxPollRecords is 5 and the first 5 retriable tuples are reemitted in the first batch, the next 5 tuples can't be emitted until (some of) the first 5 are acked. This is because the spout will seek the consumer back to the last committed offset any time there are failed tuples, which will lead to it getting the first 5 tuples out of the consumer, checking that they are emitted, and skipping them. This will repeat until the last committed offset moves. If there are other partitions with tuples available, those tuples may get emitted, but the "blocked" partition won't progress until some tuples are acked on it.

I think it might make sense to remove maxUncommittedOffsets entirely, and have the spout use maxPollRecords instead?
The tl;dr is that I think we should allow polling if there are retriable offsets, even if numUncommittedOffsets >= maxUncommittedOffsets, we should pause non-retriable partitions when polling for retries, and we should maybe merge maxUncommittedOffsets and maxPollRecords.
@hmcl Could you take a look at this explanation and let me know if I got something wrong, or if you'd prefer to solve the issues in another way? I think it got a bit hypothetical.

@hmcl I made the changes mentioned in my last comment.
As far as I can tell there's no way to get the default max.poll.records out of Kafka, so for now I've made do with adding comments in KafkaSpoutConfig recommending that maxUncommittedOffsets and maxPollRecords should be equal.

IMHO, looks like maxUncommittedOffsets makes thing complicated.
We've two throttling mechanism here: maxUncommittedOffsets and max spout pending.
Since KafkaSpout guarantees that only one tuple emitted per one nextTuple() call, max spout pending will work perfectly.
So if it's just for throttling, why not relying on max spout pending? At-least-once is guaranteed whether we have maxUncommittedOffsets or not.
If max spout pending is unset, users should have known that Spout will emit tuples as many and fast as possible unless backpressure is not in place.

@srdo apologies for a little delay. Had a lot of deadlines for last week. I will finish reviewing this today.

@HeartSaVioR I agree, I think it would be much simpler to rely on maxSpoutPending. maxUncommittedOffsets does have a slightly different meaning though. With only maxSpoutPending, the spout might progress arbitrarily far past the last committed offset, since there's only a limit on how many tuples are in-flight at once, rather than on how many tuples have been emitted past the committed offset. If a user needs to cap how far the spout can read ahead for some reason, they can't do that with maxSpoutPending.
I can't tell if that's a real need anyone has though. @hmcl any opinion?

+1
Once @hmcl finished the review and no outstanding comments there I'll merge.
Btw, regarding maxUncommittedOffsets, yes it provides more guarantees but if we guarantee that commit occurs in time periodically (we're providing option too), IMHO that's enough.
The thing I have in mind is that commit in nextTuple() doesn't strictly guarantee commit in time. Two situations come in mind: reached max spout pending, backpressure in place.
If spout reached max spout pending, since we are emitting at most a tuple for nextTuple() so when tuple tree for a tuple is complete or tuple fails, nextTuple() can be called. At least nextTuple() will be called after tuple timeout (actually up to 2 * tuple timeout due to underlying implementation).
So if users can tolerate this, it might be OK, but could be far from configured value.
If backpressure is in place, nextTuple() will never be called. We can't guarantee any time frame here.
If we want to strictly guarantee that commit occurs in time, it should be apart from spout's lifecycle, like timer. It might also introduce some handling of thread-safety so a bit more complicated, but IMO simpler than respecting maxUncommittedOffsets.

@hmcl
I guess you're busy, but could you continue reviewing this one, or please let me know if you are not available for reviewing soon? I'd like to get this merged sooner since this is necessary for 1.1.0.

@HeartSaVioR @srdo reviewing this right now.

@hmcl @HeartSaVioR I think if we can't think of a good use case for maxUncommittedOffsets, we'd be better off removing it.

@srdo I am reading through your detailed explanation again and will let you know my opinion concerning the need, or no need, for the parameter maxUncommittedOffsets, based on all the facts you state.
Prior to that, however, I will share right away what is the rationale behind maxUncommittedOffsets and why I think we still need it.
maxUncommittedOffsets is unrelated to ConsumerConfig#MAX_POLL_RECORDS_CONFIG and to Config#TOPOLOGY_MAX_SPOUT_PENDING. It's purpose is to allow the KafkaSpout to keep polling/fetching records from Kafka while imposing a (memory consumption) limit on how many offsets can be polled and non committed over ANY ARBITRARY NUMBER of polls to Kafka (not just one poll), before the KafkaSpout stops polling.
This limit is necessary because if e.g. tuple for offset 3 keeps failing, and all subsequent offsets (4, 5, 6, ... 1M, ... 1B, ...) are acked, the spout won't be able to commit to Kafka any offset greater than 3, unless it reaches maxNumberOfRetrials. If there is no limit on maxNumberOfRetrials (in order to guarantee at least once delivery), and offset 3 keeps failing forever, the spout won't ever be able to commit any offset > 3. In the limit this would cause the Map<TopicPartition, OffsetManager> acked to grow to infinite size (despite it's small footprint, which is constituted of mainly offsets and some bookkeeping small objects - it doesn't have ConsumerRecords).
In order to put a cap on the size of this map, maxUncommittedOffset was created to stop polling if this number is too high, and avoid OutOfMemoryError. The purpose of the KafkaSpout keeping on polling despite a particular offset (tuple) keeping on failing is to increase the overall throughput. If at some point the offset 3 is successfully acked, the max subset of continuous offsets acked would be committed to Kafka in the next Timer commitTimer cycle, and the size of Map<TopicPartition, OffsetManager> acked would be reduced (potentially by a lot). The spout could then keep doing its work and the overall throughput would be much higher.
maxUncommittedOffsets is not a hard limit parameter, and I don't think that we have to enforce that the KafkaSpout never exceeds this number. It is OK to exceed it as long as the JVM doesn't throw OutOfMemoryError. Currently, and prior to these proposed changes, in the worse case maxUncommittedOffsets is upper bounded by  maxUncommittedOffsets + maxFetchRecords - 1, which is OK as long as there is memory.
Perhaps the name maxUncommittedOffsets is not the most clear name. We can either change the name (which can cause background compatibility issues and/or confusion), or document properly what this parameter really means. The bottom line is that I think that we need a parameter doing the job that maxUncommittedOffsets is currently doing, which I don't think can be accomplished with a combination ofConsumerConfig#MAX_POLL_RECORDS_CONFIG and/or Config#TOPOLOGY_MAX_SPOUT_PENDING
The name maxUncommittedOffsets should more precisely be something like allowPollingIflLessThanMaxUncommittedOffsets
Please let me know your thoughts. I will still go over your explanation again in the meantime.

@hmcl Thanks for the explanation. It makes more sense now.
I don't think we can meaningfully handle the case where the user has specified no cap on retries and one or more tuples keep failing.
In the situation you describe, maxUncommittedOffsets isn't really solving the problem. If offset 3 fails and all other tuples can be acked, the spout will emit another maxUncommittedOffsets tuples on the same partition as 3, and will then stop emitting because it can't commit any tuples until 3 is acked. At this point, only offset 3 will get re-emitted until it hopefully succeeds at some point, so having a continually failing tuple (or just one that fails many times) will still "clog" the spout.
If maxUncommittedOffsets is removed, you're right that the acked map size is technically uncapped, but given the amount of information we store, and how the spout handles retries, I think it is a non-issue. Just to illustrate, say we remove maxUncommittedOffsets, and let's say again that offset 3 is failing a large number of times, and the last acked offset is far beyond it, e.g. 5000000. When 3 is ready for retry, the consumer is reset to that position on the relevant partition. This means it fetches and emits message 3. It will also have to fetch 4...5000000 (potentially over many calls to poll()), because we never seek forward to where we left off). The spout therefore has to spend time fetching and discarding all tuples up to 5000000 before it can finally emit another tuple. It seems likely that it'll hit the point where it is spending all the time fetching and discarding acked tuples earlier than it'll run out of memory to store their offsets.
Disregarding the issue with consumer seeking, because my reasoning relies on an implementation detail of how we do retries, I'm still not sure maxUncommittedOffsets is allowing higher throughput compared to not having it. If we allow the spout to fail with an OutOfMemoryError, the spout will have had higher throughput up to the crash than if it were being throttled by maxUncommittedOffsets (because otherwise it would also have had an OOME in that case). It really seems to me like all maxUncommittedOffsets is doing is trading having the spout potentially cause an OOME due to acked size, in exchange for making the spout react to the same situation by not emitting any more tuples. I'm not sure that is better, because data flow stops in either case.
maxUncommittedOffsets could have some value in a system where the KafkaSpout is a secondary stream source and the messages coming out of it aren't time sensitive. In that case it might be fine to let the KafkaSpout stop emitting tuples for a while if some tuples temporarily can't be acked, but having it cause an OOME would be too disruptive because the primary spout could be doing fine. I can't come up with a concrete example of this kind of configuration though.
I'd be fine with keeping maxUncommittedOffsets for that kind of situation.

Sorry to keep changing this. I hope these are the last few changes. The spout should now seek to the lowest retriable offset for each partition when retrying tuples, instead of seeking back to the last committed offset. This means there's not as far as I can see any reason to worry about maxPollRecords being set too low compared to maxUncommittedOffsets, so I've reverted that part of KafkaSpoutConfig.

@hmcl
I think @srdo addressed your last review comments. Could you finish the review?
Please let me know if there're some points we need to discuss or resolve, so that we can address them now, or file new issues and postpone to next release if possible.

@HeartSaVioR I think as long as the spout can seek to the tuples it needs to retry instead of seeking to the committed offset, all of the minor issues I could think of are resolved.

@srdo @HeartSaVioR I will do the last pass on this first thing in the morning such that we can merge this in.

Thanks for the reviews guys.

+1.
@srdo I forgot to say in the last review. Can you please squash the commits. Once that is done as I am concerned, this patch is ready to merge.
@HeartSaVioR can you please do your last pass? Thanks.

@srdo
Thanks for your patience. +1
I can squash this and merge, but seems like #2004 depends on this so it would be clearer if you squash the commits for this PR (and for 1.x branch #2022 too), and rebase #2004 after merging this.
Let me know when you finish squashing. Thanks again!

Very sorry about this, but this is still broken :(
In the current implementation (pre this PR), the spout can be prevented from polling if there are more than maxUncommittedOffsets failed tuples. This is because the check for whether to poll isn't accounting for retriable tuples already being counted in the numUncommittedOffsets count.
The current fix is to allow failed tuples to retry always, even if maxUncommittedOffsets is exceeded, because failed tuples don't contribute further to the numUncommittedOffsets count. The problem has been to ensure that we don't also emit a bunch of new tuples when polling for retriable tuples, and end up ignoring maxUncommittedOffsets entirely. This was partially fixed by pausing partitions that have no retriable tuples.
With the previous seeking behavior, this was a complete fix, since maxPollRecords put a bound on how far the spout could read from the commit offset in a poll that was ignoring maxUncommittedOffsets. With the new seeking behavior this is broken. If the spout has emitted as many tuples as allowed, and the last (highest offset) tuple fails, the spout may now poll for a full batch of new tuples, starting from the failed tuple. This scenario can repeat arbitrarily many times, so maxUncommittedOffsets is completely ineffective.
We don't want to go back to the old seeking behavior (IMO), because it meant that in the case where maxPollRecords is much lower than maxUncommittedOffsets (almost always), the spout might end up choking on failed tuples. For example, if maxPollRecords is 5, and tuple 0-4 are not ready for retry (they might have been retried already, and are now waiting for retry backoff), but tuple 5-9 are, the spout is unable to retry 5-9 (or anything else on that partition) because it keeps seeking back to 0, and polling out the first 5 tuples. Seeking directly to the retriable tuples should in most cases be more efficient as well, because in the old implementation we'd just be seeking to the last committed offset, polling, and discarding tuples until we reach the ones that can be retried.
We could probably fix the broken behavior by trying really hard not to emit new tuples when we're ignoring maxUncommittedOffsets, but that seems like it would be error prone and complicated to implement.
I think we might be able to fix this by ensuring that we don't "doublecount" retriable tuples. When the spout is deciding whether to poll, it should deduct retriable tuples from numUncommittedOffsets when comparing to maxUncommittedOffsets.
Changing the poll check in this way is the same as enforcing the following constraint per partition, it seems to me:

Poll only if numNonRetriableEmittedTuples < maxUncommittedOffsets. If there are more nonretriable tuples than that, the poll won't be allowed because numUncommittedOffsets = numRetriableTuples + numNonRetriableEmittedTuples, so numUncommittedOffsets - numRetriableTuples >= maxUncommittedOffsets.

This should mean that the limit on uncommitted tuples on each partition is going to be maxUncommittedOffsets + maxPollRecords - 1, because the latest tuple that can be retried on a partition is the one at offset maxUncommittedOffsets, where there are maxUncommittedOffsets - 1 uncommitted tuples "to the left". If the retry poll starts at that offset, it at most emits the retried tuple plus maxPollRecords - 1 new tuples.
There shouldn't be any problems when multiple partitions have retriable tuples, where retriable tuples on one partition might be able to cause a different partition to break the uncommitted offset limit. This is because a partition will at minimum contribute 0 to numUncommittedOffsets (e.g. if all uncommitted tuples on that partition are retriable), because any retriable tuples being subtracted were already counted in numUncommittedOffsets when the tuples were originally emitted.
If we can enforce the limit on a per partition basis this way, there's no reason to worry about only emitting retriable tuples when we're exceeding maxUncommittedOffsets.
I don't think there's a need for pausing partitions anymore either. It was meant to prevent polling for new tuples when there were retriable tuples, but we're no longer trying to prevent that, since the per partition cap is already ensuring we won't emit too many tuples. Pausing in this case would prioritize retriable tuples over new tuples (e.g. in the case where an unpaused consumer might choose to fetch from a nonretriable partition even though there are retriable tuples), but might lead to lower throughput overall (in the case where there are not enough messages on the retriable partitions to fill a batch). I've removed it again.
I've put up what I hope is the fix both here and on the 1.x branch. Sorry again that this has turned into such a moving target.

@HeartSaVioR @hmcl Do you guys have time to take another look? (again, very sorry about the number of times I've declared this "done")

Can you please let us know if this fix will be applied to lower version 1.0.4 or 1.0.3

@pavankumarp89 It should probably go in 1.2.0 or something like that. I definitely want it backported to 1.x, but I think we're trying to avoid API breakage in patch versions, and this PR changes the RetryService API.

Squashed and rebased

Thanks @srdo for your patience. Merged into 1.x & master.


ESLint error when importing components: @govuk-react/[component]' should be listed in the project's dependencies

I am importing this component as per storybook: import Input from '@govuk-react/input'; which works fine but I am getting EsLint error:
'@govuk-react/input' should be listed in the project's dependencies. Run 'npm i -S @govuk-react/input' to add iteslint(import/no-extraneous-dependencies)

How to best deal with this type of error?

This looks like a problem your end. @govuk-react/input is a dependency of govuk-react. I'm betting you only have govuk-react declared in your package.json. You can import the Input component from govuk-react like this:
import { Input } from 'govuk-react';

How ever I would recommend instead using InputFIeld which is a higher level abstraction of Input and provides great support for react-final-form.

So given I want to use the input component, what packages do I need to install? Both govuk-react and @govuk-react/input? Sorry I am little confused.

It looks like you need to ensure the dependancy '@govuk-react/input'  is listed in your projects dependancies (package.json) as per the error message, maybe this intro on dependancies might help? https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file
As you are only using @govuk-react/input you only need to ensure this package is in your projects dependancies. If you run the commang in the error message it will add it to your package.json file for you, or you could add it manually and then run npm install to install the dependancies listed in package.json.
If you wanted to use multiple elements from govuk-react you only need to make sure that is in your dependancies and that you import from there, as per the example in dsm23's comment.
I am going to close this issue as it is not an issue linked to this repository. If you think it is a problem with the repository please do comment again with a codesandbox example of the issue so we can help.
Cheers!


Remove old DSPO deployment for correct RHODS upgrade

Description

Labels for DSPO have been updated so the old DSPO deployment needs to be removed for proper upgrade from one RHODS version to another.
Related issue: https://github.com/opendatahub-io/data-science-pipelines-operator/issues/140
How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] For commits that came from upstream, [UPSTREAM] has been prepended to the commit message.
[ ] JIRA link(s):
[ ] The Jira story is acked.
[ ] Live build image:
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work.
[ ] QE contact acknowledges that this has been tested and is approved for merge.

/hold
Hold on merge until the label updates in https://github.com/opendatahub-io/odh-manifests/pull/847 make it to downstream/RHODS.

/unhold

This live builder image has this change: quay.io/hukhan/rhods-operator-live-catalog:1.31.0-1

Note I had to use dashboard image: registry-proxy.engineering.redhat.com/rh-osbs/managed-open-data-hub-odh-operator-bundle-rhel8:v1.31.0-1 because live builder image doesn't seem to work on my device.

As well as:  https://github.com/red-hat-data-services/odh-manifests/pull/413
As such it's ready for review/merge.


Add getCurrentSpeech() function & tests

@desko27 Thank you so much for contributing and taking the time to add documentation and tests! 👍 I am wondering what is the expected behavior for the following use case:
theater
  .addActor('vader')
  .addScene('vader:Luke...')
  .on('erase:start', function () {
    console.log(theater.getCurrentSpeech())
  })

The erase scene doesn't have the speech in its arguments so it will log undefined. Is that what is expected? If so, it'd be great to have a test case covering that.

 Added null test case and reorganized getCurrentSpeech()'s code to make it simpler.
Thanks for this amazing library 👍🏻

Thank you @desko27 👍


COMP: fix linking on OpenBSD

this fix linking error on openbsd platforms.
tested with openbsd 6.2, 6.3

Thanks for contributing this @rkanavath !
We are currently transitioning to GitHub. IN the meantime, I submitted the patch to Gerrit:
http://review.source.kitware.com/#/c/23420/


Uninstalled Event Source results in not properly finalized dynamic controller

If we create a new Event Source, ie. we install Kafka Sources or AWS SQS Source, the parent controller successfully creates a new dynamic controller for this particular Source. But if we unistall this Source, the created dynamic controller is not properly finalized/destroyed. This results in error messages in the log:
E0716 16:57:18.095520       1 reflector.go:382] k8s.io/client-go@v12.0.0+incompatible/tools/cache/reflector.go:125: Failed to watch *v1.Source: the server could not find the requested resource

This part of the code is probably not properly called:
https://github.com/zroubalik/autoscaler-keda/blob/85186c0c257126f6aa71fac9b26f9b252210e523/pkg/reconciler/crd/reconciler.go#L111-L119

/remove-lifecycle stale

/assign

FYI: I see this error in the logs in BOTH eventing-autoscaler-keda's contoller controller-xxx -n eventing-autoscaler-keda AND also in knative-eventing's controller eventing-controller-xxx  -n knative-eventing when the CRD is uninstalled.
That expected?
cc: @zroubalik

@aavarghese I don't think this is expected. We should talk to some folks familiar with that part of Eventing, maybe @nachocano?
CC @lionelvillard any suggestion?

interesting. I've seen this error before in core eventing, can't find the issue.
@nachocano any ideas?

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle stale
/triage accepted


Revert "Update tensorflow-swift-bindings to one with virtualized interface"

Reverts apple/swift#24948, which causes compilation to fail on macOS.
/Users/danielzheng/swift-dev/tensorflow-swift-bindings/RawOpsGenerated.swift:20:49: error: 'some' return types are only available in macOS 9999.0.0 or newer
func makeOp(_ name: String, _ nOutputs: Int) -> some TFTensorOperation {
                                                ^
/Users/danielzheng/swift-dev/tensorflow-swift-bindings/RawOpsGenerated.swift:20:6: note: add @available attribute to enclosing global function
func makeOp(_ name: String, _ nOutputs: Int) -> some TFTensorOperation {
     ^
/Users/danielzheng/swift-dev/tensorflow-swift-bindings/TFTensorOperation.swift:5:65: error: 'some' return types are only available in macOS 9999.0.0 or newer
  public static func makeOp(_ name: String, _ nOutputs: Int) -> some TFTensorOperation {
                                                                ^
/Users/danielzheng/swift-dev/tensorflow-swift-bindings/TFTensorOperation.swift:5:22: note: add @available attribute to enclosing static method
  public static func makeOp(_ name: String, _ nOutputs: Int) -> some TFTensorOperation {
                     ^
/Users/danielzheng/swift-dev/tensorflow-swift-bindings/TFTensorOperation.swift:1:1: note: add @available attribute to enclosing extension
extension _ExecutionContext {
^

@swift-ci Please test tensorflow

Locally verified that this fixes compilation on macOS.


[backport] doc: Fix truncated summary line

This PR is backport of #3235

jenkins, test this please

LGTM!


autocomplete prompt action

I have looked for this functionality, but could not find it.
What I would like is to be able to press "tab" which would replace prompt text with contents of highlighted line from the search list.
E.g.

In prompt I type: >lib.*/lib.*
I find /library/library path
I press tab and my prompt becomes >/library/library

Thanks.

This could be interesting for some use-cases, we'll look into it.
This will have to wait probably a few weeks though, unless you or someone else feels like opening a PR, as I have my hands very full atm with ratatui

I think what could be a general extension is "replace prompt" with 2 inputs:
sk --bind="ctrl+i:prompt_mod[${prompt} {}]"
# ${prompt} - current prompt contents
# {} - current highlighted item

Examples of applications:
a) Functionality I have indicated above
b) Binding a shortcut to toggle regex flags (and similar)
E.g. b):
function toggle_flag() {
    # parses input with flags and toggles desired one
}

sk --bind="ctrl+i:prompt_mod[toggle_flag ${prompt} i]"

So that:

prompt: >(?s)regex input
CTRL+I
prompt: >(?si)regex input

So these are just 2 examples, but this would allow a high degree of customisation.

To it seems like this could be 2 extensions:

prompt_mod action
${prompt} (in whatever form is best) variable for all actions

As this variable could be useful for other actions as well.


Thread safe query

Is python-binance a thread safe library?
The output from from the http request method is being assigned to a class variable (self.response). This is not being used any where else in the code.
def _request(self, method, uri: str, signed: bool, force_params: bool = False, **kwargs):

        kwargs = self._get_request_kwargs(method, signed, force_params, **kwargs)

        self.response = getattr(self.session, method)(uri, **kwargs)
        return self._handle_response(self.response)

I have code which executes queries via this library from multiple threads. This use of this shared variable looks like it has the potential to cause race conditions.
Happy to raise a PR if this can be replaced with a local method variable.

Hi @Tiergarten, the self.response is being saved so it's available for users to inspect after any API calls.
It is initialised in the __init__ of BaseClient which both Client and AsyncClient inherit from, so it's not a class level variable.

Hi @sammchardy, thanks for your reply.
The fact that it is a instance variable is what concerns me, as I have multiple threads pumping through a single class instance there is the potential for them to clash.

I can confirm that I'm getting the same issue. Some responses are mysteriously overwritten by others.
I can't believe that a trivial race condition exists in one of the most popular Python libraries for Binance.
The fix is very simple, simply using response instead of self.response.
The issue does not seem present on the asyncio version, because it uses response instead of self.response.
        async with getattr(self.session, method)(uri, **kwargs) as response:
            self.response = response
            return await self._handle_response(response)


modify logic of ldsPad=-1

we need to pad lds to avoid bank conflict on both ds_read and ds_write
In MatrixInstruction and TLDS,
we'll have MIInput element per ds_read and GRVW element per ds_write

not upload wider local read yet,
once we have wider local read, ldsPad should be max(GRVW,LRVW)


fcos3d :demo/mono_det_demo.py wrong visuliaztion results

I got the result as below when run demo/mono_det_demo.py in the master branch

and run /tools/test.py  got the result as below

I have tried setting several --score-thr to filter low confidence boxes, but don't got the same results as https://github.com/open-mmlab/mmdetection3d/pull/542
need to using NMS to filter detection results?
Thanks

Could you please try with the threshold 0.15? There will also be overlapped boxes left because we do not apply nms among feature levels, but I think it should not be so many.

Thanks for your reply. Yes I have tried with the threshold 0.15 and there are also be overlapped boxes left, but I think  a detected object should eventually have only one box, like https://github.com/open-mmlab/mmdetection3d/pull/542 , his results look beautiful , I want to know how he did it .Is it just adjusting the threshold?
thanks!

Hi @DMing11 I am the author of #542. The visualization with only one box per object is simply because I use GT instead of the predicted results from FCOS3D. You can see the 1st, 3rd and 4th images I post there also have many overlapped boxes for each object. I think your first image result is very similar to what I got in #542?

So it is !  Thank you very much ! @Wuziyi616

Hi, @DMing11 @Wuziyi616 @Tai-Wang
I met the same problem of keeping so many bboxes overlap with each other and I found it's caused by the setting of 'nms_thr'. The default setting is 'nms_thr=0.8', you could set it to a lower value (like 0.2) and the visualization result will be much better.


Add timestamp in Power Distributing Result

What's needed?
Add timesetamp in Power Distributing Result:

We need to know when exactly the power was set.

Proposed solution
No response
Use cases
FCR Balancing actor
Alternatives and workarounds
Just get the time when the Result arrives, which is a very imperfect way to do this.
Additional context
No response

We need to know when exactly the power was set.

I don't think we can do that, since we don't get this information from the hardware.
The best you can do is subscribe to the return channel and use the timestamp of the returned message.

After some talking and with the new SDK changes which uses proposals instead of power requests, a good way to get what is needed here (probably?) is to use the battery_pool.power()  method..

OK, closing as invalid.


Add checks for Emscripten API return values

Add checks for Emscripten API return values to make sure API calls are not failing.

Those BX_CHECK become noops in release, so the functions are not called. Maybe doing those tests in two steps like so ?
int res = emscripten_webgl_make_context_current(m_context);
BX_CHECK(res == EMSCRIPTEN_RESULT_SUCCESS, "emscripten_webgl_make_context_current() failed!");

I had this exactly in mind when writing this, and jumped in to the code to find and say "no they don't, this construct is being used all over in the renderer codebase like this!", but now when I look at the code, I see
			GL_CHECK(glGenTextures(1, &m_id) );
			BX_CHECK(0 != m_id, "Failed to generate texture id.");
			GL_CHECK(glBindTexture(_target, m_id) );
			GL_CHECK(glPixelStorei(GL_UNPACK_ALIGNMENT, 1) );

So BX_CHECKs do have the semantics that they become no-ops, but GL_CHECKs have the opposite meaning to expand to unchecked form of the code. Yikes for consistency/static readability on above types of constructs :/
Certainly need to do the checks in two passes it seems.

Yeah, GL_CHECK, DX_CHECK, VK_CHECK match every GL/D3D/VK API.
What you want is to create EMSCRIPTEN_CHECK. That has the same semantics as GL/D3D/VK_CHECK because you're creating API check.

I could rename BX_CHECK to BX_ASSERT if that will make less confusion.

Done. https://github.com/bkaradzic/bgfx/commit/2cbcb6ea90cf9469a525ed76db4fa7d3dd0dfb73

Fixed: https://github.com/bkaradzic/bgfx/commit/77c974b69f99e71e14edde0b2666e71222566fea

Great idea this EMSCRIPTEN_CHECK ! There are some other calls to emscripten functions that should be wrapped around it in glcontext_html5.cpp and glcontext_egl.cpp.

Looks great!

@goodartistscopy Feel free to add it, and send PR. One thing with *_CHECK is that they need to be used in cases where we expect positive result, and there is no reasonable way to do anything in case of failure. If result might be multiple things then proper error handling needs to be added.

Ok i'll had just those that prevent html binaries to not run properly in release build


[Question] Can I create my own library which provides templates and NTypewriter?

Hi! First of all, your library is outstanding... awesome work.
I want to create a library that automatically maps CQRS commands (decorated with some attributes) to endpoint using ASP.NET minimal API.
Forcing users to add NTypewriter + the templates + the extensions needed sounds like overkilling for some developers.
Is there any way to create my own source generator which introduce custom predefined templates?
I can download the project and inject my files, probably here but I'd like to know if this can be a feature... I don't know, maybe scanning other assemblies for custom configuration.
Again, awesome job. Thank you.

I guess I can create a source generator and use https://github.com/NeVeSpl/NTypewriter/blob/master/DocumentationGenerator/Program.cs
,,,


Merge pull request #1 from blindpirate/develop

Prepare for publishing

Coverage remained the same at 88.584% when pulling b1ea408f084a0f4f6a0d37672cc1832047fef67e on master into 4419f0b3546e0efba63f24a28cd1a91ca8e12ddd on develop.


Added GRPC example

Hi, I have added a basic GRPC example (#96).
I took reference of the Java and Go example and used GRPC::ServerInterceptor for injecting the trace logic. Other parts are mostly copied from Ruby GRPC example (with some modifications), including the .proto file and server/client implementation.
I have 2 parts I am not sure about, which would like to seek some suggestions/guidance:

How the parent context should be extracted? I saw in the http example it uses OpenTelemetry.propagation.http.extract(env), should I add grpc util or just extract it from call.metadata in the Interceptor. Also, what metadata should I extract from there?
Should I assign the grpc status to span status when error happens?

I found that protobuf seems to have issue with Ruby 2.7 (https://github.com/protocolbuffers/protobuf/issues/7070). I will test further see if it is my configuration or protobuf issue.
Any feedback is welcome, it is my first time contribution. Thank you very much.

Thanks for working on this!
The protobuf issue with Ruby 2.7 has been a blocker for us (Shopify) too. I’ll check internally to see if and how we’re working around it.
Assigning grpc status to span status is required: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/rpc.md#status
The semantic conventions for gRPC are documented here: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/rpc.md#grpc
The specification doesn’t describe how propagation is supposed to work with gRPC, but the Go implementation simply sets the keys in the metadata. I think we want to use the text propagators rather than http for that, since the latter (for Ruby) expects Rack formatted keys. @mwear can definitely correct me on that.

Thanks @fbogsany for pointing out the spec.
For the span name, as the grpc lib will underscore the rpc method name (https://github.com/grpc/grpc/blob/v1.28.1/src/ruby/lib/grpc/generic/service.rb#L98), we have to camelize it back.
For the peer attributes, we only have a string containing both the ip address and port so I added a regex to parse it.

I also assigned the context to be OpenTelemetry.propagation.text.extract(call.metadata), not sure if I am doing it right.

I have studied the Go implementation again and did some adjustments:

opentelemetry-go made the grpctrace a plugin (https://github.com/open-telemetry/opentelemetry-go/tree/master/plugin/grpctrace) which contains the server/client interceptors for different scenarios. I copied the idea and the interceptors are grouped under a single module GRPCTrace under the example lib folder which can potentially be extracted out in the future
Understand better about the context propagation, used the OpenTelemetry.propagation.http.inject and OpenTelemetry.propagation.http.extract for the propagation in the interceptors (referencing Go implementation again)

Two hacks are needed so far because the grpc interceptors does not have enough info exposed (it is still an experimental API) for building the span:

For client interceptor, it can't access the peer info from the call so instance_variable_get needs to be used to access underlying data
For server interceptor, the RPC method name is lost (which is available for client interceptor). Right now, I try to reconstruct it from the actual method object

I will continue to explore for StreamServer and StreamClient

@pinglamb are you still working on this?

I can continue to work on this, any comments so far? Thanks!

I can continue to work on this, any comments so far? Thanks!

@pinglamb have any progress with this one?

Hi @pinglamb! 👋  We've moved code related to instrumentation into a different repo: open-telemetry/opentelemetry-ruby-config
We appreciate your PR and would be happy to take another look in that context. Thank you!


Error 402 "Payment Required"

When trying to access the website linked in the description and readme, the page fails the load and gives back the error in the title.

Hello, thanks for raising this up! I will reach out to vercel for this.

The website should be up and working now, thanks!


feat(ui/picker): Picker of colums add deep watch

Checklist

[ ] Fix linting errors
[ ] Tests have been added / updated (or snapshots)

Change information

for https://github.com/varletjs/varlet/issues/560

Codecov Report

Merging #572 (1818cf7) into dev (b5c13ec) will decrease coverage by 0.72%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #572      +/-   ##
==========================================
- Coverage   95.85%   95.13%   -0.73%
==========================================
  Files         217      217
  Lines        5257     5257
  Branches      984      989       +5
==========================================
- Hits         5039     5001      -38
- Misses        211      249      +38
  Partials        7        7

Impacted Files
Coverage Δ

packages/varlet-ui/src/picker/Picker.vue
96.02% <ø> (ø)

packages/varlet-ui/src/card/Card.vue
60.00% <0.00%> (-40.00%)
:arrow_down:

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 b5c13ec...1818cf7. Read the comment docs.


If viewController.modalPresentationStyle is custom

If UIViewController modalPresentationStyle is custom/currentContext/overCurrentContext
UIWrapperView.backgroundColor is clear or dimmed color
After pushing the viewController,
there is a case in which the backgroundColor changes to white
when pop and return to the original page.

PR 123

PR-124


fix(help): don't show ARGS when there are only hidden positional args

Also no need to check for Hidden inside for that already is filtered
on !Hidden.
Closes #882

Coverage increased (+0.01%) to 91.566% when pulling 55c11c01bdfbeff9a253ac7c4df324a0c23780df on andete:all_args_hidden into 7b08a0a5832c4900eb84bc5a9abfb258c1636f2e on kbknapp:master.

Thanks! Sorry for the long response, I've been traveling for work. I've merged your commit into my bigger rollup PR (#886)


Use of OpenFL/Flash results in multiple unclosed processes

(source: http://community.openfl.org/t/many-instances-of-neko-exe-running-neko-wont-close-when-flash-player-is-closed/9773/11)
It sounds like we need:

...to know that FlashDevelop is calling our tools, using an environment variable, and to disable tracing in that instance. Is there one?
...to have FlashDevelop use OpenFL's trace output, instead of its own
...or to add -notrace when FlashDevelop calls openfl run
...to figure out why FlashDevelop's background processes are not cleanly exiting on the OpenFL/Flash target

One or more of the above should likely fix the problem. Let me know if I can help :smile:

@SlavaRa, @Neverbirth?

I will tackle this issue tomorrow.

@Meychi @jgranick I'll start work on this task on Monday, I'll keep you posted


Remove docs about overriding current_timestamp type when Trino's iceberg implementation supports TIMESTAMP(3)

Describe the feature
The following issue in: Trino https://github.com/trinodb/trino/issues/6658 requires us to override the current_timestap macro for the Iceberg catalog.

Trino uses 3 digits of subsecond precision in Date and time functions, but Iceberg expects timestamp with 3 digits of subsecond precision.
As a result we can't create Iceberg table from Trino
create table iceberg.examples.test
as select now() as n;
Exception:
Timestamp precision (3) not supported for Iceberg. Use "timestamp(6) with time zone" instead.

Once this issue is resolved, we can remove this documented limitation.
Describe alternatives you've considered
No response
Who will benefit?
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

I just tried making a dbt snapshot with a dbt-trino connector that eventually end up in iceberg files.
Underlying, dbt snapshots use current_timestamp, so I also got the following error:
13:58:41    TrinoUserError(type=USER_ERROR, name=NOT_SUPPORTED, message="Timestamp precision (3) not supported for Iceberg. Use "timestamp(6) with time zone" instead.", query_id=20221228_135841_01246_szyby)

I then modified the current_timestamp macro in the dbt-trino adapter by casting to timestamp(6), as in https://github.com/RobbertDM/dbt-trino/commit/6e8d13d8395676de9711513aff56f438b837f89e
Do I get correctly from this thread and the one linked above that this problem will soon be resolved, and this modification to the current_timestamp will not be necessary anymore?

I dove a bit deeper and had some additional issues with current_timestamp. When taking a snapshot, it would always put a wrong updated_at field in the snapshot table, always off by one hour. That is because it appears to take the UTC date and then cast it to timestamp(6) (which is the same as timestamp(6) without time zone).
When using with time zone as in https://github.com/starburstdata/dbt-trino/pull/204/files , the timestamps are nicely stored as UTC. I opened a PR https://github.com/starburstdata/dbt-trino/pull/204.

Note that current_timestamp already returns timestamp with time zone. See trino docs.
To make it compatible with Iceberg you should just override the macro as mentioned in the docs.
{% macro trino__current_timestamp() %}
    current_timestamp(6)
{% endmacro %}

Thanks! Indeed, the cast is unnecessary. Changed it in the PR.
Do you think it makes sense to have current_timestamp(6) there by default, so that not every iceberg user has to manually modify a macro file right after running pip install dbt-trino? Would it break anything to have current_timestamp(6) in there?
Or does the above thread (linked in your original post) resolve the issue altogether?

iMHO we shouldn't switch the default behaviour to suit Iceberg. Changing it will break behaviour for Delta and Hive.
Ideally it is solved in the engine itself. I have filed a PR on Trino to fix this but it still under review.

Ok, thanks a lot for following up so quickly! :)

I found another case where this timestamp(3) vs. timestamp(6) with time zone thing causes trouble. If you run dbt snapshot on a source table, then add a timestamp(6) with time zone column, run dbt snapshot again, it will get into this do create_columns statement at https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/include/global_project/macros/materializations/snapshots/snapshot.sql#L44-L58
I believe that either there, or in https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/include/global_project/macros/materializations/snapshots/helpers.sql#L11 , a part of this data type gets lost, because the query that's eventually run on starburst is alter table "iceberg"."dbt_snapshots"."my_snapshot" add column "extract_ts" timestamp with time zone.
So somewhere, this (6) gets lost 🤔
Of course, that results in
TrinoUserError(type=USER_ERROR, name=NOT_SUPPORTED, message="Timestamp precision (3) not supported for Iceberg. Use "timestamp(6) with time zone" instead.", query_id=20230127_150706_02226_b7axv)

Good find. I don't think dbt-trino implements get_missing_columns it looks like it's being taken from dbt-core, so I assume that you should create an issue there.

I will, thank you!

Ah indeed, it seems like https://github.com/starburstdata/dbt-trino/blob/fa901faf6f48f14d812b8cd5796b7a4964ea03d7/dbt/adapters/trino/column.py#L32-L36
is the culprit.
I'm not sure why you're rebuilding the data type from the regex matches instead of passing on the raw one, @damian3031  ?

The reason is that from_description should return data_type and char_size (or scale and precision) as separate tuple elements. So, if raw_data_type argument is timestamp(6) with time zone, this method returns timestamp with time zone as data_type and 6 as char_size.
I think that it is correct implementation regarding purpose of this method.
I will take closer look at this specific use case, maybe we should somehow adjust this method or code which is invoking it.

I think it will be safer to not alter the type if not string or numerical. I think dbt only widens string types. The variable name charsize seems also to point to that.

So do you mean to extend this condition to sth like:
if raw_data_type.startswith(("array", "map", "row", "date", "time", "interval", "boolean")):
    return cls(name, raw_data_type)

@mdesmet?

The reason is that from_description should return data_type and char_size (or scale and precision) as separate tuple elements. So, if raw_data_type argument is timestamp(6) with time zone, this method returns timestamp with time zone as data_type and 6 as char_size. I think that it is correct implementation regarding purpose of this method. I will take closer look at this specific use case, maybe we should somehow adjust this method or code which is invoking it.

Is there a spec somewhere that describes this? I find it a bit weird to chop the datatype in pieces 🤔
I'm using https://github.com/calogica/dbt-expectations/blob/main/macros/schema_tests/column_values_basic/expect_column_values_to_be_in_type_list.sql right now, and again failing because I have columns that are DECIMAL(20,4), but in there, they also just call adapter.get_columns_in_relation and access only the dtype fields.
Could it be an option to fill in char_size where needed, but always return raw_data_type as data_type?

Btw I also have this problem with varchar(20).

Hmmm, trino itself seems to indeed separate the datatype:
https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/adapters/base/column.py#L124-L160
Then I guess dbt-expectations is wrong in only accessing dtype

Apparently, the solution is to use column.data_type, not column.dtype.
See https://docs.getdbt.com/reference/dbt-classes#column and https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/adapters/base/column.py#L41

^ this is me discovering the difference between data_type and dtype 🤦
In the snapshot logic, it already uses data_type so you can ignore my last 4 comments.
Sorry for the noise. Carry on :-)

Once this Trino pr is merged, we can remove those docs.


fix onGKE to use the cluster location, as name may be registered

Fixes #906

/gcbrun

CLA passes.

/gcbrun


Added information about ephemeral responses

Thanks for the contribution :) These docs make a lot of mention about Discord.js v14, slasher still currently only supports v13. I'm working on upgrading the package to v14 then I'll get your docs incorporated.

Merged! Thanks for the contribution :)


More explicit logging messages for OVM manifest errors

This change logs the error that caused the OVM spec to be invalid.

retest this

retest this please

retest this please

Labels are no longer required by the OfflineVirtualMachine controller (see https://github.com/kubevirt/kubevirt/pull/828). Odds of a user encountering this error condition are much less likely and much less unclear now.


nice proposal!

 Nice!
Please have a look at my suggestions from the commits. The main is that you should use levels (for rates) and log-levels of the series and not differentiate them. Thanks!
All the best, Tomasz

Hi, Tomasz
Thanks to your feedback and probably I may try to use Minnesota Prior in the following model instead of differentiate them. (I seems did something wrong when i merged the the pull request and hopes it has solved in a correctly way.)
Best,
Qingqing


Dynamically compile more than just TestCases

You can now specify a list of types in a TestCase to get dynamic recompilation support for those classes.

👍 let's get this show on the road

🔥  WOOOOO 🚒


[BUG] When the Weather is unavailable it kills Fastfetch

I apologise if someone else has reported this already.
Occasionally the weather is unavailable and when this happens Fastfetch hangs at that point.
When the weather module is commented out, Fastfetch resumes working.
Since Fastfetch is dependent on an external source/provider to get the weather, it might be useful to give the module a timeout, if possible.
Cheers
Mac

timeout of Weather module is already supported in Linux, FreeBSD and Windows.

Thanks. Found it. Got it working.


How many bytes are needed to make a determination?

Based on my testing, it seems the number of bytes needed to retrieve the metadata about the image varies. Is there some some maximum or is there no cap on the number of bytes needed before we are able to make a determination on image size?
I'm in a situation where I'd like to retrieve the metadata using probe-image-size from a stream and then continue (without creating a brand new stream) streaming the data into some transformations. In order to do this, I think the best way would be to use a PassThrough to buffer the data needed by probe-image-size before sending off to the transformations. So it looks something like this:
const readPassThrough = new PassThrough();
const readProxy = pipeline(readStream, readPassThrough, ()=> {});
const fileMetadata = await probe(readStream);
readProxy.pipe(transformer).pipe(writeStream);

The problem I ran into is that probe-image-size fetched about 50815 bytes for a JPEG I tested with before being able to output the image metadata. This is bigger than the default highWaterMark for the PassThrough, which is 16384 bytes. So the PassThrough couldn't accept the 50815 bytes, causing backpressure, which stopped the entire pipeline. So, in order to make this example work, I'd have to use const readPassThrough = new PassThrough({ highWaterMark: 51200 });. I'm wondering if there is some max value I can set highWaterMark to in order to guarantee I wouldn't run into backpressure issues. If not, I may have to just create a new read stream after probing the metadata and accept the performance hit.
Thanks in advance for the help!

There is no guaranteed cap for some formats like jpeg. I'd suggest you to inspect sync versions, those are easy to understand.
Internal parsers eat chunks of any size until succeed or fail. Those consume immediately anything available on input.

@puzrin thanks for the quick response!

I'd suggest you to inspect sync versions, those are easy to understand.

Are you referring to the parsers in the parse_sync directory?
How about GIFs? Based on the gif sync parser it looks like all the metadata is always in the first 10 bytes. Is this correct?

How about GIFs? Based on the gif sync parser

Yes, if you parse gifs only, then 10 bytes will be enough. But such task is very rare in real world.

Ok great. I only really need the width/height before transforming in the case of a GIF, so I can work with that. Thanks for all the help 👍