text:
CalDAV add-on?

Classification
Please delete options that are not relevant.

[ ] Question
[ ] Deliverability issue
[ ] Crash/Hang/Data loss
[ ] Serious bug
[ ] Minor bug
[ ] Vulnerability
[X] Feature/Enhancement
[ ] Documentation

Description
Any plans or do you know of any add-on for a CalDAV server to incorporate? I have been using this for a couple years now, and its been great.

radicale is pretty good. I've it running in the same vps but not inside a docker container.
configured traefik [file] provider to proxy it under SSL
...

[file]
domain = "domain.tld"
watch = true
exposedbydefault = false

[backends]
  [backends.radicale]
    [backends.radicale.servers.radicale]
    url = "http://0.0.0.0:5232/"

[frontends]
  [frontends.radicale]
  backend = "radicale"
    [frontends.radicale.routes.radicale]
    rule = "Host:dav.domain.tld"

authors: iMouath ragboy

repo: hardware/mailserver


text:
[Feature Request] Metrics selection should persist after a refresh

Right now, when you select metrics in the vehicle dashboard, the selection is not persisted so after a page refresh it is reset to the full selection.
It would be nice if the previous selection is saved somewhere (probably the browser's session storage).

Actually, it would be interesting if I tried implementing this (web dev is where I spend most of my time). Do you have documentation somewhere on project setup? I think I can squeeze some time during the next week to implement this.

available in edge tagged docker image.

Released in 1.3.1

source: gharchive/issue

authors: hargata jstebenne

repo: hargata/lubelog

license: MIT

license_type: permissive

license_source: github-api


text:
FFM-7480,FFM-7483: updates ruby, python relnotes

Updates release notes for Ruby SDK v1.1.0, Python SDK v1.1.10

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

source: gharchive/pull-request

authors: StrawberryPad bot-gitexp-user

repo: harness/developer-hub


text:
Doc 2963 tas manifest override

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

authors: bot-gitexp-user roshnisarangadharan


text:
[HDH-159] made cursor pointer in RSS suscribe button

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


text:
FAQ

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.

[x ] Tested Locally

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

authors: bot-gitexp-user lijo-harness


text:
Update computing-uptime.md

Pipeline Executions failure caused by Harness platform	| Failure rate Increase	| More than 50% over 5 min rolling window | Major Outage
Moving this to pipeline-section and not create a separate section for CI
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screenshot.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660c36d5c44ead4c71be298d--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660c38bf3093fd4d988e103d--harness-developer.netlify.app


text:
Upgrade maven-model dependency to 3.5.0 at-least due to CVE-2022-4245

ff-java-server-sdk is getting flagged in our scan for CVE-2022-4245 due to the presence of plexus-utils, 3.0.22 coming from maven-model, 3.3.9
I think the fix would be to upgrade the maven-model dependency to 3.5.0

Thanks for the report, I've raised this internally as FFM-8133 and it will be fixed in the next release

This has been fixed and the PR merged. It will be in version 1.2.3

Thanks @andybharness for a quick fix. Can you please let me know when can I expect 1.2.3 to be released?

@debraj-spotnana If testing goes well we're hoping some point next week

authors: andybharness debraj-spotnana

repo: harness/ff-java-server-sdk


text:
Predict daily returns instead of of price

This might solve the scaling issue

Log returns might work better

repo: harrisonfloam/crypto-trading-algorithm


text:
Add problem 1929 solve and example implementation

Added problem_1929 module.
Added fn solve() function in this module.
Added test cases for examples in this module. e.g.) fn example_1()

@harry-cluml
노션의 "커밋 메세지 작성 규칙" 문서에 명시된 것 처럼 앞으로 pr을 올릴때 연결된 issue가 자동으로 close 되도록 키워드(close,fix...)를 커밋 메세지에 추가해주세요.

@kimhanbeom 아래 스샷들 처럼 머지시 이슈 닫히게 링크 걸어놨는데요! 현재 규약이 꼭 close 키워드를 써야하는거죠...?
이슈 스크린샷

PR 스크린샷

@harry-cluml 노션의 "커밋 메세지 작성 규칙" 문서에 명시된 것처럼 지금 pr의 경우에는 하나의 commit으로 충분하므로 rebase -i 로 하나의 commit 정리해주세요

rebase 완료했습니다! ㅎㅎ

@harry-cluml 네 맞습니다

@kimhanbeom 아래 스샷들 처럼 머지시 이슈 닫히게 링크 걸어놨는데요! 현재 규약이 꼭 close 키워드를 써야하는거죠...?

해당 이슈 내 Fixes 항목으로 추가했습니다!

@harry-cluml 네 맞습니다

@kimhanbeom 아래 스샷들 처럼 머지시 이슈 닫히게 링크 걸어놨는데요! 현재 규약이 꼭 close 키워드를 써야하는거죠...?

해당 이슈 내 Fixes 항목으로 추가했습니다!

키워드를 사용하라는 의미는 issue가 아닌 pr올리는 commit에 추가하라는 의미입니다.

@harry-cluml 네 맞습니다

@kimhanbeom 아래 스샷들 처럼 머지시 이슈 닫히게 링크 걸어놨는데요! 현재 규약이 꼭 close 키워드를 써야하는거죠...?

해당 이슈 내 Fixes 항목으로 추가했습니다!

키워드를 사용하라는 의미는 issue가 아닌 pr올리는 commit에 추가하라는 의미입니다.

다시 설명해주셔서 이해했습니다. 감사합니다!

authors: harry-cluml kimhanbeom

repo: harry-cluml/rust-practice


text:
[BUG] Upgrade: mismatched ISO checksum is not detected and backing image is stuck at in-progress

Describe the bug

This was spotted when testing an upgrade from v1.1.0 to master ISO, and later the remote ISO was updated, so the expected checksum changed.
The download image progress is stuck at 99%.

Checking the VirtualMachineImage
spec:
  checksum: cc6fae7d2103d3748b565eb626eec96bf2ddd29c44d071205405e7d0c4e7d60b73928e7f54f6f40a40bc5b36052e9f384c893a6270d24d50eb2fb3eee75634ed
  displayName: hvst-upgrade-ksdtm-v1.1.0-5a18d059
  pvcName: ""
  pvcNamespace: ""
  sourceType: download
  storageClassParameters:
    migratable: "true"
    numberOfReplicas: "3"
    staleReplicaTimeout: "30"
  url: https://releases.rancher.com/harvester/master/harvester-master-amd64.iso
status:
  appliedUrl: https://releases.rancher.com/harvester/master/harvester-master-amd64.iso
  conditions:
  - reason: Importing
    status: Unknown
    type: Imported
  - lastUpdateTime: "2022-11-08T11:31:18Z"
    reason: Initialized
    status: "True"
    type: Initialized
  progress: 99
  size: 5006032896
  storageClassName: longhorn-harvester-iso-z8rx5

From Longhorn GUI, we can see the backing image has mismatched checksum:

And the backing image resource:
spec:
  checksum: cc6fae7d2103d3748b565eb626eec96bf2ddd29c44d071205405e7d0c4e7d60b73928e7f54f6f40a40bc5b36052e9f384c893a6270d24d50eb2fb3eee75634ed
  disks:
    1e46e345-e065-4cc8-b88e-210320c93823: ""
  imageURL: ""
  sourceParameters:
    url: https://releases.rancher.com/harvester/master/harvester-master-amd64.iso
  sourceType: download
status:
  checksum: a366e973cc346817ac25d62405193072c44f3e6ba0d0565506dede5104b3da711913255ee21ab6284ca38982083b3bebf21dcd91b685619a3a9a3e3d234e7e01
  diskDownloadProgressMap: null
  diskDownloadStateMap: {}
  diskFileStatusMap:
    1e46e345-e065-4cc8-b88e-210320c93823:
      lastStateTransitionTime: "2022-11-08T11:31:26Z"
      message: ""
      progress: 100
      state: in-progress
  diskLastRefAtMap:
    1e46e345-e065-4cc8-b88e-210320c93823: "2022-11-08T11:31:18Z"
  ownerID: harvester-z622q
  size: 5006032896
  uuid: 21e8526b

The state is in-progess.
To Reproduce
Steps to reproduce the behavior:

Create a version with mismatched checksums, for example, the isoChecksum has a wrong value:

apiVersion: harvesterhci.io/v1beta1
kind: Version
metadata:
  name: v1.1.0-5a18d059
  namespace: harvester-system
spec:
  isoChecksum: cc6fae7d2103d3748b565eb626eec96bf2ddd29c44d071205405e7d0c4e7d60b73928e7f54f6f40a40bc5b36052e9f384c893a6270d24d50eb2fb3eee75634ed
  isoURL: https://releases.rancher.com/harvester/master/harvester-master-amd64.iso
  releaseDate: '20221108'

Upgrade to the version.

Expected behavior

The checksum mismatched should be detected,  and the upgrade should fail, not stuck at 99%.
Support bundle

supportbundle_8aab8f77-c143-4518-9c7e-239decd2aeda_2022-11-08T14-33-21Z.zip
Environment

Harvester ISO version: master 5a18d059
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Create a dependency issue: https://github.com/longhorn/longhorn/issues/4852

@bk201 Just to understand the functionality, is the check of mismatched checksum included in the precheck of the upgrade?

It's worth noting that when I was testing this I put in the accurate checksum to my version.yaml file. It's just that the ISO was corrupt in some way so the checksum didn't match the distributed on on the release page. However I ran the checksum on my local ISO and it was correct in the yaml. It allows you to set it like you do in an AirGapped upgrade.

@bk201 Just to understand the functionality, is the check of mismatched checksum included in the precheck of the upgrade?
@khushboo-rancher Yes!

The issue is ready for testing with v1.2.0-rc3 since we bump LH.

Reproduced in v1.1.0, will test in v1.2.0-rc3.
Test Environment

Harvester

version: v1.1.0
profile: QEMU/KVM, single node (8C/16G/250G)
ui-source: Auto

Verification

Prepare an air-gapped upgrade w/ wrong checksum
Ref. https://docs.harvesterhci.io/v1.1/upgrade/automatic#prepare-an-air-gapped-upgrade

harvester-v1.2.0-rc3-version-wrongmd5.yamlapiVersion: harvesterhci.io/v1beta1
kind: Version
metadata:
  name: v1.2.0-rc3
  namespace: harvester-system
spec:
  isoChecksum: 'f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb7777777777777777777777777777777777777777777777777777777777777777777777'
  isoURL: http://172.17.0.1:8080/harvester-v1.2.0-rc3-amd64.iso
  releaseDate: '20230707'

Correct checksum is f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb77af706f03f4b67eace5d13dce5791edb055ca63f7df4d6cc8122b8780657e867af749

