Update sdcard etc

Description
This PR fixes a number of issues related to the SDCARD class in System.IO.Filesystem

The mapping of gpio pins for S3 and P4 targets.
Allowing the card detect to be active high or low
Adds some missing unit tests for a previous fix for list files with directories in same folder.
Card detct has been broken for a while. Fixes a problem where interrupts for card detect was not working due the same event names being used for card detect and when drives are mounted.
Added an Auto mount on card detect (optional)
Added feature to allow multiple cards (which was already existing in firmware). There is now a slotIndex parameter which denotes which card slot is being worked with. ESP32 allow 2 x slots for SDIO pins and we can have additional slots on SPI bus.
Separate the Card detect parameter in to separate parameter class.
Due to all these changes the API has been changed and not backward compatible.

This assembly requires updated NanoClr

Includes native code fix for unreliable GPIO event when debounce was enabled.
SDcard pins mapping
Update events

Also updated Hardware.ESP32

New pin mapping option for SDMMC1 and SDMMC2 devices.

Motivation and Context

Fixes nanoFramework/Home#1447
Fixes nanoFramework/Home#1475

How Has This Been Tested?
Tested locally with updated mount sample
Types of changes

[ ] Improvement (non-breaking change that improves a feature, code or algorithm)
[x] Bug fix (non-breaking change which fixes an issue with code or algorithm)
[] New feature (non-breaking change which adds functionality to code)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Config and build (change in the configuration and build system, has no impact on code or features)
[ ] Dependencies (update dependencies and changes associated, has no impact on code or features)
[x] Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
[ ] Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

[x] My code follows the code style of this project (only if there are changes in source code).
[ ] My changes require an update to the documentation (there are changes that require the docs website to be updated).
[ ] I have updated the documentation accordingly (the changes require an update on the docs in this repo).
[x] I have read the CONTRIBUTING document.
[x] I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
[x] I have added new tests to cover my changes.

Summary by CodeRabbit

New Features

Updated the Nerdbank.GitVersioning package to a newer version, which may include improved performance, bug fixes, or new functionalities for users.

Bug Fixes

This update is expected to address previously known issues related to the earlier version of the package.

Sorry a meant to leave some notes for discussion for this PR before review. That why I hadn't requested review yet :-)
When started testing the SD card stuff I found the storagemanager RemovableDeviceInsertion event was being used to indicate when a removable device had been mounted in file system although I thought it was for the card detect. The event logic for card detect was no longer working but looked like it had been calling the same event which didn't make sense.  I fixed event so card detect called RemovableDeviceInsertion event then found the args for event didn't make sense. It was passing a drive path for I: drive for a card which wasn't mounted yet. I hope this makes sense.
So that's why I decided to create a new event for card detect with new args and leave the mount & unmount events alone.
Probably the RemovableDeviceInsertion event is the wrong name as it is being used for when a device is mounted. Should we rename it ?  And call the Card Detect event that name ?
The card detect event I routed to the relevant sdcard object which I thought made more sense.
Everything is working now but I do think maybe some renaming will be in order. What do you think.
@josesimoes

The storage list is for mounted drives. With the card detect it isn't mounted yet so could use that for lookup.

Unit tests failing because references wrong firmware checksum for filesystem. Won't be fixed until interpreter updated.

Need to merge this now as matching nanoclr already merged.


updated memory limitiations (based on update 8)

I loaded up a bigger safe and the server didn't consumed more than 4GB (so I updated to 5GB)
This only applies to update 8 so this PR is draft atm until update 8 gets released to the early access branche.
Closes: #198

The wiki should update once update 8 is released.

@DenuxPlays  16G -> 5G upgrade? seriosly?

@kaflan update 7 is what increased the RAM requirement to what it was, update 8 brought it back down to what it was. I'm waiting for the official wiki to reflect this change now that uodate 8 is in early access

@DenuxPlays  16G -> 5G upgrade? seriosly?
@wolveix it work correctly?

Yes!
But I suggest that we check if 5Gigs is still enough.
They pushed a lot of releases in meantime (including updating the engine to 5.2 I think) so I would check if 5GB is still enough bevore merging this.

Thanks again!


loading all angular2 js separated

I broke this issue out of a compounded issue here:
https://github.com/mgechev/angular2-seed/issues/399 ... which I renamed to his other issue.
As @gustavolira mentions...

Today I did a pull at project and now I all angular2 js is loading separeted taking much more time to finish to load the page.
[omitted]
There's some way to load only angular2 bundle js instead of separeted?