In Harvester UI, trigger Upgrade.
Upgrade should fail due to mismatched checksum. $~~$ :x: $\color{red}{\textsf{Upgrade stuck at Download Upgrade Image 99%}}$

Note

Longhorn shows backing image has mismatched checksum

k8s BackingImage shows 100% in-progress$ kubectl -n longhorn-system describe BackingImage/harvester-system-harvester-iso-fsxwn
...
Spec:
 Checksum:  f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb7777777777777777777777777777777777777777777777777777777777777777777777
 Disks:
   942b905a-ddc2-4ea7-bf82-e1996aee431c:
 Image URL:
 Source Parameters:
   URL:        http://172.17.0.1:8080/harvester-v1.2.0-rc3-amd64.iso
 Source Type:  download
Status:
 Checksum:                    f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb77af706f03f4b67eace5d13dce5791edb055ca63f7df4d6cc8122b8780657e867af749
 Disk Download Progress Map:  <nil>
 Disk Download State Map:
 Disk File Status Map:
   942b905a-ddc2-4ea7-bf82-e1996aee431c:
     Last State Transition Time:  2023-07-17T02:59:51Z
     Message:
     Progress:                    100
     State:                       in-progress
...

Tested in v1.2.0-rc2 with single & 3 nodes profile, close as fixed.
Test Environment

Harvester

version: v1.2.0-rc2
profile: QEMU/KVM, 8C/16G/250G per node

single node
3 nodes

ui-source: Auto

Upgrade Target

version: v1.2.0-rc3
checksum: f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb77af706f03f4b67eace5d13dce5791edb055ca63f7df4d6cc8122b8780657e867af749
Ref. https://docs.harvesterhci.io/v1.1/upgrade/automatic#prepare-an-air-gapped-upgrade

Verification

Note Click "▸" to expand details.

Prepare an air-gapped upgrade to v1.2.0-rc3 w/ wrong checksum
harvester-node-0:~ # kubectl create -f http://172.17.0.1:8080/harvester-v1.2.0-rc3-version-wrongcs.yaml
version.harvesterhci.io/v1.2.0-rc3 created

harvester-v1.2.0-rc3-version-wrongcs.yaml
apiVersion: harvesterhci.io/v1beta1
kind: Version
metadata:
  name: v1.2.0-rc3
  namespace: harvester-system
spec:
  isoChecksum: 'f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb7777777777777777777777777777777777777777777777777777777777777777777777'
  isoURL: http://172.17.0.1:8080/harvester-v1.2.0-rc3-amd64.iso
  releaseDate: '20230707'

Trigger upgrade to v1.2.0-rc3

Upgrade should fail due to mismatched checksum $~~$ :heavy_check_mark:
hvst-upgrade-h7hfx-upgradelog-archive-2023-07-17T06-44-57Z.zip

Prepare an air-gapped upgrade to v1.2.0-rc3 w/ correct checksum
harvester-node-0:~ # kubectl create -f http://172.17.0.1:8080/harvester-v1.2.0-rc3-refresh-version.yaml
version.harvesterhci.io/v1.2.0-rc3-refresh created

harvester-v1.2.0-rc3-refresh-version.yaml
apiVersion: harvesterhci.io/v1beta1
kind: Version
metadata:
  name: v1.2.0-rc3-refresh
  namespace: harvester-system
spec:
  isoChecksum: 'f9c163a9a11e65f141892006bc147fed5f832158fcdf741b6ef9ac11bb77af706f03f4b67eace5d13dce5791edb055ca63f7df4d6cc8122b8780657e867af749'
  isoURL: https://releases.rancher.com/harvester/v1.2.0-rc3/harvester-v1.2.0-rc3-amd64.iso
  releaseDate: '20230707'

Trigger upgrade to v1.2.0-rc3-refresh

Upgrade should success $~~$ :heavy_check_mark:

Download Upgrade Image $~~$ :heavy_check_mark:

Upgrading System Service $~~$ :heavy_check_mark:

Upgrading Node $~~$ :heavy_check_mark:

Note

Test also passes in 3 nodes cluster

Upgrade fails due to mismatched checksum $~~$ :heavy_check_mark:
hvst-upgrade-lngzb-upgradelog-archive-2023-07-17T09-22-54Z.zip

Backing image is cleaned.
harvester-node-0:~ # kubectl -n longhorn-system get BackingImage
No resources found in longhorn-system namespace.

Upgrade success with correct checksum $~~$ :heavy_check_mark:

Trigger Upgrade

Download Upgrade Image

Upgrading System Service

Upgrading Node

authors: albinsun bk201 khushboo-rancher noahgildersleeve

repo: harvester/harvester


text:
implementing injured_accidents_with_pedestrians in accordance with issue spec

sample API call can be something like 127.0.0.1:8080/api/infographics-data?news_flash_id=16577&years_ago=8&lang=en
sample redash query on which I based this PR
IMPORTANT: As it currently stands, for SubUrbanWidgets such as this, the is_relevant() method is simply is_sub_urban() which checks for the presence of "road1" and "road_segment_name", which do not match the condition of "street1/2_hebrew" having value, which is required for matching with the "involved_markers_hebrew" table (see SQLAlchemy below). Maybe we should make InjuredAccidentsWithPedestriansWidget inherit Widget instead of SubUrbanWidget?

@atalyaalon , regarding this comment, I have a question about injured_type:
Does a code has same injured_type_hebrew, regardless of its year and provider_code? What is the meaning of these fields?

@atalyaalon , regarding this comment, I have a question about injured_type:
Does a code has same injured_type_hebrew, regardless of its year and provider_code? What is the meaning of these fields?

that's a good question - if you query the table injured_type you can see that any id has only one value - see here
however when you query the table accident_type  you can see that there are a few ids with multiple values (however with the same meaning) - see here
We will add in the coming future data tests to verify that the CBS are backward compatible and be alerted on changes they are making.

I also suggest creating an issue for localizing the widget (we'll add it in the next pr not this one)

lgtm! great work!
small question - what's the average widget performance? how long does it take to calculate it?

Running locally with the full DB it takes ~2.5 secs but I think this is not the best way to benchmark

authors: atalyaalon shaysw ziv17

repo: hasadna/anyway


text:
fix: locale direction

Description
Closes #331
screenshots

I've updated the original post with a Hebrew screenshot @NoamGaash

repo: hasadna/open-bus-map-search


text:
Removes hethers since it is deprecated

Description:
This pull request involves the elimination of hethers' usages throughout the codebase.
Related issue(s):
Fixes #1524
Checklist

[x] Tested (unit, integration, etc.)

Codecov Report
Patch coverage: 60.00% and project coverage change: +0.22% :tada:

Comparison is base (036deb1) 78.02% compared to head (f50e03b) 78.24%.

:exclamation: Current head f50e03b differs from pull request most recent head 076a10d. Consider uploading reports for the commit 076a10d to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1559      +/-   ##
==========================================
+ Coverage   78.02%   78.24%   +0.22%
==========================================
  Files          32       32
  Lines        2621     2625       +4
  Branches      541      544       +3
==========================================
+ Hits         2045     2054       +9
+ Misses        410      405       -5
  Partials      166      166

Files Changed
Coverage Δ

packages/relay/src/lib/eth.ts
85.29% <50.00%> (+0.42%)
:arrow_up:

packages/relay/src/lib/clients/mirrorNodeClient.ts
89.48% <100.00%> (ø)

... and 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter konstantinabl

repo: hashgraph/hedera-json-rpc-relay


text:
Pad slot value on comparison

Signed-off-by: nikolay n.atanasow94@gmail.com
Description:

Related issue(s):
Fixes #769
Notes for reviewer:

Checklist

[x] Documented (Code comments, README, etc.)
[x] Tested (unit, integration, etc.)

Codecov Report
Base: 72.87% // Head: 72.85% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (1bd9687) compared to base (75dc43f).
Patch coverage: 83.33% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #770      +/-   ##
==========================================
- Coverage   72.87%   72.85%   -0.02%
==========================================
  Files          16       16
  Lines        1246     1249       +3
  Branches      231      234       +3
==========================================
+ Hits          908      910       +2
  Misses        280      280
- Partials       58       59       +1

Impacted Files
Coverage Δ

packages/relay/src/lib/eth.ts
83.62% <83.33%> (-0.10%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

I think the mirror-node images should be updated to 0.70.0 in order for the getStorageAt test to pass, because 0.69.0 does not include this PR https://github.com/hashgraph/hedera-mirror-node/pull/4881


text:
CSV file should include all transaction value fields

Problem
Currently, the CSV file allows a user to configure the sender account, submission time, node account IDs, and list of receiving accounts for a transfer transaction.
Users should be able to set the following transaction values in the CSV file.

Transaction memo
Max transaction fee
Transaction valid duration
Fee payer

Solution
See above.
Alternatives
No response

@SimiHunjan @mark-hedera
These are the changes to the CSV:

Added a field Transaction Fee: The fee must be entered in tinybars. If the field is not present, the app will use the default (backwards compatibility)
Added the field Transaction Valid Duration: an int from 1 to 180. If the field is not present, the app will use the default (backwards compatibility)
Added the field Fee Payer Account: a string of the form XX.XX.XXXX. If the field is not present the app will use the Sender Account field.
Added the field Memo: a string. If the field is not present, the app will not add a memo to the transactions
Removed the requirement for the CSV fields to be in order. Going forward the only requirement is that the distribution is after the common fields.
testNewCSV.csv

authors: DSMatusevich SimiHunjan

repo: hashgraph/hedera-transaction-tool-demo


text:
ReadableStreamingData should implement bulk read methods

Problem
ReadableStreamingData should implement efficient versions of the InputStream bulk read methods.
    public long readBytes(@NonNull byte[] dst) {
    public long readBytes(@NonNull final byte[] dst, final int offset, final int maxLength) {

As the default just call read() in a loop which is not idea. Most InputStream sub classes like FileInputStream have efficient implementations
Solution
Something like this maybe
    /** {@inheritDoc} */
    @Override
    public long readBytes(@NonNull byte[] dst) {
        return readBytes(dst, 0, dst.length);
    }

    /** {@inheritDoc} */
    @SuppressWarnings("DuplicatedCode")
    public long readBytes(@NonNull final byte[] dst, final int offset, final int maxLength) {
        if (maxLength < 0) {
            throw new IllegalArgumentException("Negative maxLength not allowed");
        }
        // return 0 if there is no data remaining to be read
        if (!hasRemaining()) return 0;

        int maxReadable = Math.min((int)Math.min(Integer.MAX_VALUE,remaining()), maxLength);
        try {
            int readBytes =  in.read(dst,offset,maxReadable);
            // our spec differs from InputStream that we return 0 when no bytes available to read because we reached
            // end of the file.
            if (readBytes == -1) {
                eof == true;
                return 0;
            }
            return readBytes;
        } catch (IOException e) {
            throw new DataAccessException(e);
        }
    }

Alternatives
No response

It appeared to be slightly more complicated than the proposed code snippet above. The issue is with eof. The streaming object is expected to reach EOF even if it was able to read some bytes. That it, checking the result of in.read() against -1 is not enough. There is test for that: it creates a byte array input stream over an array of 10 elements, then tries to read 12 bytes from it. 10 bytes are expected to be read (this is fine), but in addition to that, hasRemaining() is expected to be false. With the proposed implementation above it will be true: eof is still false, and position (10) is less than limit (which is usually Long.MAX_VALUE for streaming data, but in this particular test is set to 12).

authors: artemananiev jasperpotts

repo: hashgraph/pbj


text:
Tempus 701 computations

This PR contains three kubeless functions(computations) :

Mud pressure calculation.
Equivalent Circulating Density Calculation.
Bit on Bottom calculation.

Thank you for submitting a contribution to Tempus.
In order to streamline the review of the contribution please
ensure the following steps have been taken:
For all changes:

[ ] Is there a Waffle ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with Tempus-XXXX where XXXX is the waffle number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically dev)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn clean install at the root Tempus folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] Have you added documentation for any UI or API related changes to the /docs folder

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: anuj-akt:white_check_mark: Himanshu-it:x: pal-abhishekYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant Himanshu-it

repo: hashmapinc/Tempus


text:
Ability to pass --force to GHCup

I want to use LLVM backend on GitHub Actions, so trying to install GHC with OPT and LLC set:
      # GHC <= 9.8 needs LLVM 12: https://gitlab.haskell.org/ghc/ghc/-/issues/23870
      - name: Install LLVM 12 with Homebrew
        run: |
          brew install llvm@12
          echo "OPT=$(brew --prefix llvm@12)/bin/opt" >> "${GITHUB_ENV}"
          echo "LLC=$(brew --prefix llvm@12)/bin/llc" >> "${GITHUB_ENV}"
        if: ${{ (matrix.os == 'macos-13' || matrix.os == 'macos-14') && (matrix.ghc == '9.6' || matrix.ghc == '9.8') }}

      - name: Install LLVM 12 with APT
        run: |
          sudo apt-get install llvm-12 clang-12
          echo "OPT=opt-12" >> "${GITHUB_ENV}"
          echo "LLC=llc-12" >> "${GITHUB_ENV}"
          echo "LLVMAS=clang-12" >> "${GITHUB_ENV}"
        if: ${{ matrix.os == 'ubuntu-22.04' && (matrix.ghc == '9.6' || matrix.ghc == '9.8') }}

      - name: Install LLVM 15 with Homebrew
        run: |
          brew install llvm@15
          echo "OPT=$(brew --prefix llvm@15)/bin/opt" >> "${GITHUB_ENV}"
          echo "LLC=$(brew --prefix llvm@15)/bin/llc" >> "${GITHUB_ENV}"
        if: ${{ (matrix.os == 'macos-13' || matrix.os == 'macos-14') && (matrix.ghc == '9.10' || matrix.ghc == '9.12') }}

      - name: Install LLVM 15 with APT
        run: |
          sudo apt-get install llvm-15 clang-15
          echo "OPT=opt-15" >> "${GITHUB_ENV}"
          echo "LLC=llc-15" >> "${GITHUB_ENV}"
          echo "LLVMAS=clang-15" >> "${GITHUB_ENV}"
        if: ${{ matrix.os == 'ubuntu-24.04' && (matrix.ghc == '9.10' || matrix.ghc == '9.12') }}

      - uses: haskell-actions/setup@v2
        name: Setup Haskell
        with:
          ghc-version: ${{ matrix.ghc }}

...but this does not seem to work if GHC is already installed in the runner image. Passing --force to GHCup may improve the situation.
Is there a way to pass --force to GHCup?

Not that I would know of.
As a workaround, you could install GHC via GHCup directly, as e.g. in https://github.com/haskell/unix/blob/dcf19781244a569b5b9da71e6c47f65f5c10705c/.github/workflows/ci.yml#L31-L33

Another workaround for using LLVM would be, passing -pgmlo $OPT and -pgmlc $LLC to GHC.
Now there is ghcup-setup: https://discourse.haskell.org/t/ghcup-setup-github-marketplace/11078 I will try it.
I'm going to close this issue because there are several workarounds. If anyone else thinks haskell-actions/setup should have an option for --force, he or she can reopen it.

Would it make sense to always pass --force or do can you think of examples where this would be a bad idea?

authors: andreasabel minoki

repo: haskell-actions/setup


text:
Add some release notes?

I have no idea how to make a release of this code to wherever it lives in prod.
@chrisdone, thoughts?

We could add something to the scripts/ to check for new releases and clone and restart accordingly.

Just cleaning up my issues list ....

repo: haskellnews/haskellnews

license_source: bigquery


text:
why you are using .gz files

why are my tfrecords are saying corrupted everytime

You may check your code read the files with 'GZIP' in tf.data.TFRecordDataset(file_paths, compression_type='GZIP')


text:
CODE RUB: ChatCompletionDependencyValidationException Class Update v2.10.1

Updated ChatCompletionDependencyValidationException class by removing constructors in which the error message was hard coded in. Updated all relevant service files to include message.

Closed Pull Request. Resolved in PR #556.


text:
Portainer is not able to download extensions manifest on clean HassOS install

Problem/Motivation
Portainer is not able to download extensions from internet on a clean installation of Home Assistant.
This seems to be quite similar to #33 except I'm doing this on a clean install, not a snapshot recovery.
The link to the solution/workaround is broken (unixblogger.com domain now redirects to startpage.com), and since it's not documented anywhere else (should have been included on the documentation for this addon!)
Steps to reproduce

Install Home Assistant OS 5.13 (RPi 4/400) using Raspberry Pi Imager
Perform initial setup
Setup Raspberry Pi 4 using WiFi rather than ethernet

Set user to advanced mode
Install "SSH & Web Terminal Addon"
Disable protection mode in the addon
Configure addon with a random password (ssh.password parameter)
Run command: nmcli device wifi connect "YOUR_SSID" password "YOUR_WIFI_PASSWORD"

Install and configure Portainer

Disable protection mode
Navigate to Extensions page
Witness the error Portainer must be connected to the Internet to fetch the list of available extensions.

The problem persists if, after those steps, I connect the Raspberry Pi via ethernet. So, Wifi may not be the problem, as in #33 .

The add-on does not provide connection to the internet, that is not an add-on responsibility or concern. Please report your issue with the upstream project.

@frenck Would the upstream project be https://github.com/home-assistant/operating-system ?

authors: frenck joaomlneto

repo: hassio-addons/addon-portainer


text:
core: give up updating a lock file of an unsupported version

Apparently lockfile v4 is comming soon so

Closed by #218

repo: hasundue/molt


text:
fix sidebar active element highlighting

The highlighting of active element on the left sidebar doesn't seem to work. It's probably an issue with URL matching that ends without slashes.

#22 causes gatsby build to fail.
Building static HTML failed for path "/"

See our docs page for more info on this error: https://gatsby.dev/debug-html

   5 | import Link from "../link";
   6 |
>  7 | const TreeNode = ({className = '', setCollapsed, collapsed, url, title, items, location = document.location, ...rest}) => {
     |                                                                                ^
   8 |   const isCollapsed = collapsed[url];
   9 |   const collapse = () => {
  10 |     setCollapsed(url);

  WebpackError: ReferenceError: document is not defined

@i001962 - Thanks for pointing out. Builds failed obviously because document is available only on the client and not during build phase. Fixed it via https://github.com/hasura/gatsby-gitbook-starter/commit/0c4d89437e509270a711cf90d8ba8a83a084a01f

repo: hasura/gatsby-gitbook-starter


text:
Using date/time fields

Hi, I'm facing an issue when trying to pass time.Time values as variables during a query:
type Record struct {
	ID	string `graphql:"id"`
	CreatedAt time.Time `graphql:"created_at"`
}
type Query struct {
	Record []Record `graphql:"record(where:{created_at: {_gte: $gte, _lte: $lte}})"`
}

err := client.Query(context.Background(), &query, map[string]interface{}{
	"gte": time.Now(),
	"lte": time.Now(),
})

The following error shows up:
% go run main.go
panic: Message: variable "gte" is declared as Time!, but used where timestamptz is expected, Locations: []

Same error occurs if I pass a string version of the date as gte. Wandering what's the appropriate way here.

@matiasinsaurralde you can set the alias, or define a custom type with GetGraphQLType method https://github.com/hasura/go-graphql-client#specify-graphql-type-name
type timestamptz time.Time

type Record struct {
	ID	string `graphql:"id"`
	CreatedAt timestamptz `graphql:"created_at"`
}
type Query struct {
	Record []Record `graphql:"record(where:{created_at: {_gte: $gte, _lte: $lte}})"`
}

err := client.Query(context.Background(), &query, map[string]interface{}{
	"gte": timestamptz(time.Now()),
	"lte": timestamptz(time.Now()),
})

@hgiasac Thanks. Closing this one.

I'm trying to update the updated_at value using the Mutate method.
and the solution provided did not work for me, and it throws the following exception:
   `parsing UTCTime failed, expected String, but encountered Object, Locations: []`

The reason behind it is the value of timestamptz(time.Now())  is equivalent to time.Time{} object, and hasura is waiting for String to be parsed. knowing that sending a string will throw the following error:
variable 'time' is declared as 'String!', but used where 'timestamptz' is expected, Locations: []
Building the query inside the buildAndRequest method do the job, but cannot handle having the 'timestamptz' to be sent as String.
If there are no solution, a possible solution might be by editing the queryArguments in ConstructMutation method, to make optional parsing of the arguments manually by the developer(similar to OptionType ..eg.. OperationName implementation by providing the Arguments' names as another Option), rather than only parsing it using only  the implemented code.

authors: NajyFannoun hgiasac matiasinsaurralde

repo: hasura/go-graphql-client


text:
Use Rust 1.77.0

What
Upgrade to use Rust 1.77.0
https://github.com/rust-lang/rust/releases/tag/1.77.0

cargo machete is having a bad time now, maybe a bug? https://github.com/hasura/ndc-postgres/actions/runs/8393753764/job/22989435799?pr=378#step:5:12

repo: hasura/ndc-postgres


text:
--purge-with-truncate fails because of foreign key constraints

Hi, I am experiencing this with v2.0.0-beta.3...
# ./bin/console hautelook:fixtures:load -n --purge-with-truncate

  [Doctrine\DBAL\Exception\ForeignKeyConstraintViolationException]
  An exception occurred while executing 'DELETE FROM fos_user':
  SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`some_database_name`.`some_table`, CONST
  RAINT `FK_C7440455D3564642` FOREIGN KEY (`createdBy`) REFERENCES `fos_user` (`id`))

Other tables are affected too.
I have a temporary fudge in place, basically drop the schema and run the Doctrine migrations, but it's not pretty.
Maybe I'm missing something, or something needs fiddling?
Happy to pitch in and try to help with a PR if it needs doing.

Hi, I believe https://github.com/theofidry/AliceDataFixtures/pull/32 can fix this issue.
I unfortunately didn't have the time to properly review it, and as I think there's a hole in the test suite regarding that peculiar part, a manual check is necessary.
So if you can help with the review (actually more the manual test) and fix the tests, then I could merge the PRs without further delay :)

I'll have a look at the PR over lunch, but anything more may have to wait until our next spike day as there are deadlines and things.

@theofidry Looking at that PR, assuming we don't want the disabling of foreign keys in this project, as I think we both agree that it would maybe belong in Doctrine\Common\DataFixtures\Purger\ORMPurger, not here, I don't think that PR actually changes anything.
I've also been playing with our cascading delete, but the purging with truncate still falls over the foreign keys, so I have dealt with the purge outside of here.
It does seem that the --purge-with-truncate option does not get through to \Fidry\AliceDataFixtures\Loader\PurgerLoader::load() though.
I doubt I'll be able to look at that today, because now we are doing our truncating outside of here, we just want to append, and are getting caught out by this...
./bin/console hautelook:fixtures:load -n --append --env=dev

  [LogicException]
  Cannot append loaded fixtures and at the same time purge the database. Choose one.

I think I'll close this issue and maybe have a look at that.

authors: WillGibson theofidry

repo: hautelook/AliceBundle

license: mit


text:
Prisma Plugin exposeDescriptions not working

Hey @hayes,
I'm a big fan of pothos and love the developing experience  so far. One thing that keeps on coming up, is that I have to add descriptions to my schema in many places and since I use prisma I would love to add these to my prisma schema where possible and expose these to generated graphql schema with exposeDescriptions: true as described here:

https://github.com/hayes/pothos/tree/main/packages/plugin-prisma#set-up-the-builder
https://github.com/hayes/pothos/discussions/106#discussioncomment-3353810

But somehow descriptions for fields that have comments like /// field description in my prisma.schema do not end up having the comment as description in my generated graphql schema.
I am using the prisma plugin in combination with the relay plugin like this:
const builder = new SchemaBuilder<ExtendedSchemaTypes>({
  plugins: [PrismaPlugin, RelayPlugin],
  relayOptions: {
   ...
  },
  prisma: {
    client: prisma,
    // use /// comments from prisma schema as descriptions
    // for object types, relations and exposed fields
    // see: https://github.com/hayes/pothos/tree/main/packages/plugin-prisma#set-up-the-builder
    exposeDescriptions: true,
  },
});

Any idea what I might be doing wrong?
Thanks a lot!

Mhh ok, after a little more testing I got it working, but it has to do something with my setup, where i also do some schema stitching. Thanks a lot for looking into this!

repo: hayes/pothos

license: ISC


text:
GraphQL aliased subqueries with different parameters return identical results

Description:
When I execute a query with aliased subqueries that have different parameters, the results returned are identical. This behavior is unexpected, as the subqueries should return distinct values based on the provided parameters.
Implementation
const AccountValuesFilter = builder.prismaWhere("Value", {
  fields: (t) => ({
    date: builder.prismaFilter("Date", {
      ops: ["gte", "lte", "equals"],
    });
  })
});

export const Account = builder.prismaNode("Account", {
  name: "Property",
  id: { field: "id" },
  values: t.relatedConnection("values", {
    cursor: "id",
    totalCount: true,
    defaultSize: 10000,
    args: {
      date: t.arg({ type: AccountValuesFilter }),
    },
    query: (args) => {
      console.log("-> args", args);
      return {
        where: args.filter ?? {}
      };
    },
  })
});

The query looks like the following:
{
  account(id: "1") {
    currentValues: values(filter: { date: { equals: { "2022-01-01" } } }) {
      edges {
        node {
          date
          value
        }
      }
    }
    previousValues: values(filter: { date: { equals: "2021-01-01" } } }) {
      edges {
        node {
          date
          value
        }
      }
    }
  }
}

Here's the results:
{
  "data": {
    "account": {
      "currentValues": {
        "edges": [
          {
            "node": {
              "date": "2021-07-01",
              "value": 68551864.7
            }
          }
        ]
      },
      "previousValues": {
        "edges": [
          {
            "node": {
              "date": "2021-07-01",
              "value": 68551864.7
            }
          }
        ]
      }
    }
  }
}

Notice that both currentValues and previousValues have the same date value, even though I'm filtering by different dates. I logged the args value and it seems that the issues happens after query().
-> args {
  date: 2022-07-01T00:00:00.000Z
}
-> args {
  date: 2021-07-01T00:00:00.000Z
}

Expected Behavior:
The aliased subqueries with different parameters should return distinct results based on the provided parameters.
Actual Behavior:
The aliased subqueries with different parameters return identical results, suggesting that the library might be reusing the parameters from the first subquery.
Library Version:
Pothos Core 3.33.0
"@pothos/core": "3.33.0",
"@pothos/plugin-add-graphql": "3.1.1",
"@pothos/plugin-errors": "3.11.1",
"@pothos/plugin-prisma": "3.57.0",
"@pothos/plugin-prisma-utils": "0.11.0",
"@pothos/plugin-relay": "3.43.1",
"@pothos/plugin-simple-objects": "3.7.0",
"@pothos/plugin-tracing": "0.5.8",
"@pothos/plugin-validation": "3.10.0",
"@prisma/client": "5.2.0"
"prisma": "5.2.0"

Additional Information:
This issue happens not only with relatedConnection, but also with field with select and args attributes defined.
// ...
score: t.float({
  nullable: true,
  args: t.arg({ type: "Date" }),
  select: args => {
    scores: {
      select: {
        value: true,
      },
      where: { date: args.date },
      take: 1,
    },
  },
  resolve: ({ ids }) => ids?.[0].value ?? null
}),

I just noticed that it works it the args isn't deeply nested. for instance, if I introduce another arg like orderBy and pass in a different value, the query works as expected.
{
  account(id: "1") {
    currentValues: values(orderBy: { date: Asc }, filter: { date: { equals: { "2022-01-01" } } }) {
      edges {
        node {
          date
          value
        }
      }
    }
    previousValues: values(orderBy: { date: Desc }, filter: { date: { equals: "2021-01-01" } } }) {
      edges {
        node {
          date
          value
        }
      }
    }
  }
}

So my guess is that it does a shallow comparison. make sense?

hey, thanks for the report.  Unfortunately I haven't been able to reproduce the issue.
I created a repo with a minimal reproduction based on your description, but it doesn't cause the same issue, any chance you could see if you can modify the example to more accurately reproduce the issue you are running into?
Here is my attempted reproduction: https://github.com/hayes/pothos-prisma-alias-bug

Awesome, thanks! I've just created a PR there!

should be fixed now! Definitely an interesting bug, thanks for helping to track this down

authors: hayes juliobetta


text:
set up local firestore emulator for testing

Problem/Need:
Minimize reads/writes/deletes to the production Firestore.
Suggestions:

[x] https://github.com/hchiam/learning-firebase-local-emulator
[ ] try integrating it into Travis CI?: https://github.com/hchiam/slides/blob/main/.travis.yml

Don't bother running the "mock" DB in the Travis CI.

repo: hchiam/slides


text:
Pass workflow_name and input_folder to DbResultWriter

Parsing logs in DbResultWriter was error prone. This PR fixes this issue by passing the necessary context directly via the constructor or BaseJob.run() method

This is good to go BTW, I've tested it

Thanks!

authors: constantinpape wolny

repo: hci-unihd/batchlib


text:
files missing

This code misses the file of utils.py and small_tools.py,Could author upload it again?

Sorry for the inconvenience. Just uploaded the utils.py and small_tools.py.


text:
At-Least-Once processing and acknowledgements

It appears from EventHubReceiver.java#L83 that, even though the receiver is operating in AcknowledgeMode.ALO, that messages are acknowledged immediately on receipt.
This makes it impossible to ensure that messages are completely processed by consumer logic before acknowledgement. If the consumer receives a messages an aborts prior to completely processing the message, the whole payload is considered processed and the data is lost.

Thanks @clarkbreyman for reporting this. Will get this looked at.

Hey @rtandonmsft Is this still an ongoing issue?

@rtandonmsft This is Jon Meran from Schneider BTW :)