I have also seen this in the latest changes and not sure why every single little .js file is now loading separately. It makes development much slower as the page load to refresh is now painfully slow. :(

The issue should be fixed in this branch https://github.com/mgechev/angular2-seed/tree/fix-400
@NathanWalker would you verify and merge?

IE issue with beta.1 :(
https://github.com/angular/angular/issues/6501

beta.2 released!
Now is possible!!

Fixed in https://github.com/mgechev/angular2-seed/pull/420.


Update 03_assignment.zig | Missing Line In Example

Looks like one of the example lines was missing.
set bar to a value that wouldn't have fit in foo (like the other examples seem to be doing)

Yes, good catch!  As a matter of fact, both foo and bar should probably be const in these examples so it's clearer what the difference is between the two.
Like so:
// Example: foo cannot be negative and can hold 0 to 255
//          bar CAN be negative and can hold −128 to 127
//
//     const foo: u8 = 20;
//     const bar: i8 = -20;
//
// Example: foo can hold 8 bits (0 to 255)
//          bar can hold 16 bits (0 to 65,535)
//
//     const foo: u8 = 20;
//     const bar: u16 = 2000;

Would you mind adding this change as well?
Thank you!


Remove Github new user requests for IT Catalogue

User Need
As an Operations Engineering Team
I want a single manual process for requesting new Github user accounts
so that we can ensure joiner policies are being followed and we can better manage our Github licences
We would like to either remove the catalogue items altogether or have the information pointing users to #ask-operations-engineering in the catalogue. Either way users should not be able to submit a request via the IT Service Catalogue.
Value
Removing this manual process would ensure that all requests are coming via one route so that we can ensure policies are being applied consistently e.g. collaborators. Removing this other channel for requests will also enable removal of some Github owners.
Functional Requirements:

Remove "GitHub for D&T staff - Add/Amend/Remove" from the IT Catalogue

Acceptance Criteria:

Catalogue item no longer exists. All new requests coming via Ops Eng.

Notes:

Moved out of 'in progress' while Leon is off.

Request Item > RITM1548669 closed complete


Reducing time to merge in merge_masks.py w/i ez_segmenter

Is your feature request related to a problem? Please describe.
merge_masks.py takes a long time to run in ez_segmenter, especially when running through large datasets (>1000 FoVs) with hundreds of cells / FoV.
Describe the solution you'd like
Reduce merge time by limiting scope of potential cells-to-merge to the area surrounding the object to be merged. Also adding testing for this method.
Describe alternatives you've considered
Pararellization of FoV's also considered but may need to be a separate undertaking.
Additional context
Add any other context or screenshots about the feature request here.

Pre-updated merge code: top (time to merge = 18+ hrs)
Post-updated merge code: bottom (time to merge: 2+ min)


Archlinux compile error

Describe the bug

Compile errors during installation

To Reproduce
Steps to reproduce the behavior:

try to install with aur or cargo or try to compile from source

Expected behavior

A normal install

System information:

Distro: Arch Linux
Compositor: Hyprland
Ironbar version: 0.11

Additional context

I already checked if had al the build dependencys and even checked the rust errors and found out that one is related to an import problem and the other is trying to use a private function out of scope

Screenshot

This looks like it's caused by an old version of the rust toolchain. Can you try updating that (rustup updateif you installed via rustup) and see if that resolves it?

yeah thanks that solved it I'm closing the issue


improve ocropy processor

I tried applying your Python 3 port / workspace processor of ocropy, but the results were really bad on OCR-D GT. (I always use OCR-D-GT-SEG-LINE on different models, like LatinHist-98000.pyrnn.gz from chreul, incunabula-00184000.pyrnn.gz from GT4HistOCR or fraktur-jze.pyrnn.gz from jze. Those models are reported to achieve CER < 10%, and I can reproduce that when applying them on the test files in GT4HistOCR, which are deskewed, cropped and binarized / flattened properly. But I get CER >> 10% when applying them on our GT with your processor.)
By investigating, I found that many models expect dewarping to be disabled, so I added this option to the processor. Also, the GT data are still raw, so I re-enabled binarization and made the actual method selectable. I got best results when I added the full binarization from ocropus-nlbin, which also includes deskewing. Now the line images extracted from preprocessing look a lot more like the data in GT4HistOCR (although the threshold parameters could be optimised a bit). Recognition results are also much better than before, but I still do not get CER < 10%.
The most prominent difference of our line images is that large segments of the neighbouring lines still appear, so I guess one needs to re-crop after deskewing (but I don't know how to do that). But it might also be that the GT segmentation is the culprit (it seems to be off vertically).
Other improvements here are: error handling, ocropy sanity checks, no temporary files and CER calculation.
I hope you find these useful. Please let me know if you require further changes or splitting into smaller commits. Also, I would be happy to share my measurements and sample images.
review requested – @finkf @wrznr @kba ?

I was not sure if ocropy should do all the image preprocessing. There should be other steps in the ocr-d workflow that improve the image quality for the later ocr-step.

I'm OK to merge this

I was not sure if ocropy should do all the image preprocessing. There should be other steps in the ocr-d workflow that improve the image quality for the later ocr-step.

I agree. But where are they? So far I can only see the binarization in ocrd_kraken, but that does no deskewing (which seems to be important with OCR-D GT) and probably ocrd_olena. Both are not useable right now. Also, some steps (like dewarping) depend on the OCR model to use.

Maybe we should open an issue about a workable pipeline for GT – but where?

No idea. Maybe core?


extractcsvtables should update index.csv rather than replacing it

In case a previous run has written an index, that new index should be added to, rather than truncated and left containing only files created/modified from the latest run only.

Fixed in da20a8ec29c8b895d180b99ff5a8e1cffbe02c78.


Crash Report -2014523872

Link:
https://wowsims.github.io/cata/paladin/retribution/#eJzjUuVgFGB0YMxgLGDsYGScwci4gpHxACPjDUbGF4yMDUyMHUyMG5gYnbgEGC0YPRgjgAqFGKResMxiZgvISaxMLeJgFWCRWs3IxS9w8BGTxEtZJbZth5n27GDiYhH4/ZSJi0egaS+TxANZJeZzZ5m42AXagIpOcwBVn3rBJLFFUokNqBSkmktg7j4miVY5JUYGLl6B/3uYJA7zKLEAZRi4OAUanjEpMYNU8Qs0Ak17LwvWdmIHyMC+XUwSn2SBtr1+ArJz13MQ+WYviHx9HqTgwG4mibOyXAxA5uNzTEDzlbg5GA0kAoB+mcDIqAVU2cHEMArAQMiAVB1WDE4MuxjZpFi4mCSYdzFJGxkY6xoY6RoZGwGRIRABgbGBoREQH2IS4Wg5yKTw/BKTRvdBJosXl5gczlxiOsHEcoGJ8xYTwyMmJgnGF0wpC5khRkc6dDEzKN1h4gTzGtIcBCHiIg6Ss2aCwEl7S4jIBXvFNDC4Zu949gwIvLE3WsykECHBqkXjyNXodCBHW0PKcbL0UQIggbX3vYMjhP/DPoERAODAdyI=
RNG Seed:<PHONE_NUMBER>
Spell {OtherID: 3, Tag: 1} missing CritMultiplier
Stack Trace:
goroutine 15 [running]:
runtime/debug.Stack()
/opt/hostedtoolcache/go/1.21.9/x64/src/runtime/debug/stack.go:24 +0x6
github.com/wowsims/cata/sim/core.runSim.func1()
/home/runner/work/cata/cata/sim/core/sim.go:123 +0x10
panic({0x1039a0, 0x302e370})
/opt/hostedtoolcache/go/1.21.9/x64/src/runtime/panic.go:914 +0x2c
github.com/wowsims/cata/sim/core.(*SpellResult).applyAttackTableCrit(0x338e870, 0x338e6c0, 0x31604d0, 0x3feaa2c2b2545b21, 0x3aff9c8)
/home/runner/work/cata/cata/sim/core/spell_outcome.go:471 +0x1f
github.com/wowsims/cata/sim/core.(*Spell).OutcomeMeleeWhite(0x338e6c0, 0x335eea0, 0x338e870, 0x31604d0)
/home/runner/work/cata/cata/sim/core/spell_outcome.go:166 +0x95
github.com/wowsims/cata/sim/core.(*Spell).calcDamageInternal(0x338e6c0, 0x335eea0, 0x33f2000, 0x408cda74faa6730b, 0x3ff07ae147ae147b, 0x0, 0x3affc38)
/home/runner/work/cata/cata/sim/core/spell_result.go...

When will paladins learn to read… the paladin sim is not released yet.

Hey, just gonna say, replying like this is super unprofessional. People
make mistakes, and this could have been handled much better.
On Wed, May 8, 2024, 02:52 rosenrusinov @.***> wrote:

When will paladins learn to read… the paladin sim is not released yet.
—
Reply to this email directly, view it on GitHub
https://github.com/wowsims/cata/issues/359#issuecomment-2099866723, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BILEMMXEPB5DZ3YSOTONAQ3ZBHDS7AVCNFSM6AAAAABHMIOCDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJZHA3DMNZSGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

Something I'd like to point out, is that I found this tool through Google
and assumed it would work. There was nothing easily visible on the sim page
that suggested that it wouldn't work. I was simply doing as the website
instructed to submit the report.
You need to do better to make this tool easier for the average player to
understand if you want to avoid getting more reports like this.
On Wed, May 8, 2024, 02:52 rosenrusinov @.***> wrote:

When will paladins learn to read… the paladin sim is not released yet.
—
Reply to this email directly, view it on GitHub
https://github.com/wowsims/cata/issues/359#issuecomment-2099866723, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BILEMMXEPB5DZ3YSOTONAQ3ZBHDS7AVCNFSM6AAAAABHMIOCDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJZHA3DMNZSGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fixed the issues with the App-app-sso-client Node.js sample.

Build Pipeline -
https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/10233574648


Merge cmf cmf callgraph and develop

Pull Request Test Coverage Report for Build 485124070

1078 of 4921 (21.91%)  changed or added relevant lines in 561 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-18.5%) to 47.429%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/newExploreButtonFor..st
0
1
0.0%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/newLineMorphFor..st
0
1
0.0%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/valuesMorphFor..st
0
1
0.0%

packages/Babylonian-Core.package/BPCallgraphPathContextSenderChanged.class/instance/doBrowse.st
0
2
0.0%

packages/Babylonian-UI.package/BPAssignmentProbeMorph.class/instance/valueMorphFor.trace..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomDoubleClickFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomKey.pressedFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomMenu.for..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/topDoubleClickFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/topKey.pressedFor..st
0
2
0.0%

Totals

Change from base Build 480598535:
-18.5%

Covered Lines:
5101

Relevant Lines:
10755

💛  - Coveralls

Pull Request Test Coverage Report for Build 485124070

1078 of 4921 (21.91%)  changed or added relevant lines in 561 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-18.5%) to 47.429%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/newExploreButtonFor..st
0
1
0.0%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/newLineMorphFor..st
0
1
0.0%

packages/Babylonian-UI.package/BPProbeMorph.class/instance/valuesMorphFor..st
0
1
0.0%

packages/Babylonian-Core.package/BPCallgraphPathContextSenderChanged.class/instance/doBrowse.st
0
2
0.0%

packages/Babylonian-UI.package/BPAssignmentProbeMorph.class/instance/valueMorphFor.trace..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomDoubleClickFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomKey.pressedFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/bottomMenu.for..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/topDoubleClickFor..st
0
2
0.0%

packages/Babylonian-UI.package/BPBrowserSidebarVisualizationEntriesWithDetails.class/instance/topKey.pressedFor..st
0
2
0.0%

Totals

Change from base Build 480598535:
-18.5%

Covered Lines:
5101

Relevant Lines:
10755

💛  - Coveralls


Unexpected rendering issue for v1 mode

Operating system
Ubuntu 20.04.4 LTS
Helmfile Version
0.152.0
Helm Version
3.11.2
Bug description
I've started to look into our helmfile v1 mode and bumped into an issue.
In the attached helmfile.yaml.gotmpl the $configDir variable is added as a value, and within same yaml document the environments (attached envs.yaml) section is loaded, which uses the configDir previously added .Values. However, in v1 mode this fails with:
in ./helmfile.yaml.gotmpl: error during helmfile.yaml.gotmpl.part.0 parsing: template: stringTemplate:9:6: executing "stringTemplate" at <tpl (readFile $envFile) .>: error calling tpl: template: stringTemplate:4:18: executing "stringTemplate" at <.Values.configDir>: map has no entry for key "configDir
Without v1 mode it works fine, i.e. configDir in .Values is instantly exposed to the envs.yaml rendering, even if adding of configDir to .Values is done within same yaml document as the envs.yaml rendering.
Using attached files this can be reproduced by:
export HELMFILE_V1MODE=true && helmfile -e prod template
It is working with:
export HELMFILE_V1MODE=false && helmfile -e prod template
Example helmfile.yaml
helmfile.yaml.gotmpl :
{{ $configDir := default (env "CONFIG_DIR") | default "config" }}
values:
- configDir: {{ $configDir }}
{{ tpl (readFile (printf "%s/envs.yaml" $configDir)) . }}
---
repositories:
- name: incubator
  url: https://charts.helm.sh/incubator
---
releases:
- name: service-a
  chart: incubator/raw
  values:
  - resources:
    - apiVersion: v1
      kind: ConfigMap
      metadata:
        name: raw1
        namespace: default
      data:
        foo: {{ .Values | get "some-random-key" "" }}

envs.yaml :
environments:
  prod:
    values:
      - {{ .Values.configDir }}/envs/prod/values.yaml

config/envs/prod/values.yaml :
some-random-key: with-some-random-value
Error message you've seen (if any)
in ./helmfile.yaml.gotmpl: error during helmfile.yaml.gotmpl.part.0 parsing: template: stringTemplate:9:6: executing "stringTemplate" at <tpl (readFile $envFile) .>: error calling tpl: template: stringTemplate:4:18: executing "stringTemplate" at <.Values.configDir>: map has no entry for key "configDir
Steps to reproduce
See bug description
Working Helmfile Version
N/A
Relevant discussion
No response

@mumoshu

Hey @gakesson and @yxxhero! Thank you so much for your support as always ❤
I just reviewed this, and I think this is supposed to fail in helmfile v1 because it depends on the double-rendering feature we will disable in v1.
gakesson's (original)
{{ $configDir := default (env "CONFIG_DIR") | default "config" }}
values:
- configDir: {{ $configDir }}
{{ tpl (readFile (printf "%s/envs.yaml" $configDir)) . }}

is almost equivalent to
gakesson's (how it's treated)
{{ $configDir := default (env "CONFIG_DIR") | default "config" }}
values:
- configDir: {{ $configDir }}
environments:
  prod:
    values:
      - {{ .Values.configDir }}/envs/prod/values.yaml