@jonmer85 - Here's the link to the specific line. The messages are acked when they are received, not when the events they contain are processed. If you crash after receiving but before processing, the events are lost.
https://github.com/hdinsight/eventhubs-client/blob/master/src/main/java/com/microsoft/eventhubs/client/EventHubReceiver.java#L83

Thanks @clarkbreyman for my specific case this may not be a huge problem since I will likely use this library for sending messages, not receiving them. We rely on Storm to process messages out of the Hub so we need the Storm component to ack the messages.

@jonmer85 You deduction is right, for Storm case (for which the spout/receiver) were originally written, once the message enters Storm, it's Storm guarantee to ensure the message is fully processed. So acknowledging the message on server side will not make a difference as all the check-pointing information is stored in Zookeeper.
@clarkbreyman What scenario are you using this client for? The same problem does not exist if you use https://github.com/hdinsight/storm-eventhubs that uses this underneath. I had reached out to event-hubs team about this issue and did not get a response. What behavior change do you expect? Do you want a separate acknowledge method to be exposed in receiver? Have you looked at Storm to solve your message processing guarantees?

Thanks for your quick responses as always @rtandonmsft !

@rtandonmsft - We're looking at a variety of applications which cannot tolerate any message loss (requires at-least-once processing), so if our consumer crashes or disappears before the consumer processing is complete, the message must not be acknowledged.

For these applications, we would be considering Event Hubs as an alternative to Kafka, not as a spooling mechanism for Storm.

Closing this issue, as this client was mostly written to support Storm. Newer java applications should consider switching to: https://github.com/Azure/azure-event-hubs

authors: clarkbreyman jonmer85 rtandonmsft

repo: hdinsight/eventhubs-client


text:
ORM Dependency causing errors while implementing with sequel-rails

Environment

Ruby 2.7.1
Rails 6.0.3.3
Devise 4.8.0

Current behavior
When trying to reset a password this error is produced after using the link with the token. it seems like it is expecting reset_password_sent_at to be a Date object but it is a string. This is running on a recent install of devise - i am using sequel ORM rather than active record but i don't think that should affect anything controller side.

So my initial impression was that it would get the variable through the controller, and i was of course wrong, its getting it through the model so i added this to my User model
def reset_password_sent_at     Time.parse(super)   end
And that allowed it to pass this error , however, immediately ran into another, which i am going to guess is another ORM issue.

I had already installed sequel devise hoping to deal with these issues but that obviously hasn't been much good, (neither was the sequel devise generator).
Is it sensible if i document these as i progress through them, then perhaps changes could be made to make Devise more independent of the ORM?

So I was being a derp for a while, but i fixed this in the end by putting this method in my model class ( my model extends Sequel::Model, which is where the incompatibility comes from )
 def reset_password_sent_at     if super        Time.parse(super)     end   end
It seems like this is because Devise is expecting to receive Date objects from the ORM/model and sequel is only providing literal values of the database. It seems possible that some convention isn't being followed that would maintain Devise as independent from the choice of ORM, Perhaps Sequel isn't following these conventions, but it tends to be a pretty strict on rules in general, which is why it's good.

Devise is meant to be mostly ORM independent, in fact it used to work just fine with both Active Record and Mongoid ORMs (more recently it's stopped testing against mongoid due to some issues and it was never added back, that's on my list, but it still strives to be compliant with both)
Regards to your issue, I'm not interested in adding any type of parsing to Devise itself, I believe that's the ORM's job. It does sound like that particular column/field is set to be a string and not a date/datetime column, maybe in your database? I'm wondering if it's just Sequel reflecting that it is a string and not doing any parsing work for you.
I've never tested with Sequel myself and so I can't offer much help there honestly. Are you using another library to make any bridge necessary? I'm happy to adjust things on Devise's end if that ends up being needed, but it does seem like an ORM thing from the looks of it.

Ok so it appears i was still being a bit dumb (not uncommon), I used a generator from sequel devise generators to set up the migration, and it produced something that was probably more of an AR migration so i had to morph what it produced into a sequel migration, which i did without checking the sanity of the datatypes, and it had put reset_password_sent_at as a string so good call on that one ( sorry for not checking the obvious ).
Unfortunately there is still an issue. So as far as i can tell reset_password_sent_at is set here -
`
def set_reset_password_token
raw, enc = Devise.token_generator.generate(self.class, :reset_password_token)
      self.reset_password_token   = enc
      self.reset_password_sent_at = Time.now.utc
      save(validate: false)
      raw
    end

`
Which is converting the time to UTC and then sending it to the ORM. Unfortunately Sequel stores the timezone with the datetime so as i am in UTC + 9  this effectively steps the time back 9 hours, meaning that a 6 hour window is not enough.
So it appears that Sequel is missing the UTC identifier when storing the time, and i am not sure how to correct this at the moment. I don't know whether the error is more sequels issue than devise, i am reluctant to point any fingers, it looks like sequel, but sequels got a habit of being correct in a lot of situations like this. I am going to keep investigating. If you are aware of a way to deal with this please let me know (even if its just a workaround), otherwise i will let you know what i find.

After some investigation, i found the resolution to this - Sequel supports databases that do not store timezones and so has a variety of ways of dealing with them. The most direct solution was to load the extension named timezones in application.rb -
    module RailsApp
      class Application < Rails::Application
        config.sequel.after_connect = proc do
          Sequel.extension :named_timezones
        end
      end
    end

Once i have done testing, would you like me to list the necessary adjustments to allow Sequel to interface with Devise in rails so they can be documented?

authors: carlosantoniodasilva mofmn

repo: heartcombo/devise


text:
Allow custom http Client

Closes #23
Allows passing in an http.Client.
No breaking changes.
Adds very rudimentary tests.

I actually don't like this. The New method should take in a struct. I'll fix it.

repo: hekmon/transmissionrpc


text:
Webpack can't resolve JSX extensions

The webpack config files don't contain a resolve configuration:
resolve: {
  extensions: ['.js', '.jsx'],
}

it does, https://github.com/heldrida/reactatouille-boilerplate/blob/master/template/webpack.dev.config.js
ln25

authors: heldrida miukimiu

repo: heldrida/reactatouille-boilerplate

license: WTFPL


text:
支付宝应用公钥证书模式-需要如何配置？

支付宝资金支出类接口（转账，现金红包）只能使用证书方式。

我也在关注这个问题，发现 rsaAliPubKey 这个参数根本没法填

这个作者能否来回复下呢，很急呀，这个功能应该是不支持的

这是支付宝的新功能，没有上线。有时间我加一下


text:
Minor changes

Overall probably a very pointless PR but I couldn't help myself.
The main changes:

Setting the homepage to say PyHC instead of just home on the tab title.
Two typos
Some incorrect unicode characters

Everything else is just whitespace changes either to attempt to make it look prettier, or to try and follow the markdown spec in places.
I rendered it locally, I had to add a new bundle for it work, I could not spot anything I had broken on the surface.

Thanks for the PR but it’s hard to tell where the important changes are. It looks like your IDE did a bunch of auto-formatting that we didn’t ask for (changing indents from 4 spaces to 2, etc.). Will you please revert all the formatting changes and keep just your three main changes?

Thanks for the PR but it’s hard to tell where the important changes are. It looks like your IDE did a bunch of auto-formatting that we didn’t ask for (changing indents from 4 spaces to 2, etc.). Will you please revert all the formatting changes and keep just your three main changes?

All of those changes I did deliberately to ensure a consistently across the files and to fix a bunch of formatting issues.
If you don't want them I can remove them.

I have undone all the extra whitespace/indentation changes.

Well I certainly do appreciate you taking such a close eye through our code base! Sorry I assumed that was IDE auto-formatting and not your manual labor. But this is much easier for me to review now that it's not 62 changed files.
I'm happy with these improvements except for where you changed dashes to hyphens; we were intentionally using en dashes because it's the correct punctuation mark for intervals. So please revert those hyphens back to dashes then I'll gladly merge. Thanks.

I'm happy with these improvements except for where you changed dashes to hyphens; we were intentionally using en dashes and em dashes for intervals and for separating clauses, respectively, because they're the correct punctuation marks. It would be incorrect to use hyphens in those contexts. So please revert those hyphens back to dashes then I'll gladly merge. Thanks.

I have fixed my mistakes regarding this matter.

authors: nabobalis sapols


text:
[Addition]: [MOC to investigate] Pisces Cluster Popping Up like Deeper (2/5)

Hotspot b58 Addresses
112exaKaQQyMupe5VEX8tcDxueY3HhWrbeK4cjFCA7V4k9twnoaw
11ZPKsTp4CtfFpxoHdKVbW9CB4JLzP6nz18jU5L2p7rvXreLVyJ
112QupKEb2Zmh39RS5Zqnrpv1T1oL5odDVyfAYeUggdmDrRJWi7t
117CSktCrzkC3t7TjACCeVdhRRwNWaGvuxs2Lw4Q5BDVy5mBy1P
11Zox9rGtsHL8qH9356w96hxPhtQWTL2R3ist14wWZ484pQpGRF
1129Y4ecquWVgSEHndmRbWekr8ugHckWnx5zbYuEsTDK9SXt4CHG
1129Cbe6Pw4KMwNW7drgv8roXAm8e5bQ2MVpkQT4eMQ25GuYNDxA
11awc8hZhAyCZKdYyHJin1GfWEw3k1CGL2HCZjNzN6foSzhBmFy
111rtczstKWhj3BVAn9y5fshAPRJD4CDAsLfcyXByKCmrSFaN9
112K5QSpV3teE4rSpmsSv3KYqePYwkCX63VNrpmt7jsBjK6Uk68C
11UjakPZ2qKA8n52ZqptCZhN6BLy9mBePaUP47DoSDioctAUh8p
11dmYPHJ8BJSi5gqK5Cxu8wBb8kqSeDcPW9gAw2ZggsVRNfkKUk
1123jiptAkzaVfBMZh22xEwNbhu8ogNXWRNnKAJ8gWfmbpfV2Bgw
112XEvg8eeT6dTe7h31Fhwn8AmV26Lesm1JPn2jrCmB1vKiftP4R
11TvKzA7nLfPHs6RvDEvJzsUcmcmciri576LMMq3QdXUWUyy8Ts
11UNF3gnF69g2ZbjxFN1AP4kCptweVA1PNLxjb1fcxmkYoRPkUp
Discord Handle
No response
Reason(s)
All cheaters are with similar patterns:

RSSI is the same regardless of distance
All popping up within the same hour and self witnessing right off the go.
One wallet per miner

As the leading task force, the Manufacturing Oversight Committee (MOC) should review the recent trend of spoofing with Pisces and PantherX miners.

Hi,Mr hexPi,I'm little Andy from HongKong who lives in Georgia.I've heard about Helium project from my best friend Jack who lives in HongKong last year,I really like this project after he explained the whole concept of Helium to me.
So I told my grandpa about it,He and I were very exciting about this project.So he decided to give me his pension to have a try.Then I  asked Jack to help me out with buying 16 Pisces miners from HongKong. It took me a while  till I got those Pisces miners. Then my grandpa helped me to talk to his friends and neighbors to allow us to  put Pisces miners in their houses,We'll share the HNT with them.
I didn't know that one wallet can connect to more than one helium miner,It took me a long time to use my phone to generate wallets and connect to those miners.I just finished assert the locations for my miners and going to put them in my grandpa's friends' houses soon.But I've been busy with preparing gift for my sister's birthday,That's why I didn't set up those miners in their houses right away.I'll do that in the next few days. I'm not a cheater,Mr HexPi. Jack called me today and said there's a man call me and my miners cheaters here. I couldn't believe it until I saw my miners' name here. I'm very sorry If my miners caused any problems to you,Mr HexPi. I just wanna give it a try and make some money to help my parents.

I will remove this if any of your miners listed can be witnessed by any surrounding hotspot already installed (there are plenty of them, see screenshot below). Otherwise, you are just playing victim.

authors: hexPi littleAndycanfly

repo: helium/denylist


text:
nishantProfileAdd

What does this PR do?

Fixes #(issue)

Type of change

Bug fix (non-breaking change which fixes an issue)
Chore (refactoring code, technical debt, workflow improvements)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

How should this be tested?

[x] Test A
[x] Test B

Mandatory Tasks

[x] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

Checklist

JSON file error

@NishantSharma48 you forgot the comma here

Awesome. About to merge
Make sure to drop a ⭐ Star to the repository @NishantSharma48

repo: hellofaizan/xprofile


text:
Added warning about configuration difference from MetalLB docs

What this PR does / why we need it: This helm chart, by default, has MetalLB looking for a ConfigMap named 'metallb-config' in the same namespace in which it is deployed. This is different than the MetalLB docs, which specify that a ConfigMap named 'config' should be created in a namespace called 'metallb-config'. I updated the README.md to warn users of this difference.
Which issue this PR fixes: Fixes #9973
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X ] DCO signed