This is a template that must be rendered before decoding the YAML data. At the render time values are not present because it isn't decoded as YAML yet.
I think @yxxhero got this and rewrote @gakesson's example so that the values and environments parts are separated with ---. This removes the dependency on double-rendering and, therefore, should work.
Hey @yxxhero, did you example work? (I presume so- just confirming!
I can suggest further enhancing yxxhero's awesome example to keep configDir definition DRY.
yxxhero's
{{ $configDir := default (env "CONFIG_DIR") | default "config" }}
values:
- configDir: {{ $configDir }}
---
{{ $configDir := default (env "CONFIG_DIR") | default "config" }}
{{ tpl (readFile (printf "%s/envs.yaml" $configDir)) . }}

My suggestion (in case you want to keep configDir definition DRY
values:
- configDir: {{ default (env "CONFIG_DIR") | default "config" }}
---
{{ tpl (readFile (printf "%s/envs.yaml" .Values.configDir)) . }}

Note also that you should be able to apply my suggestion before migrating to v1!
Does my explanation makes sense, @gakesson? I'd appreciate any feedback/comment/etc from you! Thanks ❤

So we should give some tips when running helmfile？ WDYT？ @mumoshu

my example works fine. you got me. @mumoshu

@yxxhero Thanks for your confirmation! Yeah if you are to add a warning message that let the user know that this is an instance of double-rendering and needs an additional --- before upgrading to v1, that would be awesome!

Hello @mumoshu and @yxxhero ,
Thanks for input!
Maybe I misunderstood but I'm not able to get @yxxhero example to work.
If I run the helmfile attached in this issue it fails with:
export HELMFILE_V1MODE=true && helmfile -e prod template
err: no releases found that matches specified selector() and environment(prod), in any helmfile

The specified environment prod is required to be defined in the first yaml document, which happens in the tpl/readFile command so that tpl/readFile can't be deferred?

@gakesson yes. you are right. I will see this issue.

The no releases found that matches specified selector() and environment(prod), in any helmfile error typically happen when the whole helmfile config (the result of rendering and merging all the helmfile parts separated by ---) misses the prod environment even though you specified -e prod.
So... I'm unsure why that happens in this case 🤔 Does it fail on both  v0 and v1 modes? If so, the environment existence check might be happening too early (bug)?

@mumoshu yes, both v0 and v1 expects that the environment is defined in the very first yaml document. This has been the case as far as I can remember (~1 year).
Relaxing this constraint, pushing validation later if possible, would certainly address the issue observed here. Then we can simply do as @yxxhero proposes.
Thoughts?

Just to give a helmfile to reproduce the "eager" no releases found that matches specified selector() and environment(prod), in any helmfile error:
{{ $configDir := "config" }}
values:
- configDir: {{ $configDir }}
---
environments:
  prod:
    values:
      - some-random-key: with-some-random-value
---
repositories:
- name: incubator
  url: https://charts.helm.sh/incubator
---
releases:
- name: service-a
  chart: incubator/raw
  values:
  - resources:
    - apiVersion: v1
      kind: ConfigMap
      metadata:
        name: raw1
        namespace: default
      data:
        foo: {{ .Values | get "some-random-key" "" }}
        bar: {{ .Values.configDir }}

@gakesson would you like to work on this feature?

I can give it a try, but is it agreed how we want it to behave?
I don't mind deferring the environment validation (to after rendering?), but not sure what implications that come with and how feasible it is.

@mumoshu WDYT?

@gakesson Thanks for your confirmation! I intended to validate the environment's existence before execution and after fully loading the helmfile.yaml content. So it looks rather like a bug to me, and I would consider changing it to defer the validation as a bug fix!

I agree this could be considered a bug, that the crucial part is that the specified environment is defined at some point, not as today that it has to be defined in the first yaml document.
@yxxhero @mumoshu - relabel this as a bug?

I checked the code a bit and I have a couple of doubts. In this func...
https://github.com/helmfile/helmfile/blob/main/pkg/app/app.go#L817
...each state file is rendered then processed in that order, so if we have multiple state files we have the algorithm render, process, render, process, and so on.
It is pretty straight-forward to move the verification of defined env inbetween render and process (instead of as today, after first  yaml part/document), but then it still mandates that the env is defined somewhere in the first state file. So if we load 2 files and the env is defined in the second file such solution would fail. Perhaps a reasonable limitation but not very obvious?
Breaking up this func, i.e. to first render all state files first and then process them in order, seems feasible but I'm not sure you want to take that route.
WDYT @mumoshu and @yxxhero ?

@mumoshu ping

@mumoshu @yxxhero did you get some time to look into how to approach this issue (e.g. my solution queries)? As I said before, I would love to see this issue get resolved so we can go ahead with v1.

Sorry for the delay!

It is pretty straight-forward to move the verification of defined env inbetween render and process (instead of as today, after first yaml part/document), but then it still mandates that the env is defined somewhere in the first state file. So if we load 2 files and the env is defined in the second file such solution would fail

@gakesson I'm not sure if this is correct-
As far as I can tell, we already does that via https://github.com/helmfile/helmfile/blob/1843cc447e2d38733110927d4e4efa12f0078efe/pkg/app/app.go#L818, by loadDesiredStateFromYaml loading all the parts from a helmfile.yaml and reader it one-by-one, merging the results to finally form the state to be processed by visitStates.
If the error mentioned in https://github.com/helmfile/helmfile/issues/807#issuecomment-1515287329 happens for the example, I'd assume the bug might be in loadDesiredStateFromYaml, where it won't produce necessary environments or releases? 🤔

My debugger says loadDesiedStateFromYaml is failing with "failed to read helmfile.yaml: environment \"prod\" is not defined" and that ends up with the app.go code finally throwing the err: no releases found that matches specified selector() and environment(prod), in any helmfile error.
Although the error is surfaced by app.go, it become more likely that loadDesiredStateFromYaml is somehow not working well 🤔

@gakesson please try to use the latest version by building the main branch.

Hello @yxxhero , @mumoshu et al!
I'm so sorry for late reply, I've been on leave for past weeks.
I built latest master (0.154 was still failing) and it works as expected! Really nice to see you've resolved this issue.


libvtk issue with if,3d ros

I have successfully built and installed ifm3d and now I want to install the ros package but I get this error, anyone knows what is the problem here?

Base path: /home/pedram/catkin-ws/ifm3d
Source space: /home/pedram/catkin-ws/ifm3d/src
Build space: /home/pedram/catkin-ws/ifm3d/build
Devel space: /home/pedram/catkin-ws/ifm3d/devel
Install space: /home/pedram/catkin-ws/ifm3d/install

Running command: "make cmake_check_build_system" in "/home/pedram/catkin-ws/ifm3d/build"

Running command: "make -j8 -l8" in "/home/pedram/catkin-ws/ifm3d/build"

[  0%] Built target std_msgs_generate_messages_cpp
[  0%] Built target std_msgs_generate_messages_py
[  0%] Built target std_msgs_generate_messages_eus
[  0%] Built target std_msgs_generate_messages_lisp
[  0%] Built target _ifm3d_generate_messages_check_deps_SoftOff
[  0%] Built target _ifm3d_generate_messages_check_deps_Config
[  0%] Built target _ifm3d_generate_messages_check_deps_Trigger
[  0%] Built target _ifm3d_generate_messages_check_deps_Extrinsics
[  0%] Built target _ifm3d_generate_messages_check_deps_Dump
[  0%] Built target _ifm3d_generate_messages_check_deps_SoftOn
[  0%] Built target std_msgs_generate_messages_nodejs
[ 17%] Built target ifm3d_generate_messages_cpp
[ 34%] Built target ifm3d_generate_messages_lisp
[ 57%] Built target ifm3d_generate_messages_py
[ 77%] Built target ifm3d_generate_messages_eus
[ 94%] Built target ifm3d_generate_messages_nodejs
[ 94%] Built target ifm3d_generate_messages
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libvtkproj4-6.2.so.6.2.0', needed by '/home/pedram/catkin-ws/ifm3d/devel/lib/libifm3d_ros.so'.  Stop.
CMakeFiles/Makefile2:1385: recipe for target 'ifm3d/CMakeFiles/ifm3d_ros.dir/all' failed
make[1]: *** [ifm3d/CMakeFiles/ifm3d_ros.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j8 -l8" failed

Updating libvtk solved the issue


How to change text color on onItemViewFocusChanged?

Hi i'm getting stuck on this, i need to change the text color of my item when getting focus.
I have try onFocusChange on my CustomViewHolder, but nothing happen when the focus is changed.
Can anybody help?is it possible to change the element text color on onItemViewFocusChanged?
Thank you in advance.

yes, you can change text color on "onItemViewFocusChanged"
Because the default Recyclerview will consume the focus, if you want to change in you customViewHolder, you can make isAutoProcessFocus attr false.


Move segment aliasing to linkall.x

This allows other projects to define their own alias whilst still being able to use esp-hal linker scripts. I will be using this trick in the flasher stub
Thank you!
Thank you for your contribution.
Please make sure that your submission includes the following:
Must

[x] The code compiles without errors or warnings.
[x] All examples work.
[x] cargo fmt was run.
[ ] Your changes were added to the CHANGELOG.md in the proper section.
[x] You updated existing examples or added examples (if applicable).
[x] Added examples are checked in CI

Nice to have

[x] You add a description of your work to this PR.
[ ] You added proper docs for your newly added features and code.

This is now ready for review. I don't think its worth adding a changelog entry for this.


Global Cache issue with Cloudflare

Most users still experience cache issues and are not able to either see the website or are seeing the old version.
Clear local cache will fix this.
But have you guys tried to purge global cache on Cloudflare?
Purge everything through your Cloudflare dashboard
Reminder: We highly recommend performing single-file purges.

Login to Cloudflare and select the site with the resources to purge.
Click the Caching app.
In the Purge Cache pane, click Purge Everything.
A warning dialog appears.
If you agree, click Purge Everything.

https://support.cloudflare.com/hc/en-us/articles/200169246-Purging-cached-resources-from-Cloudflare
I can see cache and not being able to reach the website is a on-going issue. I know a lot of investors have an issue with this.
Hope it gets fixed.

I would also add in a time to live action to help force a cache refresh in the browsers
https://support.cloudflare.com/hc/en-us/articles/360043842472-Configuring-cache-TTL-by-status-code

Issue still exist..
14 days later, still haven't fixed cache.. But you have banned me on telegram because I "fuddled"..
Fix your communication skills on TG.


error: error opening input file 'myproj/node_modules/react-native-video-processing/ios/RNVideoProcessing-Bridging-Header.h' (No such file or directory)

Current Behavior

Cannot build the project on iOS, I've tried configuring following the video. Step by step.
Followed many threads, but couldn't find any workable solution.
Still get this error:
error: error opening input file 'myproj/node_modules/react-native-video-processing/ios/RNVideoProcessing-Bridging-Header.h' (No such file or directory)
I'm really stuck here, help anyone?
Expected Behavior

Your Environment

software
version

react-native-video-processing
1.20.0

react-native
0.61.2

node

I had the exact issues. Follow this thread: https://github.com/shahen94/react-native-video-processing/issues/276

@xlogix I was able to configure the project on iOS successfully, thank you.
The issue I'm facing now is:
TypeError: Cannot read property 'compress' of undefined
I don't know exactly what is wrong.
Since the very same code is working on Android.
Any help?

This particular issue was resolved using
Bunhouth's fork.
However there are other issues.

Please send a PR to my fork so we van resolve that issue too.


Added a check for site status

Pre-Flight checklist

[x] Testing

[x] Changes have been manually tested

What are the relevant tickets?
closes #1404
What's this PR do?
Adds a check on live-publish-status
How should this be manually tested?

Publish a site and verify its status is displayed as published on SiteDashboard
Unpublish a site and verify status is displayed as Draft on SiteDashboard

@Wassaf-Shahzad Could you please provide guidance for how to test this locally? On a local version of OCW Studio, this change appears to make all of the courses' status into Draft.

@Wassaf-Shahzad Could you please provide guidance for how to test this locally? On a local version of OCW Studio, this change appears to make all of the courses' status into Draft.
In particular, it looks like the variable site.live_publish_status may not be being set properly. Querying the backend of a local copy of the prod database, most sites have live_publish_status as succeeded. Also, should this check
https://github.com/mitodl/ocw-studio/blob/eb793b4f3bc1264e631cf6efbd1efef9b07a79c1/static/js/pages/SitesDashboard.tsx#L77
be looking for live_publish_status === "succeeded" rather than not null?

For local testing I was actually following this code and setting values from the admin panel
The reason I did not check for live_publish_status as succeeded is  since we can republish a course. Now in the case of a republish if the publish fails or is aborted the publish_date remains unchanged while  live_publish_status is changed to not None. In this case the user should see published (Since the course was never unpublished, just republished and failed) on the course card. In case of and unpublished event live_publish_status becomes none and we Draft is shown irrespective of publish_date.

What are the possible values of the status label?

@Wassaf-Shahzad Looking at the API response for GET /api/websites/?limit=10&offset=0, I think @pt2302 is correct that live_publish_status by WebsiteSerializer https://github.com/mitodl/ocw-studio/blob/09ef8c6f1972061704e933e0d0c226372dfafc0e/websites/serializers.py#L37-L47 (Looks like it's only included in the detail response).
I think we should just add the two publishing statuses to the list serializer.

It looks like the frontend Website type is the "detailed" response for /api/websites<site_name>, and a quick look makes me think we do not have a separate type for the less detailed paginated /api/websites response. (In contrast, we do have separate detail vs list types for WebsiteContent objects on the frontend.)
IMO we should probably just make the "detailed" and "less detailed" responses as similar as possible...at least include all the non-FK fields.

@Wassaf-Shahzad I'm also having trouble with this, as indicated above. It seems that all sites display "Draft" even when they are published.  I think the issue is with WebsiteSerializer as mentioned above (and the related issue that the typescript definition for the API response was incorrect. Sorry about that!)

@Wassaf-Shahzad Why did you add a new unpublished variable instead of passing the value of the existing live_publish_status variable to the frontend? To me, that would seem like a simpler route.

@Wassaf-Shahzad Why did you add a new unpublished variable instead of passing the value of the existing live_publish_status variable to the frontend? To me, that would seem like a simpler route.

Yes, since if you look at the description of the model property in websites/models.py, The unpublished property is specifically calculated to check whether  the course has been unpublished or not.
Also its not exactly new, since to pass the live_publish_status to the frontend would need the same amount of changes.
Also there are some things that i might need clarification on @ChristopherChudzicki .

We are using Websites.Meta.fields property in CreateWebsiteSerializer and WebsiteDetailSerializer, without inheriting WebsiteSerializer. Why ?

This results in some issue where serialisers fields (not directly coming from the model) need to be described in both of these models.

Would it not be better to just inherit the serialiser ?

Also if we cant inherit them for some reason or the other. We should make the common fields in Webiste.Meta.fields as a list of constants and add them in meta when needed.
  class Meta:
      fields  = [custom_fields] + common_fields


Assignment from none

Here is a draft of implementing PLE1128. I have a skeleton implementation and need assistance finishing it using Visitor or something similar. Looking for feedback, and suggestions on how to finish this off.

Thank you for this!
Looking at the rule... I don't think we have the compiler infrastructure necessary to support implementing this rule reliably (yet). We could maybe support it in some limited cases (e.g., calling a function from within the file that defines it), but we'd have a lot of false negatives, since we don't yet resolve references across files.
Could I help you pick out a different Pylint rule in lieu of this one?

Ah, cross-file support is not something I had considered just yet... what an interesting problem, I will spend some time considering how to do that once I better understand how Ruff works.
I would absolutely be open to suggestions! I'm from Dish Network and we use ruff across all our Python automation. I'm working with Dish internal teams to set up a process for more Dish devs to contribute to FOSS projects like ruff, so expect some more from us in the near future!

That's amazing to hear! Thanks so much for getting involved.
A good chunk of the outstanding Pylint rules can't be implemented yet without improving some of our internal infrastructure, but from scanning the list, here are a few that are doable: R0206, W1507, W0124.

@charliermarsh Is there an open issue/discussion about the said infrastructure? If there are knowledge gaps or decisions that require input, I'd like to help.

@tusharsadhwani - There isn't, it's not yet a priority, but I'll keep this in mind as we start to think through it.

(Going to close for now as I don't think we're able to implement this with our current infra.)

@charliermarsh I believe I have an idea for cross-file support, I don't quite know where I would begin tho:
What are your thoughts on having a lookup table that stores all declarations from all files in a given directory/workspace, (exact logic needs to be fleshed out). So at runtime, Ruff would first index all python files and store the filename and line number of any declaration, (class, function, etc). When Ruff encounters one of these objects, it would use the lookup table to find the declaration of that object, and proceed from there.

@wiwa5606 as it turns out it's actually not that straightforward.
Even if you had a way to reliably detect every import as a relative import (as opposed to one coming from the built-in modules, 3rd party libraries or a modified sys.path), you still have the problem of having multiple definitions of the thing in the same file, figuring out whether only one of them is reachable, sometimes multiple declarations can be under a sys.version check to support multiple python versions, the thing you're looking for could be nested inside another scope (like a class), ...
Both building an import graph and finding the declaration for the said name or attribute are both really complex problems.

I hope to end up building support for all of those things, but it will admittedly take a lot of time and work. The core ideas are likely correct though: learn to resolve imports (including non-first party imports), do a pass over every file to build its symbol table, and lookup in the module symbol table as you analyze bindings.

Right, 3rd party imports and os.path manipulation. There's always another thing...
It almost sounds like Ruff needs its own interpreter to do that resolution, I don't know if that will be too slow though. I'm obviously lacking a solid understanding of how Ruff does what it does today, so I don't quite know the specifics. I'm more than willing to pitch in if that's something that is being considered.


Align matter-devices xml file with spec for on-off light device type

Problem

matter-devices.xml file is not aligned with spec
Fixes a part of #20809

Change overview

Aligns xml files with spec for on-off light device types

Testing

no testing required

@bzbarsky-apple @tcarmelveilleux PTAL

File loading time: 174ms
{
commandRef: 100,
fieldIdentifier: 1,
label: 'DayOfWeekForSequence',
name: 'DayOfWeekForSequence',
type: 'DayOfWeek',
code: undefined,
isArray: false,
presentIf: null,
isNullable: false,
isOptional: false,
introducedInRef: null,
removedInRef: null,
countArg: null,
caption: 'Command argument of type DayOfWeek',
isBitmap: true
}
⇝
⇝ /__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:463
throw new Error(item.type + ' not found.');
^
Error: DayOfWeek not found.
at enhancedItem (/__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:463:9)
at /__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:487:7
at Array.forEach ()
at /__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:486:23
at Array.forEach ()
at enhancedCommands (/__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:485:12)
at Object.Clusters.init (/__w/connectedhomeip/connectedhomeip/src/app/zap-templates/common/ClustersHelper.js:727:20)

building of zap failed with this error, but I haven't made any changes in this file @woody-apple @bzbarsky-apple any idea about this?

building of zap failed with this error

It's a random failure, though I have only seen it with a different enum... @tecimovic @vivien-apple


Add access example to DataFrame docs (#1001)

To start, I added one example that shows what happens when trying to access a data frame column that does not exist.
I'm not sure how much to go into some of the comments in #1001, e.g., the fact that an error is raised instead of returning nil and other aspects of the Access behaviour that might be surprising.
What do you think, should it be kept simple like this or should I add something specifically about Access behaviour?

What other aspects of the Access implementation did you maybe want to highlight?

Mainly some of the aspects from this discussion: https://elixirforum.com/t/access-behaviour-for-explorer-dataframe/66691. (Though, looking at the username, I think you might already be in that discussion!)
To summarize that thread, I was surprised by the fact that DataFrame had a different Access behavior than what the docs for the Access behavior would imply. E.g., raising rather than returning nil, fetch raising rather than returning :error, Access.fetch! raising ArgumentError rather than KeyError, etc.
I wasn't sure if these doc change was the spot to get into all of that though.

Yep that's me!
I wanted to clarify because some points (like not needing to implement fetch!) were cleared up in the post but others weren't. I figured it'd be a good idea to make a fresh list all the stuff we might want to document here.
If we do want to include more than what's ["not_a_column"] raising vs. returning nil, I think I'd prefer to include a brief overview of the reasoning behind the design choices. Something like:
### Missing columns

Explorer will generally raise an `ArgumentError` if the argument to `[]` is not
found, but not always. For example:

...your example...

This deviates from other `Access` implementations which return `nil` when the
key is not found. We raise early to help users catch errors quicker since most
DataFrame operations could not meaningfully continue if the result was `nil`.

We also raise an `ArgumentError` rather than a `KeyError`. This is because `[]`
is designed to take a wider collection of arguments than a single key, e.g.
lists and regexes.

However, note that some `[]` calls will not raise if their argument is not
found. This occurs when argument to `[]` is more of a search criteria like
a regex:

    iex> df = Explorer.DataFrame.new(col_1: [1], col_2: [2], other: ["a"])
    iex> col_n_regex = ~r/^col_\d$/
    iex> df[col_n_regex]
    #Explorer.DataFrame<
      Polars[1 x 2]
      col_1 s64 [1]
      col_2 s64 [2]
    >
    iex> nothing_will_match_regex = ~r/not_a_pattern/
    iex> df[nothing_will_match_regex]
    #Explorer.DataFrame<
      Polars[0 x 0]
    >

I'm not married to any of that language. But explaining the "why" might be nice (if the team agrees!).

But explaining the "why" might be nice

I like the idea of adding some clarification of the reasoning of why things were designed this way.  For me, it was pretty surprising to see the same action (trying to access a column) have different result depending on the argument, (sometimes raising, sometimes returning an empty dataframe, etc.).
(note: this got a bit rambling, there is a summary at the bottom)
More examples
To be honest, I don't understand the reasoning behind sometimes raising and sometimes returning an empty dataframe.  E.g., for this dataframe:
iex(1)> df = DataFrame.new(a: [1, 2])
#Explorer.DataFrame<
  Polars[2 x 1]
  a s64 [1, 2]
>

This raises:
iex(2)> df["b"]
** (ArgumentError) could not find column name "b". The available columns are: ["a"].
If you are attempting to interpolate a value, use ^b.

    (explorer 0.9.2) lib/explorer/shared.ex:252: Explorer.Shared.maybe_raise_column_not_found/3
    (explorer 0.9.2) lib/explorer/shared.ex:187: anonymous fn/4 in Explorer.Shared.to_existing_columns/3
    (elixir 1.17.2) lib/enum.ex:1829: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3
    (explorer 0.9.2) lib/explorer/shared.ex:175: Explorer.Shared.to_existing_columns/3
    (explorer 0.9.2) lib/explorer/data_frame.ex:3984: Explorer.DataFrame.pull/2
    (explorer 0.9.2) lib/explorer/data_frame.ex:373: Explorer.DataFrame.fetch/2
    (elixir 1.17.2) lib/access.ex:322: Access.get/3
    iex:2: (file)

But this returns an empty data frame:
iex(2)> df[~r/b/]
#Explorer.DataFrame<
  Polars[0 x 0]
>

Asking for the 2nd column raises:
iex(3)> df[1]
** (ArgumentError) no column exists at index 1
    (explorer 0.9.2) lib/explorer/shared.ex:240: Explorer.Shared.fetch_column_at!/2
    (explorer 0.9.2) lib/explorer/shared.ex:178: anonymous fn/4 in Explorer.Shared.to_existing_columns/3
    (elixir 1.17.2) lib/enum.ex:1829: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3
    (explorer 0.9.2) lib/explorer/shared.ex:175: Explorer.Shared.to_existing_columns/3
    (explorer 0.9.2) lib/explorer/data_frame.ex:3984: Explorer.DataFrame.pull/2
    (explorer 0.9.2) lib/explorer/data_frame.ex:373: Explorer.DataFrame.fetch/2
    (elixir 1.17.2) lib/access.ex:322: Access.get/3
    iex:3: (file)

But this returns a data frame with just column a even though I'm asking for the first both the 1st and 2nd columns:
iex(3)> df[0..1]
#Explorer.DataFrame<
  Polars[2 x 1]
  a s64 [1, 2]
>

Comparing to R's tidyverse
I'm not making a value judgement on this, rather trying to explain what I found confusing.  Consider this R tidyverse example.  Here is a data frame.
 > df <- tibble(a = 1:2)
> df
# A tibble: 2 × 1
      a
  <int>
1     1
2     2

And here attempting to access a column that doesn't exist:
 > df["b"]
Error in `df["b"]`:
! Can't subset columns that don't exist.
✖ Column `b` doesn't exist.

That gives an error similar to Explorer.  And the result of selecting columns from a data frame with regex also behaves like Explorer, by giving an "empty" dataframe.
> df |> select(matches("b"))
# A tibble: 2 × 0

Same behavior when accessing a column by index when that index is out of bounds (R using 1-based indexing):
> df[2]
Error in `df[2]`:
! Can't subset columns past the end.
ℹ Location 2 doesn't exist.
ℹ There is only 1 column.

But doing the equivalent of the df[0..1] example from Explorer:
> df[1:2]
Error in `df[1:2]`:
! Can't subset columns past the end.
ℹ Location 2 doesn't exist.
ℹ There is only 1 column.

That raises an error in R, whereas Explorer gives the data frame with just column a returned.
Summary
Explorer's access behavior is surprising to me in some ways.  Not making a judgement on how it should be, since I don't have enough experience with Explorer, just trying to think of ways that docs could make it clearer.
I think some of this stuff is out of the scope for this small PR though.  In fact, it would probably make sense as part of a cheat sheet or something like Explorer for Tidyverse users. I may have a go at putting something like that together, but it can be a big task.
(There was a discussion here about cheat sheets too.)

To summarize and expand a little, here are your uses in the three relevant libraries:

Use
Explorer
Tidy
Polars

Specific column
df["b"]
df["b"]
df["b"]

String match
df[~r/b/]
select(df, matches("b"))
df.select(cs.matches("b"))

Range past end
df[0..1]
df[1:2]
df[0:2]

And here are their outputs:

Use
Explorer
Tidy
Polars
Agreement?

Specific column
ArgumentError
Error
ColumnNotFoundError
✅ Yes

String match
DataFrame
DataFrame
DataFrame
✅ Yes

Range past end
DataFrame
Error
DataFrame
❌ No

So there's only a mismatch on the range one if I'm following. And I agree it's a bit borderline (and admit I was surprised ranges didn't raise). But when designing the API, the Explorer team is balancing a few tensions: what makes sense in Elixir, what data scientists are used to, what's feasible to implement today via Polars, etc. In this case, though I can't say for sure, I think we just defaulted to how Polars handles ranges rather than the tidyverse. Both seem somewhat reasonable to me.

But regardless of the reasoning behind individual design decisions, clearer/better docs are almost always the right call.
And as for the cheatsheet stuff, it would be appreciated! Even a start that can be improved upon later.

I think we should raise for ranges out of bounds, for consistency within DataFrames and also with Nx.

Issue for raising with ranges: https://github.com/elixir-explorer/explorer/issues/1005
Thanks for pointing it out, @mooreryan!

But when designing the API, the Explorer team is balancing a few tensions: what makes sense in Elixir, what data scientists are used to, what's feasible to implement today via Polars, etc.
...
But regardless of the reasoning behind individual design decisions, clearer/better docs are almost always the right call.

This sort of info would be pretty cool to have in docs somewhere--I'm just not sure where they would ideally go.

Yeah I'm not sure. Maybe our contributor's guidelines?

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


Use different nonce for comment incentives

Context
Check this issue
There are 2 permits generated:

https://github.com/ubiquity/ubiquity-dollar/issues/780#issuecomment-1696422095 (issue solver reward)
https://github.com/ubiquity/ubiquity-dollar/issues/780#issuecomment-1696422165 (issue creator reward)

Right now we use issue.node_id as a permit nonce so those 2 permits are using the same nonce. It means that only 1 of those permits is claimable.
We should change the logic of how permit nonce is generated so that the permit (bounty reward + comment incentives) could be claimed by different bounty hunters in a single issue.
Perhaps we could generate nonce smth like keccak256(issue.node_id . bountyHunter.user_id).
Tasks

Consolidate the permits based on contributor (right now there can be multiple posted for a single contributor.)

When combined, the caption should list out all of the reasons. e.g. "Issue creator, and assignee rewards: "

Use the issue ID and user ID for the nonce.

This enforces that a contributor can only get paid out one time per issue.

I think it would be best to:

Consolidate the permits based on contributor (right now there can be multiple posted for a single contributor.)

When combined, the comment should list out all of the reasons. e.g. "Issue creator, and assignee rewards: "

Use the issue and user ID for the nonce.

This implies that a contributor can only get paid out one time per issue, which makes sense to me.

/assign

/start

Also, is it possible to demo with valueless tokens before Friday? We could even use omni-bridged UBQ governance tokens on Gnosis. I'll be demoing with small amounts so it should be fine.

There are 2 ways:

Create a separate organization and demo with WXDAI (in case of demoing with small amounts)
Add a new bot's config param payout-token. Then we will create a separate repo in the ubiquity org, setup a special demo repository with a repo wide config setup to accept some valueless token.

@devpanther I just realized that you picked this up. It's urgent and important so we're going to need to credit whoever delivers a working fix first.

@devpanther Will you make a priority of the current issue?

@devpanther Will you make a priority of the current issue?

Sure

Then we will create a separate repo in the ubiquity org, setup a special demo repository with a repo wide config setup to accept some valueless token.

Perhaps it can set it up on @ubiquibot org?

Then we will create a separate repo in the ubiquity org, setup a special demo repository with a repo wide config setup to accept some valueless token.

I am planning on demoing using the https://github.com/ubiquity/ubiquibar repo

Then why don't we simply use WXDAI because amounts are small and everything is already set in the ubiquity org?

That's what I was going to default to yes

That's what I was going to default to yes, but then I need to ask people for the money back lol

To sum up, we need to:

Add a new payment-token bot config param (for demo you will use this repo and this token)
Update pay.ubq.fi to accept the UBQ token

Correct?

Consolidate the permits based on contributor

I see that incentivizeComments and the actual closedCallback for Assignee Reward are on different handlers thus it would not be easy to merge assignee rewards and rewards from their comments.
Perhaps assignees shouldn't get incentivized for commenting on their issue? @pavlovcik @rndquu

Perhaps assignees shouldn't get incentivized for commenting on their issue? @pavlovcik @rndquu

I agree with that idea. It doesn't makes sense that the assignee get incentives about the comments himself.

Consolidate the permits based on contributor

I see that incentivizeComments and the actual closedCallback for Assignee Reward are on different handlers thus it would not be easy to merge assignee rewards and rewards from their comments.
Perhaps assignees shouldn't get incentivized for commenting on their issue? @pavlovcik @rndquu

Yes, as far as I remember assignees shouldn't get incentives for commenting, but this is a different case.
We have 3 parties who get rewards:

Issue assignee
Issue creator
Issue commenters

In this particular case issue assignee and issue creator are the same that is why we need to consolidate the reward (issue creator reward + issue solver reward) and generate a permit with a unique nonce (across a single issue) so that other parties (i.e. issue commenters) could also get their rewards.
This "reward consolidation" feature appeared in an effort to find a way to generate unique nonces for commenters. Perhaps we could generate nonces this way:

Issue assignee: keccak256(issue.node_id . bountyHunter.node_id . "ISSUE_ASSIGNEE")
Issue creator: keccak256(issue.node_id . bountyHunter.node_id . "ISSUE_CREATOR")
Issue commenter: keccak256(issue.node_id . bountyHunter.node_id . "ISSUE_COMMENTER")

If we want to consolidate all of the assignee's reward into one
We'd have to move incentivizeCreatorComment and incentivizeComments (post hooks) into the main action issueClosedCallback
That way we can share data amongst functions.

If we want to consolidate all of the assignee's reward into one
We'd have to move incentivizeCreatorComment and incentivizeComments (post hooks) into the main action issueClosedCallback
That way we can share data amongst functions.

Can't we just use the returning value of inventivizeCreatorComment and incentivizeComments(also incentivizePullRequestReviews will be added).

Can't we just use the returning value of inventivizeCreatorComment and incentivizeComments(also incentivizePullRequestReviews will be added).

It does not return, its a processor
GithubEvent.ISSUES_CLOSED]: {
    pre: [nullHandler],
    action: [issueClosedCallback],
    post: [incentivizeCreatorComment, incentivizeComments],
}

They cannot share data

Both incentivizeCreatorComment, incentivizeComments function adds the comment to the issue, right?
Instead of it, you can make them to return a comments as string and consolidate them and adds that consolidated comment to the issue at last.

You can call that functions inside issueClosedCallback\nDoes it make sense for you?

Yea, that's exactly the question I was asking..
I don't want to do that without knowing if there's a reason they separated the functions in two, a main callback and post callback
That's the only fix to our problem right now, so I'd just move all of the function to the main handler

@0xcodercrane
I guess this line was supposed to exclude assignee from comment rewards but assignee is an object.. not a login string
if (user.type == UserType.Bot || user.login == assignee) continue;

I'd exclude assingee.login from comment rewards now

You can call that functions inside issueClosedCallback\nDoes it make sense for you?

Yea, that's exactly the question I was asking..
I don't want to do that without knowing if there's a reason they separated the functions in two, a main callback and post callback
That's the only fix to our problem right now, so I'd just move all of the function to the main handler

So right now there are no any blockers for implementing the "consolidation feature", right?

You can call that functions inside issueClosedCallback\nDoes it make sense for you?

Yea, that's exactly the question I was asking..
I don't want to do that without knowing if there's a reason they separated the functions in two, a main callback and post callback
That's the only fix to our problem right now, so I'd just move all of the function to the main handler

So right now there are no any blockers for implementing the "consolidation feature", right?

None, I'm testing it out now

@pavlovcik @rndquu Ready for review, QA is attached
I fixed the header: https://github.com/one-two-test/one/issues/6#issuecomment-1699321223
So currently it should be Task Assignee, and Task Creator Reward

task assignee is same as task creator?

task assignee is same as task creator?

When the assignee is the task creator, it consolidates the earnings into one and use that header

Task Assignee Reward

Not enough fund to claim @pavlovcik


[prometheus-node-exporter] support to use global.imageRegistry and global.nodeSelector for process-exporter and calico-exporter

What this PR does / why we need it
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

[ ] DCO signed
[ ] Chart Version bumped
[ ] Title of the PR starts with chart name (e.g. [prometheus-couchdb-exporter])

cc @wrongerror


fix(start): exit forge with same status code as Electron if nonzero

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project follows, as appropriate.
[X] The changes are appropriately documented (if applicable).
[X] The changes have sufficient test coverage (if applicable).
[X] The testsuite passes successfully on my local machine (if applicable).

I’m working on a project that runs specs when launched with a command-line flag (eg electron-forge start --- --test). I like doing it that way because the tests run in exactly the same env as the app, but electron-forge isn’t returning the exit code from app.exit(1).
This PR alters the start.js API so that if the Electron child process exits with a non-zero status code, forge exits with the same code (similar to lint.js). The existing tests still pass and I've written an additional one for the exit code scenario.

Ok moved the logic over to the CLI instead of the core API - definitely think it makes more sense there.
To test the new behavior, I did have to write a small poller that waits for electron-forge-start.js to call process.exit. This is just because runCommand calls load but has no way to get the promise for the file's execution since it doesn't export anything.  I think that could be changed, but I wanted to keep this small in scope!

@bengotow It looks like the CI scripts are calling the original process.exit still somehow and terminating mid-test sequence.  Can you check that out? 👍

Since this changes the behavior of electron-forge start, I consider this a breaking change.

Yep—will check it out. Thanks @MarshallOfSound
This is a breaking change because it changes the CLI's exit code in some scenarios. I don't believe the current exit-code behavior is documented, not sure whether that impacts the release decision-making process.

It's undocumented but we're going to release 3.0.0 soon anyway. And I'm generally of the opinion that if there's a chance someone's relying on a behavior and it changes, we should be cautious and increment the major version.

Hey! Sorry for the delay—I've updated this PR to fix that issue and the full test suite is passing for me now. I was unspying process.exit before the start script actually completed. Also learned that you can await an expect().to.eventually call, which is cool!
It looks like the AppVeyor / Travis CIs are failing with Error: Failed to install modules: ["electron-prebuilt-compile"] which seems strange and unrelated. Will try to re-run them in a bit.

Ignore that failure, it's an upstream problem that I hope to fix tonight.

Only error on windows is the EBUSY thing, no need to wait for that to pass 😆


OSV API browser

create an OSV (https://osv.dev) api browser that serializes to the types we will use. namely vulnerabilities results.

marked this issue as blocking #3

marked this issue as blocked by #138

marked this issue as related to #19


Corrects module name

My guess is that it was first introduced in https://github.com/dbgrandi/danger-proselint/commit/9cac8d9ead86d082fd769cddef1474c3d44622df When trying to install the gem, this was the error:
There was a NameError while loading danger-prose.gemspec:
uninitialized constant Prose from
  /usr/local/lib/ruby/gems/2.2.0/bundler/gems/danger-proselint-2eedcbe2d8f1/danger-prose.gemspec:8:in `block in <main>'

Yep!


fix(plugins/plugin-client-common): the first time PTY output appears, Kui flashes briefly

Fixes #7437

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[x] 🐛 Bug fix
[ ] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

/lgtm


[SourceKit] Document source.request.demangle

What's in this pull request?

Additional docs for source.request.demangle.
/cc @akyrtzi @benlangmuir @briancroom

By the way, I noticed this isn't the only SourceKit request that doesn't return JSON, instead returning something like the following:
DELIMITER
One item
Another item
DELIMITER

sourcekitd-test -req=cursor also returns information in this format. Is this the intended behavior? Or should these be converted to return JSON, like the other request types documented in tools/SourceKit/docs/Protocol.md?
Related bug number: SR-2117

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Hi @modocache

Ooh, I see! Thanks!! I just tried invoking this via sourcekitd-repl, and got the following:
{
  key.results: [
    {
      key.name: "MyCoolPackage.raichu.getter : MyCoolPackage.Pokemon"
    }
  ]
}

I'll update the documentation to use this format instead. Thanks!

@nkcsgexi Updated -- thanks! Does this look good?

LGTM! merging.


Bioconda installation missing a lot of packages

Hi,
I installed your software (v0.4.1) as described
conda create -n rosella -c bioconda rosella
conda activate rosella

When running this command:
rosella bin -i Bam/Test_metabat.txt -r Test_good.fa --output-directory rosella_out/ --threads 28
I got this error for the module threadpoolctl
[2022-04-27T06:47:39Z ERROR bird_tool_utils::command] Error when running flight process. Exitstatus was : ExitStatus(unix_wait_status(256))
[2022-04-27T06:47:39Z ERROR bird_tool_utils::command] The STDERR was: "04/27/2022 08:47:39 AM INFO: Time - 08:47:39 27-04-2022\n04/27/2022 08:47:39 AM INFO: Command - /work/sber/Software/miniconda3/envs/rosella/bin/flight bin --assembly Test_good.fa --input Bam/Test_metabat.txt --kmer_frequencies rosella_out//rosella_kmer_table.tsv --min_contig_size 1500 --min_bin_size 200000 --n_neighbors 200 --output_directory rosella_out// --cores 28\nTraceback (most recent call last):\n  File \"/work/sber/Software/miniconda3/envs/rosella/bin/flight\", line 10, in <module>\n    sys.exit(main())\n  File \"/work/sber/Software/miniconda3/envs/rosella/lib/python3.10/site-packages/flight/flight.py\", line 449, in main\n    args.func(args)\n  File \"/work/sber/Software/miniconda3/envs/rosella/lib/python3.10/site-packages/flight/flight.py\", line 563, in bin\n    rosella = rosella_engine_constructor(args)\n  File \"/work/sber/Software/miniconda3/envs/rosella/lib/python3.10/site-packages/flight/flight.py\", line 534, in rosella_engine_constructor\n    from flight.rosella.rosella import Rosella\n  File \"/work/sber/Software/miniconda3/envs/rosella/lib/python3.10/site-packages/flight/rosella/rosella.py\", line 33, in <module>\n    import threadpoolctl\nModuleNotFoundError: No module named 'threadpoolctl'\n"
thread 'main' panicked at 'Failed to grab stdout from failed flight process', /home/conda/.cargo/registry/src/github.com-1ecc6299db9ec823/bird_tool_utils-0.3.0/src/command.rs:27:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I got the same error for
numba
matplotlib
seaborn
umap
scikit-bio

I had to re-install
pip install flight-genome
which resolved a lot of the issues by installing missing dependencies but not all, the rest of the packages had to be installed with conda
Best
Greg

Hi Greg,
The conda install for Rosella is relatively okay from my understanding, it's the conda & pip versions of flight that are a bit busted. Due to some difficulties with segfaults with pynndescent we've had to resort to only using the GitHub version of flight. I had forgotten to update the documentation to reflect this.
What you need to do is clone this repo: https://github.com/rhysnewell/flight/tree/master
and use pip install . inside the cloned repo. This will install all of the correct dependencies for you. Once you've done that then it should run as expected.
For the moment, until the pynndescent issues are resolved I recommend just letting Aviary handle the installation of Rosella & flight. You can use them without Aviary, but as you've found the installation can be a tad annoying at the moment. Aviary can be found here if you'd prefer to use it: https://github.com/rhysnewell/aviary
Cheers,
Rhys


Publish to NPM

I noticed you're on NPM but having published recently. This would be incredibly useful for non-jspm users, such as users of: https://github.com/stealjs/system-npm

Pushed latest version to npm.


Pipe command to rerun {command_git_branch} not working

Describe the bug
zellij pipe "zjstatus::rerun::command_git_branch" doesn't appear to work as expected.
To Reproduce

open a new session in a git repo; note branch name is shown
change directories
run zellij pipe "zjstatus::rerun::command_git_branch"
branch name is not updated

Expected behavior
pipe command should rerun the branch command and update the displayed branch name
Desktop (please complete the following information):

OS: macos
Zellij version 0.41.1
Version Release v0.18.1

Layout
How does the layout look like? Please copy it into a code block.
  default_tab_template {
    children
    pane size=1 borderless=true {
      plugin location="file:~/.config/zellij/plugins/zjstatus.wasm" {
        format_left   "{mode} #[fg=#6C7086]{session} {tabs}"
        format_right  "#[fg=#FF00D9]{command_git_branch} #[fg=#6C7086]{datetime} {swap_layout}"

        mode_locked "#[bg=#FF00D9,bold] "
        mode_normal "#[bg=#008EC4,bold] "
        mode_tmux "#[bg=#ff6e27,bold] "
        mode_resize "#[bg=#ff6e27,bold] #[bg=#1D1F21,fg=#ff6e27] {name}"
        mode_default_to_mode "resize"

        tab_normal "#[bg=#8A8A8A,fg=#1D1F21] #[bg=#8A8A8A,fg=#e0e0e0]{name} {sync_indicator}{fullscreen_indicator}{floating_indicator} #[bg=#1D1F21,fg=#8A8A8A]"
        tab_active "#[bg=#008EC4,fg=#1D1F21] #[bg=#008EC4,fg=#35373B]{name} {sync_indicator}{fullscreen_indicator}{floating_indicator} #[bg=#1D1F21,fg=#008EC4]"

        format_space  ""

        border_enabled  "true"
        border_char     "─"
        border_format   "#[fg=#6C7086]{char}"
        border_position "top"

        hide_frame_for_single_pane "false"

        command_git_branch_command     "git rev-parse --abbrev-ref HEAD"
        command_git_branch_format      "#[fg=#FF00D9] {stdout}"
        command_git_branch_interval    "5"
        command_git_branch_rendermode  "dynamic"

        datetime        "#[fg=#6C7086] {format} "
        datetime_format "%A, %d %b %Y %H:%M"
        datetime_timezone "US/Pacific"

        tab_sync_indicator       " "
        tab_fullscreen_indicator "□ "
        tab_floating_indicator   "󰉈 "
      }
    }
  }

Additional context
Add any other context about the problem here.
I'm trying to use add-zsh-hook -Uz chpwd (){ zellij pipe "zjstatus::rerun::command_git_branch"; }  to update the branch name when I change directories, but it seems to not work to rerun the command manually either.
Thanks for investigating!

Hi!
Thank you for the detailed bug report.
Unfortunately, I cannot really do much about this issue. Zellij is executing the plugin commands within the directory, in which the zellij session was started. Thus we cannot change directory for the running command, even on a refresh.
Let me check in the next days, if there's a way to extract the CWD of the currently focused pane. If so, we could add a switch for command widgets to follow the focus with the CWD.

That would be perfect, Thanks!

Update: the CWD will be added to the PaneInfo in the future. Thus I'd like to stall this issue until we got the field to implement it in a clean way.

For reference I’ll link this related discussion that contains some of my thoughts and ideas. (Which I’ll close because it’s a duplicate of this one.)
https://github.com/dj95/zjstatus/discussions/107


renamed collaborator file and added info about requiring tests

We seem to have an influx of collaborators - this is awesome! I'd like to get some docs about mandating tests into the collaborator files so hopefully people will read it and figure out what to do themselves.

removed code of conduct


feat(DropdownMenu): Adds titleElement to DropdownMenu

Summary
Add's titleElement to props of DropdownMenu so users can add custom JSX elements to the title area above the autocomplete.
DNA
Github issue: #839
Allow the title prop to accept a JSX element or a string for the dropdown menu so I can nest buttons or icons inside of it
Checklist

[x] Default Story in Storybook
[x] LivePreview Story in Storybook
[x] Test Story in Storybook
[x] Tests written
[x] Variables from defaultTheme.ts used wherever possible
[x] If updating an existing component, depreciate flag has been used where necessary
[ ] Chromatic build verified by @chanzuckerberg/sds-design

Thank you so much for the great PR, @TheMooseman!
I’d like to discuss this feature with the team in our meeting tomorrow. Could you share the use case you had in mind? Do you need to place an icon next to the title, or are you looking to change the font style? We have a few other components with similar title/subtitle sections, and I’d like to explore whether it makes sense to implement the same approach in those cases.
Again, I really appreciate your continuous contributions and valuable feedback 🎉😍✨

Happy to help out, @masoudmanson!
The use-case for me was to add a button to the right of the title, which I added to the storybook if you wanted a visual explanation. Adding a JSX element argument seemed like the least invasive way to support a button, but I could imagine being able to put icons next to the title would be a nice-to-have as well. If there's a better way to implement button or general JSX support for the title definitely let me know, happy to revise this PR to fit.

Hey @TheMooseman,
After discussing this feature internally, the team was aligned on the idea of offering more flexibility with the title component. However, the design team expressed some concerns about altering the default title styles, as it might impact overall consistency across the system.
We do have a similar pattern recently introduced in some components, like the Dialog component, which supports slots for custom elements. Here’s a screenshot showcasing the available slots on the Dialog:

Would it make sense to keep the current title as is and instead introduce a component slot either beside or above it? Since the title prop isn’t required, you could omit the default SDS title and use the new slot for your custom design. This approach would provide the flexibility you’re aiming for without affecting the default styles.
Please let me know what you think! The next step would be to check with @clarsen-czi and @hthomas-czi for design specs before we finalize the PR for merging.
Once again, thank you so much for your contribution, it really means a lot to us! 😊

@masoudmanson I definitely think a separate prop for it works well, the PR has a new prop titleElement that accepts JSX that gets used instead of title if it's passed in. I think it should be ready for a look from @hthomas-czi and @clarsen-czi, happy to make adjustments if there's something we'd like renamed or done differently!

Hi @TheMooseman,
After discussing with the design team, we’ve decided to go with a component slot to the right of the title element. This approach will help us keep the default title intact and preserve its styles.
I have a quick question about the slot: will it mainly be for buttons, or might you need other types of components there as well? If it’s just for buttons, we could add an optional SDS Button to the right of the title. But if you need more flexibility, we should keep it open for any React nodes.
Let me know what you think!

@masoudmanson That sounds good, I think more flexibility would be best, so keeping it open for any JSX would be my preference. Right now our only use-case is a button but I could imagine wanting toggle buttons, a dropdown, icons, or some other specialty flavor thing like a colored tag. Are there specifics that your team wants to implement or would you like me to update the code so that the title and the new element to the right of the title show up?

@masoudmanson That sounds good, I think more flexibility would be best, so keeping it open for any JSX would be my preference. Right now our only use-case is a button but I could imagine wanting toggle buttons, a dropdown, icons, or some other specialty flavor thing like a colored tag. Are there specifics that your team wants to implement or would you like me to update the code so that the title and the new element to the right of the title show up?

Thanks, that sounds perfect! We don’t have any additional specifics on our end, so it would be great if you could update the code to add a new JSX element to the right of the title. You can name it headerComponentSlot. Here’s a simple design showing how the slot will appear next to the title:

Alright, @masoudmanson I think this should be good to go for review. The new headerComponentSlot is just placed after the title and seems pretty happy at various sizes!

Hey @TheMooseman,
Thanks for the great work on this PR! After reviewing it with our design team, we made a few minor adjustments that I’d like to push directly to your PR if that’s alright with you. Let me know if you’re okay with that, and once I have your go-ahead, I’ll push the changes and we can get this merged and released today. 🫠🙂

@masoudmanson Go for it, glad I was able to help!

09/18 Release
:computer: Coded Library<EMAIL_ADDRESS>:gift: New Features:

Added new headerComponentSlot prop to DropdownMenu component (Demo)

:bug: Bug Fixes

Added sdsStyle to doNotForwardProps on ButtonIcon


Read the Docs: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently

This Bug Report affects these Traffic Control components:

Documentation

Current behavior:

The Read the Docs CI to build the documentation is broken. From https://readthedocs.org/projects/traffic-control-cdn/builds/20564986/ :
 Running Sphinx v4.0.3
loading translations [en]... done

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/registry.py", line 420, in load_extension
    mod = import_module(extname)
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/builders/linkcheck.py", line 28, in <module>
    from requests import Response
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/requests/__init__.py", line 43, in <module>
    import urllib3
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/urllib3/__init__.py", line 39, in <module>
    "urllib3 v2.0 only supports OpenSSL 1.1.1+, currently "
ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2n  7 Dec 2017. See: https://github.com/urllib3/urllib3/issues/2168

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/cmd/build.py", line 279, in build_main
    args.tags, args.verbosity, args.jobs, args.keep_going)
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/application.py", line 239, in __init__
    self.setup_extension(extension)
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/application.py", line 400, in setup_extension
    self.registry.load_extension(self, extname)
  File "/home/docs/checkouts/readthedocs.org/user_builds/traffic-control-cdn/envs/latest/lib/python3.7/site-packages/sphinx/registry.py", line 424, in load_extension
    err) from err
sphinx.errors.ExtensionError: Could not import extension sphinx.builders.linkcheck (exception: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2n  7 Dec 2017. See: https://github.com/urllib3/urllib3/issues/2168)

Extension error:
Could not import extension sphinx.builders.linkcheck (exception: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2n  7 Dec 2017. See: https://github.com/urllib3/urllib3/issues/2168)

Expected behavior:

The Read the Docs CI should pass.
Steps to reproduce:

Go to https://readthedocs.org/projects/traffic-control-cdn/builds/
See the last run was 2023-05-08
See the last successful run was 2023-05-03

They updated the readthedocs image and our docs build successfully again, can no longer reproduce.


[opentelemetry-collector] Update clusterrole and clusterrolebinding naming

Fixes https://github.com/open-telemetry/opentelemetry-helm-charts/issues/585

Updates cluster role and cluster role binding naming logic to always default to fullname, even when a preset is creating the objects.
Updates clusterrole to only attempt rendering rules if there are rules preset.
Allow rendering rules even if clusterRole.create is not true.  This allows adding extra rules to cluster roles created by presets.
Several cluster role and cluster role binding doc updates.

Maybe also changes the comment on top of clusterRole.create as the current one is not true ? (it may be created even if it's false)

@kedare updated the comment


--fragment-retries "infinite" and -R "infinite" do not function properly

Checklist

[x] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2021.04.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar bug reports including closed ones
[x] I've read bugs section in FAQ

Verbose log

I have attached the log separately due to the fact that it is over 4,000 lines long. log.txt
Description

When I attempt to download a video from crunchyroll.com, it will occasionally skip segments without attempting to retry, even with --fragment-retries "infinite" and -R "infinite" enabled. This could be fixed by making the program actually attempt to retry downloading a segment when it fails instead of skipping over it when these arguments are present.

ffmpeg does not support fragment retry.

should I use --hls-prefer-native to be able to download a complete video then?

Just to follow up, using the argument --hls-prefer-native did solve my problem.


Support for Audio (1D Conv) Feature visualization.

I am working on Audio feature visualization by trying to apply already existing tools and research on vision. Lucid seems general enough to be used for Deep Neural Networks in Audio. I haven't read through all the code but I feel like the library could be more of a tool for visualization in the input space for deep neural networks. What do you think?

Hey @BadrYoubiIdrissi sorry for missing this until you closed the issue!
The concepts behind lucid are definitely general enough; we've done some audio experiments ourselves. The place to start would be to look at lucid.optvis.param and add an audio module. lucid.optvis.transform could become a package with a spatial and a audio module.
I'm afraid we won't be using this code for audio soon, but you'd be welcome to contribute and I'd happily review any proposals!


create-docs.sh does not work in bash

The create-docs.sh script identifies itself as a bash script, however, running the script results with the following output:
Generating appledocs...
appledoc version: 2.2.1 (build 1334)

Caught: AppledocException: Path or file '/Users/apwelsh/src/FirebaseUI-iOS/FirebaseUI/**/*.h' doesn't exist!

If, instead I run it using zsh with zsh create-docs.sh then it can identify the source .h files, but it still fails to create the documentation.
Generating appledocs...
appledoc version: 2.2.1 (build 1334)
WARN | FIRGoogleAuthUI.h@44: Description for parameter 'clientID' missing for -[FIRGoogleAuthUI initWithClientID:]!
WARN | FIRGoogleAuthUI.h@44: 1 unknown parameter descriptions (clientId) found for -[FIRGoogleAuthUI initWithClientID:]
WARN | FIRPasswordSignUpViewController.h@33: Description for parameter 'nibNameOrNil' missing for -[FIRPasswordSignUpViewController initWithNibName:bundle:authUI:]!
WARN | FIRPasswordSignUpViewController.h@33: Description for parameter 'nibBundleOrNil' missing for -[FIRPasswordSignUpViewController initWithNibName:bundle:authUI:]!

I have had nothing but failures trying to get the most basic examples and docs generated.  Is the library really that broken, or am I seriously missing something?

I do indeed use zsh, so I guess it doesn't surprise me too much that it works in zsh and not bash.
And yes--unfortunately it's pretty broken from a developer perspective. We incurred a lot of technical debt in the run up to I/O, and we haven't had time to fix things since then (combination of burnout and tremendous uptake/support volume).

Thanks. Since i have no documentation, dont know Objectice-C well enough to reverse engineer the requirements for implementing the library under Swfit, I will use the current API and build my sign-in page manually.  I was hoping to avoid that with this library.
Is there a certain issue I should follow to know when it is all ready for use again?


Implement Paketo RFC 0038: CycloneDX + Syft SBOM

To implement Paketo RFC0038, this buildpack (and the implementation buildpacks inside) will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.
This issue serves as a meta-issue for work required to complete this work for the Go language family. This will require (link Github issues as they are created):
[ ] Updating from label-based BOM to filesystem-based SBOM in CPython

https://github.com/paketo-buildpacks/cpython/issues/288

[ ] Updating from label-based BOM to filesystem-based SBOM in Pipenv

https://github.com/paketo-buildpacks/pipenv/issues/171

[ ] Updating from label-based BOM to filesystem-based SBOM in Pip

https://github.com/paketo-buildpacks/pip/issues/213

[ ] Updating from label-based BOM to filesystem-based SBOM in Miniconda

https://github.com/paketo-buildpacks/miniconda/issues/173

[ ] Adding SBOM support for application dependencies in Pipenv Install

https://github.com/paketo-buildpacks/pipenv-install/issues/83

[ ] Adding SBOM support for application dependencies in Pip Install

https://github.com/paketo-buildpacks/pip-install/issues/86

[ ] Adding SBOM support for application dependencies in Conda Env Update

https://github.com/paketo-buildpacks/conda-env-update/issues/88

We should also evaluate if there any use-cases for generating an SBOM in the Python Start buildpack separate from SBOM generation for dependencies in the Pip Install/Pipenv Install/Conda Env Update buildpacks.
Switching from label-based BOM to filesystem based SBOM will be a breaking change for consumers of this buildpack (and the buildpacks within them) so it might be prudent to consider also doing any additional breaking changes (e.g. dropping support for buildpack.yml) at the same time.

Update: we will wait for first-class support in pack (and hence occam) before implementing this. We will support both the metadata/label format and the filesystem format via packit/v2.
Marking this as blocked until occam testing framework is available.

This is unblocked - the testing framework in occam is available for use.

This is blocked on the upstream issues/PRs. Once they are all merged and the buildpacks are released we can unblock this issue and bump them in this buildpack.

All sub-buildpacks have been release with SBOM support; we are waiting on automation to pick them up and bump them in this buildpack's buildpack.toml. Once that happens this issue will be complete.


feat(coral): Use search param over topic param where possible

What is currently missing?
A number of our API calls use the topic param as the property for filtering data by topic (in Approvals and My requests tables). This topic param only provides results when there is an exact match.
Most of these endpoints also expose the search param, which allows for partial match, which is more desirable in this context
How could this be improved?
Use the search param instead of the topic param wherever possible.
Is this a feature you would work on yourself?

[x] I plan to open a pull request for this feature

🙋♀  I made a note for the api update for searching -> where we using the "search" param, we also have to update our search element. It currently informs user that they are looking for an exact match, which then should be changed.

@programmiri are you referring to what is happening in this commit? https://github.com/aiven/klaw/pull/940/commits/2193d8fff30aa9df8944dabe6abb38dfa934e39b
Or something more?

Nah, that's it! I check and comment github notifications from oldest to newest 😅  so didn't see you already did that update.
🙏  thanks!


Share an exception

Being able to share an exception with somebody outside of my organisation who may not have access to our Exceptionless account - I found a scenario today where a share option would have been awesome!
In an ideal world you'd forward a URL over to the user and have be able to look over the exception in all it's glorious icky detail (maybe even make comments?)

I've been thinking this over and I almost think we'd need to have to tag an event as public via some kind of share functionality.

This could tag the event as public
Create a public url /events/id/public for users to share that is a limited subset of functionality.

@ejsmith : If we don't tag an event, we'd have to figure something out because a user might be able to guess semi sequential event id's.

Merged into https://github.com/exceptionless/Exceptionless/issues/152


Pigpio not found

Which addon?
pigpio
Describe the bug
addon not found
To Reproduce

click INSTALL ON MY
Open link - OK
Opening Supervisot page - addon not found
Reload addons in store - without difference

Expected behavior

Screenshots

System
core-2021.6.6
supervisor-2021.06.6
Home Assistant 2021.6.6
Home Assistant OS 6.1
Docker 20.10.6
frontend: 20210603.0 - latest
Python : 3.8.9
board : rpi4-64
not beta

As the images on the README states: The pigpio add-on is not available for the aarch64 architecture, which the Pi4 has.

Hmm, I maybe you also need to add the repository also before that. But I'm not sure about it

As the images on the README states: The pigpio add-on is not available for the aarch64 architecture, which the Pi4 has.

Hmm, I maybe you also need to add the repository also before that. But I'm not sure about it

OK, how do I add repository ?

@jalicz See the how to here: https://github.com/Poeschl/Hassio-Addons#installation

As the images on the README states: The pigpio add-on is not available for the aarch64 architecture, which the Pi4 has.

So what is the supplement when GPIO is only on the RPI board?

As far as I know the gpio can get input and switch the pins on or off with just HA installed (https://www.home-assistant.io/integrations/rpi_gpio/)
To control PWM values the pigpio needs to be used. 😉
Maybe there is a version to target arm64 devices. If so I will gladly include it.

I'm using my pins input - output On RPI. Now I need to use PWM, according to the https://github.com/soldag/python-pwmled#installation Manual, this is not the HA OS

@jalicz See the how to here: https://github.com/Poeschl/Hassio-Addons#installation

I added repository, but no new items didn't meet me, I tried restart, but no difference.

Then you are right and you will need to install pigpio inside the homeassistant container or use the addon.
I will look if the addon could also be build for the Pi4. For the progress of it see #254

@jalicz See the how to here: https://github.com/Poeschl/Hassio-Addons#installation

I added repository, but no new items didn't meet me, I tried restart, but no difference.

reload browser - OK

instal on RPI4 - OK
PWM light entity added
i'll test the pin output later


Add huggingface_hub.utils.telemetry

Pull Request Template

Adds telemetry for:

[x] CRUD users
[x] CRUD workspaces
[ ] CRUD datasets
[x] login users
[ ] server errors
TBD:
[ ] records
[ ] CRU responses
[ ] CRU suggestions
[ ] CRU metadata
[ ] CRU vectors

Closes #5204
Type of change

Improvement (change adding some improvement to an existing functionality)

How Has This Been Tested

NA
Checklist

I added relevant documentation
I followed the style guidelines of this project
I did a self-review of my code
I made corresponding changes to the documentation
I confirm My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have added relevant notes to the CHANGELOG.md file (See https://keepachangelog.com/)

@dvsrepo added some initial work, still in progress but added you more soo to keep track.

Looks good, just left two small comments!

@frascuchon I am getting some failed tests for test_settings_database_url. Not sure if they are related?

@frascuchon sure, no problem :)

@burtenshaw, Paco felt comfortable with merging this into develop and start testing the incoming metrics from there. Would you be able to five it a final lookover so we can merge after?


Use browser-based Dropbox APIs

The current Dropbox integration doesn't work:
curl http://localhost:3001/dropbox_login
TypeError: object is not a function
   at /home/timothy_gu/LilyBin/server.js:93:49
   at Layer.handle [as handle_request] (/home/timothy_gu/LilyBin/node_modules/express/lib/router/layer.js:82:5)
   at next (/home/timothy_gu/LilyBin/node_modules/express/lib/router/route.js:110:13)
   at Route.dispatch (/home/timothy_gu/LilyBin/node_modules/express/lib/router/route.js:91:3)
   at Layer.handle [as handle_request] (/home/timothy_gu/LilyBin/node_modules/express/lib/router/layer.js:82:5)
   at /home/timothy_gu/LilyBin/node_modules/express/lib/router/index.js:267:22
   at Function.proto.process_params (/home/timothy_gu/LilyBin/node_modules/express/lib/router/index.js:321:12)
   at next (/home/timothy_gu/LilyBin/node_modules/express/lib/router/index.js:261:10)
   at /home/timothy_gu/LilyBin/node_modules/express-session/index.js:433:7
   at /home/timothy_gu/LilyBin/node_modules/connect-mongo/lib/connect-mongo.js:305:11

It might be easier to just use the Dropbox Drop-ins API, which eliminates all the session stuff.

(Line numbers might be off as this is on my WIP branch, but this is also observable with c7e9ee3a32d21da111bcfc99f6f5f93bec3ff219.

Are you running it with valid DBOX_KEY and DBOX_SECRET environment variables? If not, that might be the problem (but it might be broken anyway).
In any case, those in-browser APIs are much preferable. Let's do that.

Are you running it with valid DBOX_KEY and DBOX_SECRET environment variables? If not, that might be the problem (but it might be broken anyway).

Yes.
In my console:
> require('dropbox')
{ DropboxClient: [Function] }

But in server.js:
var DropboxClient = require('dropbox')
[…]
        var dropbox = dropboxClients[req.sessionID] = new DropboxClient({
            consumerKey: consumerKey,
            consumerSecret: consumerSecret,
            sandbox: true
        });

It doesn't look correct anyway.