/assign @lachie83

/lgtm

authors: ebauman mattfarina

repo: helm/charts


text:
[stable/fluent-bit] Upgrade to 1.2.1

What this PR does / why we need it:
Upgrade to 1.2.1.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @edsiper @hectorj2f

@ialidzhikov imagepullpolicy must not be changed

imagepullpolicy is always

Done.

/lgtm

authors: edsiper ialidzhikov


text:
[stable/elasticsearch-curator] Update appVersion

Signed-off-by: Pavel Dmytrenko mail@pavdmyt.com

Is this a new chart
No.
What this PR does / why we need it:
Updates appVersion to the actual one to avoid misleading versions in helm list output.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/chart])

Thanks!
/ok-to-test
/lgtm

authors: desaintmartin pavdmyt


text:
[stable/atlantis] fix the mount collision between repos.yaml and atlantis.yaml

What this PR does / why we need it:
Fixes a mount collision if both repoConfig and config are set in the values.yaml
Kubernetes mounts config which contains atlantis.yaml first then in the same dir (/etc/atlantis) mounts repos.yaml over it. So the server will not start since it's looking for /etc/atlantis/atlantis.yaml
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/lgtm

authors: jeff-knurek mzupan


text:
[stable/rabbitmq] Add NetworkPolicy simple support.

Special notes for your reviewer:
By default, only a single rule for all ports. This may be too permissive, but it is a start.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/lgtm

authors: carrodher desaintmartin


text:
[stable/gangway] add logic for applying env vars and pod annotations

…tations
Signed-off-by: cten cxtenberge5@gmail.com
What this PR does / why we need it:
I needed to pass pod annotations and environment variables to the pod. This allows for loading secrets from env.
Which issue this PR fixes
I don't believe there is a ticket at this time
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

@rk295

/ok-to-test

/retest

/retest

Any maintainers have time to help me merge this? Thanks

Ping...

/lgtm

sorry for lag, things bit crazy atm!

Thanks! Completely understand.

authors: cten rk295 zanhsieh


text:
[stable/chaoskube] Use version 0.10.0 + Adding minimum age to the chart

What this PR does / why we need it:
Use version 0.10.0 + Adding minimum age to the chart

/assign @linki

@shaikatz Can you sign off your commits? TIA. See: https://github.com/helm/charts/pull/7289/checks?check_run_id=14283858

I'll reopen that. it became a mess with this DCO.

authors: davidkarlsen shaikatz


text:
[stable/bookstack] Add chart for Bookstackapp

Signed-off-by: Bart Verwilst bart@verwilst.be
What this PR does / why we need it: Add Bookstack ( https://bookstackapp.com ) Helm chart for all to enjoy.

/assign paulczar

/assign davidkarlsen

/ok-to-test

/retest pull-charts-e22

/lgtm

authors: davidkarlsen paulczar verwilst


text:
Helm lint passes, but deploy fails with invalid contents

helm lint passes witih 1 chart(s) linted, no failures but `helm install fails with:
Error: release ignite-webconsole failed: Deployment.apps "apache-ignite-webconsole" is invalid: [spec.template.spec.containers[1].name: Required value, spec.template.spec.containers[1].image: Required value]

To reproduce this, see https://github.com/hughestech/apache-ignite-webconsole/tree/d9bb833e56388959f1753a189eb46cbff877c263
Output of helm version:
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.1", GitCommit:"4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState:"clean", BuildDate:"2018-10-05T16:46:06Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
minikube

Yeah, this is a limitation of helm lint where the templates are not being verified against the kubernetes schema.
Closing as a duplicate request of https://github.com/helm/helm/issues/2575.

repo: helm/helm


text:
helm client  get same ready tiller pod  every time?

I have a question about this code：
https://github.com/helm/helm/blob/7b821dd52fffa135cfe78611299b0491f7f03d39/pkg/helm/portforwarder/portforwarder.go#L72-L87
I see that the helm client takes the pod of the first ready state every time. If I have multiple pods, it can be load balanced, avoiding the first pod overload？

Followup: if helm v3 doesn't have tiller, will there be a locking mechanism to prevent simultaneous deploys to the same release?  Also, is there even anything in the current tiller setup that would does similar locking?

I'm going to close this ticket due to inactivity, but please re-open if this still needs to be addressed. Thanks!

authors: Stelminator bacongobbler silenceper


text:
Update the labels used in Helm in order to organize the many issues submitted

Output of helm version: N/A
Output of kubectl version: N/A
Cloud Provider/Platform (AKS, GKE, Minikube etc.): N/A
There are issues which are seldom used in this project  as well as a few which are either way too weighted (question/support) or no longer used due to no longer using the k8s bot / CI / etc.
Statistics:

Label
Number

question/support
417 open issues and pull requests

feature
225 open issues and pull requests

bug
151 open issues and pull requests

v3.x
100 open issues and pull requests

proposal
70 open issues and pull requests

docs
40 open issues and pull requests

help wanted
22 open issues and pull requests

size/XS
18 open issues and pull requests

size/S
18 open issues and pull requests

v2.x
16 open issues and pull requests

unconfirmed
16 open issues and pull requests

size/L
15 open issues and pull requests

good first issue
15 open issues and pull requests

refactor
13 open issues and pull requests

size/M
11 open issues and pull requests

area/helm-test
8 open issues and pull requests

awaiting review
5 open issues and pull requests

wip
3 open issues and pull requests

plugin
2 open issues and pull requests

size/XXL
1 open issue or pull request

size/XL
1 open issue or pull request

needs-rebase
1 open issue or pull request

blocked
1 open issue or pull request

Unused labels:

¯_(ツ)_/¯
wont fix
v3 port complete
release note required
picked
Needs v3 fix
needs-pick
lgtm
keep open
in progress
cncf-cla: yes
cncf-cla: no
breaking
approved

My suggestion changes:
Implement a more sane GitHub label structure
I suggest the following:

Implement changes to how we set certain PR's / issue statuses:

Add a handy label (and minimal) type label structure.

Including adding the following additional labels: Type: Feature and Type: Support

Set priorities.

Removal of old labels / unused labels
Removal of any labels which are either part of the k8s CI / org (there's a few such as the CLA) or seldom used. Here are the following unused labels:
Unused labels:

¯_(ツ)_/¯
wont fix
v3 port complete
release note required
picked
Needs v3 fix
needs-pick
lgtm
keep open
in progress
cncf-cla: yes
cncf-cla: no
breaking
approved

Restructure of the question/support label
I suggest that the following be done to "restructure" the question/support label.
There are over 400 issues (half of all issues submitted!) which are support only.
Direct users to use StackOverflow, Slack or https://helm.sh/docs
This is similar to how Kubernetes directs all support questions: https://raw.githubusercontent.com/kubernetes/kubernetes/master/.github/ISSUE_TEMPLATE/support.md

Hi @cdrage. Thanks for providing your thoughts on this topic.
I had a few comments/questions about your proposal.
In general, what is the intended goal for these proposed changes? It would be helpful to clarify the intent behind this proposal so we can better understand its intent.

as well as a few which are either way too weighted (question/support)

I don't necessarily perceive this to be an issue. Having a large chunk of the issue queue as support questions seems par for the course, and many of these support questions are eventually answered by the community over time as use cases evolve and users understand the tool. As long as we're consolidating duplicate questions and moderating the discussion, conversations are free to carry on until an answer or a solution is reached.
IMO the more important goal as maintainers is to keep the number of open bug reports to a minimum.

Direct users to use StackOverflow, Slack or https://helm.sh/docs

Similar to the previous answer, I'm not sure how this will help keep the traffic down. We're just redirecting the user elsewhere, increasing traffic in those support channels. In many cases, support questions have transformed into actionable ticket items, and as a core maintainer, I'd rather avoid having to monitor another page just to track those discussions. https://github.com/helm/helm/issues/7082 is a recent example of a ticket where a support question evolved into a feature request. Keeping support questions and feature requests allows these conversations to evolve over time.

Implement changes to how we set certain PR's / issue statuses:
Set priorities.

Many of the proposed labels here involve an increased workload on the core maintainer's end as part of the PR review process. Why do we need to change this? What is the end benefit for the maintainers?
On priority labels: we haven't really found much utility with them in the past. Github milestones has worked quite well for tracking issues/PRs in progress, and provides the community a sense of what's being prioritized. The core maintainers have based the level of priority on certain tickets based on how involved the community is engaged with a particular topic, as well as the labels attached to it. For example, an issue with the bug label implies higher priority than an issue labeled question/support.

Including adding the following additional labels: Type: Feature and Type: Support

The feature and question/support labels are used for those purposes. I'm not sure what would be the difference between a Type: Enhancement and a Type: Feature in this context.
Support issues can also be labeled as general questions, which is why they were consolidated in the first place.

Unused labels:

Please ensure you're also checking closed issues as well as open issues in your search filters -- a lot of these labels are still actively used. Some labels like the cncf-cla: yes, cncf-cla: no, lgtm, v3 port complete and approved labels could be removed, but many of those labels are all used quite actively. For example:

PRs labeled with breaking was used recently to note breaking changes introduced during Helm 3's development cycle
PRs labeled with needs-pick is used often when we need to track pull requests to be cherry-picked into the next patch release.

The size/ labels are currently used to determine how many reviewers should approve the PR before it is merged, so those should stay as well. See CONTRIBUTING.md for more details.

Hi, @cdrage - as you likely saw, we replied with some detail around current labels. Because we are always interested in improving, we now have a defined process so that if you'd like, you can submit a Helm Improvement Proposal so as to work in the community to make new ideas a reality: https://github.com/helm/community/blob/master/hips/hip-0001.md - meanwhile, I will close this issue. Thanks!

authors: bacongobbler bridgetkromhout cdrage


text:
helm upgrade failed when k8s object version changed.

Output of helm version: helm 3.2.1
Output of kubectl version: Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.12", GitCommit:"a8b52209ee172232b6db7a6e0ce2adc77458829f", GitTreeState:"clean", BuildDate:"2019-10-15T12:04:30Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):  On premise k8s cluster
I changed the k8s object version for my deployment object from apiVersion: extensions/v1beta1 to apiVersion: apps/v1. I tried to upgrade my release and it failed with the error saying
helm3 upgrade master-ci Chart --namespace dev --install --timeout 15m0s --debug --history-max 2 -f my-values.yaml   history.go:52: [debug] getting history for release master-ci  upgrade.go:121: [debug] preparing upgrade for master-ci  upgrade.go:129: [debug] performing update for master-ci  Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: Deployment "chart-master-ci" in namespace "dev" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "master-ci"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "dev"  helm.go:84: [debug] Deployment "chart-master-ci" in namespace "dev" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "master-ci"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "dev"  rendered manifests contain a resource that already exists. Unable to continue with update

Have you tried applying the annotations to the objects described in the error?

No

Kubernetes treats apiVersions separate from each other, and therefore a resource cannot be upgraded from one to another. There are closed tickets in the Helm queue that go into more detail about this behaviour, and why Helm cannot upgrade resources from one api version to the next.
Hope this helps.

for example: #7219


text:
helm upgrade --forc --automic, spec.clusterIP: Invalid value: "": field is immutable

We have not modified the service configuration in chart，but got  Upgrade "drms-admin-web" failed: failed to replace object: Service "drms-admin-web" is invalid: spec.clusterIP: Invalid value: "": field is immutable
helm version:
version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}
kubectl version:
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-15T01:55:22Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Cloud Provider/Platform:
Alicloud CS

Duplicate of #6378. I left a comment in that thread that explains the situation in greater detail. Please have a read through that thread and see if anything relates here.

I noticed in the title you used --force. As described in that issue, omitting --force resolves the issue. Therefore, closing as a duplicate of #6378.


text:
Add swedish locale

Swedes are all about astrology.

Hey 👋 ! Are you a Swedish speaker so we could give some astrology to Swedes?

Sure am. I'll get right on it

authors: helmasaur peter-rymdfabriken

repo: helmasaur/zodiac-signs


text:
M5Core2 Library 0.0.3 Issue

Does not compile with Version 0.0.3 of the M5Stack M5Core2 Library  ... You must currently use 0.0.2

as the current version is 0.1.4 I assume this is no longer relevant?

I confess I have not tried to recompile it since last year due to all the M5Stack library issues. If you find an a set of libraries that work reliably let me know and we can update this comment /and/or readme and add any specific instructions needed to get it to compile.

yeah - so far no luck at all getting this code to compile. I'm very new to this (but not development)

So I found the "problem". Basically you  need to be using Button instead of TouchButton
I was in the process of starting to convert everything when I stumbled across https://github.com/kitazaki/M5Core2_atemswitcher
This is a fork of @aaronpk code to work with the newer m5 libraries. It said it was only tested with 0.0.6 but I just compiled it without error on 0.1.5 so I assume the lbraries have not changed for this part at least since then.
Not tested it on the actual atem yet as that's in another building but the fact it compiles gives me hope.

As you figured out, the TouchButton type was dropped from the M5Core2 Touch library in 0.0.3 with no documentation other than a single  note on GitHub in the M5Touch.h header that refers to a Legacy API. Unfortunately even the header incorrectly states the "This older API is still supported". Many thanks for opening a bug against M5Core2. These types of issues are why I stopped updating the code last year.
The good news I was able to validate the code  does compile and work using:
Arduino IDE 1.18.13 / M5Stack Board 1.0.7 / M5Core2 Library 0.0.2
Of course I understand this is not a desirable outcome, as such I will take a closer look and see what it will take to update the code to the new Touch library.

Not tested it on the actual atem yet as that's in another building but the fact it compiles gives me hope.

Tested that one now and as soon as I remembered to modify the atem libraries as they stated it worked

Progress so far in converting your script. https://gist.github.com/brianteeman/30447842f7b3c07a091a753cc57a6a36
now to look at the sd card code so I can actually test this

Ah, looks like we started working on this at the same time. Im finished with the required changes however I have run into an issue with "I2S Port 0 not installed". As my Core2 was previously used for testing it still had a config stored in NVM so at least Im not dead in the water. Now I just need to borrow an ATEM for testing as well as try and figure out whats going on the I2S system.

sounds like it could be an issue with the drivers on your  computer and not the Core2.
Would be good to see your code as I am working kind of blind and guessing what it is supposed to do whereas you know what it is supposed to do as you wrote it.

Try the attached, In theory it should work. I had to add a quick hack to the readSDconfig function since cfg.begin  apparently now requires the full path even if the file resides in the root. If it works let me know and Ill start cleaning it up before I upload it.
Tallly-Core2-V10B.txt

At some point past IDE 1.8.13 the  SD File name() or possibly openNextFile()  function was changed so that the name returned no longer includes the full path when dealing with the root directory  This is why the SDConfigFile.begin() code was failing on the subsequent call to SD.open. Apparently SD.open always required the full path which should not be case when dealing with the root directory. I would not have figured this out had I not taken a look at the screen shots from version 1.0 that showed the fully qualified names.
Ill ping the developer and see what he thinks about both issues . In the mean time my hack seems to work as a quick fix until I can determine the best way to correctly address this issue.

didnt have a chance to look at anything today. But I brought the atem to my home office so will check out your script tomorrow.

Great news. It works.
Now I can start customising it for my own purposes. The first step of which is to remove alll the very clever config stuff you wrote and replace it with hard coded values. I understand why you did it that way but it is overkill for my usecase and it requires so much code to maintain

I started the same way, however within a month of the first ATEM purchase the company opted to expand to several thus the reason for the SD card allowing easy reconfiguration. However leaving SD cards around with sensitive info seemed inappropriate thus the reason for writing the config data in flash allowing us to keep the SD cards in a secure location until needed for a reconfiguration.  At last check they expanded the fleet even more with some of the newer models.

yes I changed my mind.
such a shame that the skaarhoj library stopped at 7.5 and that the replacement opensource library (libatem) is in c# not c++

Before uploading the latest version I want to ensure that the SD Library (Version 2.0.0) that now ships with M5Ccore2 Board 2.0.6 is behaving correctly when using the file.name function. I cannot find any documentation for the SD Libraries I have looked at thus far that explain why the SD Library dropped the root path between versions 1.0.5 and 2.0.0. Once I know if the new behavior is correct/incorrect I will rewrite the code appropriate to the expected behavior.
PS: Thanks for motivating me to finally address this issue.

Thanks for motivating me to finally address this issue.

It is me that should be saying thanks

It appears that the ESP32 SD & FS libraries were significantly changed in release 2.0.0. The good news is they decided to add a FS::path() method  which gives the original FQN behavior as in release 1.0.5. Ive included the reference.
https://github.com/espressif/arduino-esp32/pull/4892
Ill make the appropriate change  and upload the updated code most likely tomorrow.

This should be the final version. I found a newer version where I had apparently moved the location of the battery icon. If you prefer the older battery icon location  let me know and I will move it back.
Tallly-Core2-V10B.txt

I am smiling. The first thing I had done was to move the battery icon to the top (and remove the voltage display).
Not sure if the following is a logic error or not and also not sure if it is worth fixing but.
boot with the atem on then the connection status dot will display as green ✔
change the atem to off and the connection status diot will display red ✔
change the atem to off and the connection status diot will display green✔
BUT
boot with the atem off then the connection status dot will not display at all (until a conection is established)
I had expected in this case for it to show red
I am assuming that this is due to the code beginning at line 1150

Try the following. I now display a initial lightgray "pre-connection" dot  to differentiate it from a disconnect. I also opted to display the battery status during the setup  just to ensure it shows up in case there are network issues after setup finishes.
I guess I need to update the docs as well to correctly show the new icons locations and colors.
Tallly-Core2-V10B.txt

tested and works as intended.

Here is the new documentation to go along with it including new graphics (hopefully correct).
Tally-Core2-UserGuide.pdf

Closed with release 1.1

authors: brianteeman helo-head


text:
Fancy: Update to use PureComponent by default

Fancy: Update to use PureComponent by default

This update bumps Fancy to the latest version, which defaults to creating
PureComponent classes, which helps with performance.
Some minor adjustments were required for a couple of Message components,
mainly tests. This was good, as it revealed an implementation issue
with the ThemeProvider component.
A story was added for some manual testing of Message.context (just in case).
We'll minor bump this one!

Pull Request Test Coverage Report for Build 1365

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 1362:
0.0%

Covered Lines:
5110

Relevant Lines:
5110

💛  - Coveralls

authors: ItsJonQ coveralls

repo: helpscout/hsds-react


text:
Add rust tests to nix checks

Rust tests weren't current running as part of nix checks. This PR adds nextest to our nix checks run.
I ignored two of the integration tests which require CA root certificates to be setup because they'll need extra changes and I wanted to keep the PRs small. Another PR will follow

The Clippy failure seems unrelated to my changes in this PR.
It looks like a positive catch that was previously undetected but is now detected with a new version of clippy

repo: helsing-ai/buffrs


text:
使用中感到难受疑惑的点

实例中的computed及watch由于签名为字符串数组，是否可以支持props呢，在使用setup中又想监听某些props的变化，而这个限制貌似只有将监听通过内置hook写在组件内部，给人一种很不优雅的感觉。本质上都是监听，却又要通过组件内部来触发settings更新state达到效果。
虽然对于模块的状态在实例中监听可能会多次触发，但某些情况下的衍生数据对于写入模块显得有些小题大做。
理想状态：
computed监听state、props、refComputed、moduleState、moduleComputed
watch监听state、props、refComputed、moduleState、moduleComputed

收到建议，这块会重新考虑下更优雅的方式

那就等待魂大的好消息了

那就等待魂大的好消息了

其实有个api effectProps 满足观察props变化的需求，忘了在文档里写了，已经补上了，你可以看下
https://concentjs.github.io/concent-doc/api/ref-effect-props

那个等待魂大的好消息了

effectProps最近有api满足观察道具变化的需求，互联网文档里写了，已经补上了，你可以看下
https://concentjs.github.io/concent-doc/api/ref-effect-props

可以，很nice。其实有一点不明白为什么依赖值必须是字符串，而不是和useEffect一样的引用设计

因为，useEffect 可以在函数组件每次一次渲染时都能被触发执行，只需要将相关依赖的最新值交给react即可，react内部会去和上一次记录的值做比较然后决定要不要执行effect cb，而 setup 函数里的所有逻辑只能执行一次，ctx.effectProps 方法的第二位参数负责传递字符串，然后 concent 内部通过字符串去取上一次props和最新props的值一一做比较然后决定要不要执行，如果像 useEffect那样传值的话是没有意义的啦（重点需要理解setup 函数里的所有逻辑只能执行一次这句话哈），不过下一个版本可以升级下 ctx.effectProps 函数，支持写
ctx.effectProps( effectCb, isPropsEqualCb ) 这样的方式，既可以让用户自己定制比较规则了，举例：
ctx.effectProps(()=>{
  console.log(' triggerd! ');
}, ( prevProps, currProps )=>{
   return prevProps.someKey !== currProps.someKey
})

因为，useEffect 可以在函数组件每次一次渲染时都能被触发执行，只需要将相关依赖的最新值交给react即可，react内部会去和上一次记录的值做比较然后决定要不要执行effect cb，而 setup 函数里的所有逻辑只能执行一次，ctx.effectProps 方法的第二位参数负责传递字符串，然后 concent 内部通过字符串去取上一次props和最新props的值一一做比较然后决定要不要执行，如果像 useEffect那样传值的话是没有意义的啦（重点需要理解setup 函数里的所有逻辑只能执行一次这句话哈），不过下一个版本可以升级下 ctx.effectProps 函数，支持写
ctx.effectProps( effectCb, isPropsEqualCb ) 这样的方式，既可以让用户自己定制比较规则了，举例：
ctx.effectProps(()=>{
  console.log(' triggerd! ');
}, ( prevProps, currProps )=>{
   return prevProps.someKey !== currProps.someKey
})

这个方式算是普天同庆了。最具个性化的方式了。最初也猜想是为了不重复触发。只是觉得多个不同类的状态不方便聚合effect。例如一个effect的depkeys由state和props共同触发。有没有一种写法可以支持这样方式呢！如同sync的path将depkeys的值path化！！

这个issue先关闭了，后续有时间实现这个特性，可以关注helux，一个更先进的react 状态管理实现

authors: fantasticsoul itmanyong

repo: heluxjs/helux


text:
Add Link To F# Version.

Hi.
I created an F# version of this repo.
This change adds a link to the F# version.
Let me know what you think,
- Derek

Unfortunately this is in conflict but otherwise looks good.
The more the merrier!

authors: derek-baker jethrolarson

repo: hemanth/functional-programming-jargon


text:
Problem in ground-truth solutions

Hi, I'm encountering a problem in evaluating the solutions. For a preliminary pipeline in which I want to process all APPS benchmark with an LLM, I'm just taking one random solution among the available ones if present, otherwise using an empty solution. For the competition problems, test split, out of 1000 problems, only 311 have solutions, so in my case I should get a strict accuracy of 31.1% given that the solutions for the other 689 are left empty. However, I get the following results:
Test Case Average (average accuracy over problems) = 0.27318586602648753
Strict Accuracy (all test cases passed / total problems) = 0.263
Here's a screenshot of the last part of the evaluation script. Is it possible that certain solutions are only partially correct?
Thank you in advance for any help!

For the competition problems, test split, out of 1000 problems, only 311 have solutions,

So all of the test cases have "answers" which are unfortunately named input_output.  So it is possible to get 100% on all of the test and train.  Seeing the dataset in HF might provide some clarity.

Feel free to reopen the issue though.  If I have time I might reinvestigate the solution parser as mentioned in issue #27

repo: hendrycks/apps


text:
Refactor Frontend Authentication

This Pull Request refactors the frontend react app authentication using redux library.

Thanks @arteevraina looks great.


text:
The setColumnWidths method is not called when screen is shrinked

Hi,
I have a small sticky table with sticky header, and I give .sticky-table-table 100% to fill the container width.
When the screen width is growing, the setColumnWidths method is called to recalculate the column width, the new width and min-width are added to the column inline styles.
Then when we shrink the screen size back, the table size is not shrinked and a horizontal scroll bar is added. After I take a look at the source code, I found setColumnWidths is not called because the 'tableCellSizesChanged' is NOT true, and the reason is that the min-width in the column causes the 'bodyTable.offsetWidth' not decreasing even if its container width decreases. Below is the related code:
    ` var tableCellSizes = {
      corner: { width: this.dom.stickyCornerTable.offsetWidth, height: this.dom.stickyCornerTable.offsetHeight },
      header: { width: this.dom.stickyHeaderTable.offsetWidth, height: this.dom.stickyHeaderTable.offsetHeight },
      column: { width: this.dom.stickyColumnTable.offsetWidth, height: this.dom.stickyColumnTable.offsetHeight },
      body: { width: this.dom.bodyTable.offsetWidth, height: this.dom.bodyTable.offsetHeight }
    };

    var tableCellSizesChanged = JSON.stringify(tableCellSizes) !== JSON.stringify(this.oldTableCellSizes);

    var wrapperSizeChanged = JSON.stringify(wrapperSize) !== JSON.stringify(this.oldWrapperSize);

    if (forceCellTableResize || !this.oldTableCellSizes || tableCellSizesChanged) {
      this.setRowHeights();
      this.setColumnWidths();

      this.oldTableCellSizes = tableCellSizes;
    }`

I understand the min-width is to make the cell's width be dynamic, but how could we solve the shrink problem caused by it? Thanks

resolved in v3.0.1

repo: henrybuilt/react-sticky-table


text:
🛑 hentaiOS Blog is down

In d406487, hentaiOS Blog (https://blog.hentaios.com) was down:

HTTP code: 404
Response time: 675 ms

Resolved: hentaiOS Blog is back up in c27c524.


text:
all: update to Envoy 1.7.0

Updates #443
Fix configuration generated by Contour to avoid triggering warnings
under Envoy 1.7.0.
This is not backward compatible with Envoy 1.6.0.
Signed-off-by: Dave Cheney dave@cheney.net

Fixes #443

repo: heptio/contour


text:
accesslog_format added

For request https://github.com/heptio/contour/issues/624
Everybody run contour in kubernetes and all logs need be pased as json

@turbotankist thank you for your contribution. Can you please take a look at https://github.com/heptio/contour/blob/master/CONTRIBUTING.md#contribution-workflow
Specifically

Please wait for a clear direction on #624 before sending code. I've reviewed #624 and there is no decision yet.
Please sign all your commits, the instructions are in the link.

I'd like to close this PR as it cannot be merged as is. I welcome you to continue the discussion on #624 or raise your own issue describing the feature you want added. Once there is a clear decision on how to proceed, feel free to reopen this PR or send a fresh one.
Thank you for your time.

authors: davecheney turbotankist


text:
Provide sample httpsink receiver server

A simple webserver just echoes the received rfc5424 message to stdout. Comes
with its own Dockerfile. Currently not vendoring the rfc5424 library for
simplicity. This should help repro the bug report at #33.
Fixes #32.

I added a io.ReadFull in b4902ea, to discard a single byte after parsing a message successfully, to discard the \n appended to every message. I'm not sure if it's correct to do so but it seems to be working.
cc: @timothysc

repo: heptiolabs/eventrouter


text:
BundlerTest: adjust assertion to new hompage URL

This fixes two failing test cases.

This change is

Already adressed by another PR.

repo: heremaps/oss-review-toolkit


text:
model: Globally set the JSON property naming strategy to snake-case

Remove individual JsonProperty annotations in turn as it is too easy to
forget them. For Kotlin properties where JsonProperty annotation indeed
had been forgotten, use a JsonAlias to accept camel-case names for
backwards-compatibility.

This change is

@mnonnenmacher, any idea why the deserialization of resolved_revision in the first ScanResultContainerTest does not work?


text:
Support ECEF (earth-centered, earth-fixed) coordinates

Quantised mesh format requires Earth-centered Fixed coordinates, which is also suitable for visualisation of other astronomical bodies then Earth #49

Fixed in https://github.com/heremaps/tin-terrain/tree/ecef-coordinates.fester.

Fixed in #54

authors: delfrrr fester

repo: heremaps/tin-terrain


text:
Update rest-client gem because security vulnerabilities

rest-client 1.6.8 has security vulnerabilities
https://www.versioneye.com/ruby/rest-client/1.6.8

haven't been able to figure out why yet, but this fails locally for me

@dickeyxxx maybe only bcs restclient switched on netrc auth on 1.7.0 so your stubbed requests do not match if you have a .netrc file.

@dickeyxxx could you take a look if - on top of the additional commit kind of taking care of the stubbed requests - there's anything more we can do to have this merged?

:+1:

👍

:+1:

@atmos -- anything we can do get this rechecked/merged?

@bluta I don't understand the security vulnerabilities well enough to comment. 1.6 -> 1.8 is an API breaking change in a lot of places and I don't have enough things running constantly to speak authoritatively.

@atmos - you mean although the coverage for the first look seems promising for the API, still feel it'll fail in real applications? by any chance you have a rough direction for such problems?
sorry to bother, but our application works fine with the changes, and we also need the new version of rest-client for our own oauth - and we usually try to avoid forking if possible.

@balazslaszlo I merged this into https://github.com/heroku/heroku/pull/2011 and released, I just removed the regexes in favor of a host / netrc existence check.  I was going to mock out Netrc completely so that it never did user / pass in the url, but we depend on it to verify things in other tests, so it was not as straightforward as I had hoped.  Thanks for putting this together and sorry it took so long to get merged.

@balazslaszlo I had to roll back https://github.com/heroku/heroku/pull/2011 because this did not work on windows due to an ffi dependency.
from C:/Program Files (x86)/Heroku/ruby-2.1.7/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in require': cannot load such file -- ffi (LoadError)
from C:/Program Files (x86)/Heroku/ruby-2.1.7/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:inrequire'
from C:/Program Files (x86)/Heroku/vendor/gems/rest-client-1.8.0/lib/restclient/windows/root_certs.rb:2:in <top (required)>'
from C:/Program Files (x86)/Heroku/vendor/gems/rest-client-1.8.0/lib/restclient/windows.rb:7:inrequire_relative'
from C:/Program Files (x86)/Heroku/vendor/gems/rest-client-1.8.0/lib/restclient/windows.rb:7

authors: Hawerrr atmos balazslaszlo bluta dickeyxxx eschersgirl ransombriggs storhet

repo: heroku/heroku


text:
🛑 Software Center - Test 1 is down

In 7eeabee, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 30ace55.

repo: herrphon/upptime


text:
🛑 Software Center - Test 1 is down

In 03441c9, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 1116477.


text:
🛑 Auth-Bridge - Test 1 is down

In 9ab14dd, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 3363688.


text:
🛑 Auth-Bridge - Test 1 is down

In 17c847f, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in c750905.


text:
🛑 Auth-Bridge - Test 1 is down

In 300fdf4, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 129aadf.


text:
🛑 Software Center - Test 1 is down

In cf63ad5, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in f100964.


text:
🛑 Software Center - Test 1 is down

In 79c1301, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 3e51767 after 21 minutes.


text:
🛑 Software Center - Test 1 is down

In fca33d4, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 43283f6 after 21 minutes.


text:
🛑 Software Center - Test 1 is down

In 75efc81, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 10c0c97 after 10 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 849c095, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 2fc71ff after 1 hour, 9 minutes.


text:
🛑 Software Center - Test 1 is down

In d8c203e, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 01c6e33 after 47 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 5d9e0ea, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 0f717e6 after 22 minutes.


text:
🛑 Software Center - Test 1 is down

In 69c936c, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 5a78b2c after 51 minutes.


text:
🛑 Software Center - Test 1 is down

In 82884c1, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 6fb57e8 after 1 hour, 10 minutes.