Update to the sections, "DO NOT use underscores..." and "DO NOT use H…

…ungarian notation"
It is common to use an underscore in private fields. And I as a suffix for interfaces (and to a much lesser extent, T as a suffix for generic parameter names) are often (falsely) cited as examples of Hungarian notation. So I've made a stab at updating these guidelines to clarify those two points.
Summary
Describe your changes here.
Fixes #Issue_Number (if available)

Thank you @DavidArno. We're checking if we can accept PRs to this particular topic since this is copyrighted content.

Given the copyright nature of this content, I'll have to close this. Thaks for trying to improve that though @DavidArno!


fix: handle infinity arithmetic

Fixes https://github.com/NethermindEth/sequencer/issues/24
Merge after https://github.com/lambdaclass/cairo_native/pull/828

Just wanted to comment that when you opened this pr, the implementation had some bugs, they should be fixed now (in case you found weird results)

Pinned to a newer version of cairo native, but not the latest as later revision of main introduce changes to NativeSyscallHandler.
Merge after https://github.com/NethermindEth/sequencer/pull/28


[doc] Documentation issue in 'connectivity/usb/host/api/uhc'

Describe the bug: USB host (STM32H743) not able to communicate with USB device (Pen drive - Mass storage class).
<< Please describe the issue here >>
I am using STM32H7 hal & ll (low level) driver files in Zephyr.

STM32H743 act as USB host & USB based Pen drive is connected to Nucleo-H743ZI2 board.
STM32H7 able to detect the Pen drive.
while starting the Enumeration, I am receiving the STALL error from USB device (Pen drive).

<< You may also want to update the automatically generated issue title above. >>
Environment

Zephyr V3.2.0 with STM32H7 Hal & LL (Low Level) driver files.
Eclipse as IDE.

Thanks for your support.

USB Host is not yet supported on STM32/Zephyr. Closing


[STUDIO-1462] Add the passed-review label automatically

Add the passed-review label automatically
Jira Story
Jira Epic
See Slack discussion:
[https://shuttlerock.slack.com/archives/CGU97S2AX/p1612493732200000|https://shuttlerock.slack.com/archives/CGU97S2AX/p1612493732200000]

Add optional {{senior_reviewers}} to next
Add {{minimum_reviewers}}
At least one senior reviewer required, if any are listed
Potentially add {{auto_merge: true}} flag to next

How to test the PR

How to test feature 1

Do this
Do that
Success

How to test feature 2
How to test feature 3

Deployment Notes
It requires new Environmental variables:

EXAMPLE_ENV_VARIABLE=content
EXAMPLE_ENV_VARIABLE2=content

Tatyana is working on Japan tasks now, so this is on hold until they run out of things to do.


WIP: fixed chunk size

We have a fair amount of complexity (EqualSplit etc) involved in dynamically splitting files down into chunks based on available concurrency.
We could be less clever and use a fixed chunk size, with a fixed buffer size to go with it.  This would dovetail nicely with a sync.Pool of fixed-size buffers, and also with a configuration option to limit the total allocated RAM (implemented as a semaphore guarding how many buffers can be fetched from the sync.Pool).
This commit only does consistent hashing mode; we should do buffer mode as well if we do this work.

side note:
https://github.com/replicate/pget/pull/173/files#diff-ec1a0e746b82d63c33a617e0b8dd205d92ac3cec2213443a6e29af27aaa37f28R139-R145
checks for one var (firstReqResult.err) but uses another var (err) in diag.


Fix deprecation warnings for PHP >8.0

When running the unit tests, the following deprecation warning is emitted:
Deprecated: Return type of Iterator@anonymous::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /__w/php-cypher-dsl/php-cypher-dsl/php-cypher-dsl/tests/Unit/QueryTest.php on line 152

It seems like these issues were caused by an outdated PHPUnit.


Fix typos in Topology model

Fixes #110.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 6 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 74.681%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sdx_datamodel/models/topology.py
3
6
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.05%

Covered Lines:
1028

Relevant Lines:
1245

💛  - Coveralls


--simple --share

Share results aren't displayed in simple mode.

This is resolved in the above referenced commit.  This is only in devel as of now, and will be in the next release.


Docs about how to use it?

Are there any docs about how to use liverepl?
Than you.

The only documentation is the README file which shows how to start liverepl.
Once started, you should be presented with a Clojure REPL prompt where you can enter and execute Clojure code.  Any introductory Clojure tutorial or book should explain.

One of the purposes of liverepl (I guess) is to connect to an existing java application to run custom code without restarting the whole webapp.
; import some custom java class
(import 'a.foo.bar.java.package.SomeJavaClass)

; do something
(def fooclass (new SomeJavaClass))
(.fooMethod fooclass)

; inspect the members of the java class using clojure reflect api
(use 'clojure.reflect 'clojure.pprint)
(pprint (reflect fooclass)) ;

See clojure java interop page
For example, in a Spring based java webapp, it can be used to load custom beans (via the spring context loader) and run arbitrary code at runtime on it. The same can be achieved using JMX, but you would have to annotate the methods to expose and recompile your webapp.


Use ternary operator for one-line condition

Although it's not a big deal, I recommend using ternary operator for one-line conditions.

Personally, I'm not a fan of the ternary operator... seen it abused to the point where I avoid it. I realize I'm probably a strong minority on that, though, so if it passes Rubocop and @pcarranza is happy with it, I'm cool with this.

I'm in the same page as @smellsblue, not a fan of the iif form as it is too dense and forces me to stop and think too much about that one line => it is at least 3 lines condensed in one.
I do not see a reason to merge it. It is just a style change.

Fair enough, I'm closing it since both of you recommend. Thanks for review.


Resizing of parent container not handled

Hi, thanks for the wrapper! I have used it till now nearly without any issues. However, after now I stumbled across a resizing problem.
If I resize the map container it appears that the google tile layer is not resized and grey areas are visible. (see right end)

If I do the resizing with OSM everything works well.

FYI, I am calling the invalidateSize method of the map after the resize event.
setTimeout(function () {
            if (this.map && this.map.leafletElement) {
              console.log("updateMapSize started");
              this.map.leafletElement.invalidateSize(true);
            }
          }.bind(this), 1000);

Also worth pointing out, is that this only happens in the roadmap mode, with the satellite mode it works perfect.

After digging a bit deeper, I found out that on initalization in the onAdd function this._ready is undefined, thats why all listeners are not added.
onAdd: function onAdd(map) {
	    L.GridLayer.prototype.onAdd.call(this, map);
	    this._initMutantContainer();

	    // this._GAPIPromise.then(function () {
	    if (this._ready) { // <========== is undefined
	      this._map = map;

	      this._initMutant();

	      map.on('viewreset', this._reset, this);
	      map.on('move', this._update, this);
	      map.on('zoomend', this._handleZoomAnim, this);
	      map.on('resize', this._resize, this);

	      //20px instead of 1em to avoid a slight overlap with google's attribution
	      map._controlCorners.bottomright.style.marginBottom = '20px';

	      this._reset();
	      this._update();
	    }
	    //}.bind(this));
	  }

@alexus37  do you have any updates from this issue?

Yes it is still present, currently I am doing a little hack to get  a workaround.
componentDidMount() {
    // THIS IS A HACK TO FIX THE RESIZING PROBLEM
    // https://github.com/Charmatzis/react-leaflet-google/issues/19
    setTimeout(function () {
      this.setState({checkedLayer: ROADMAP});
    }.bind(this), 2000);
  }

This is basically first loading the SATELLITE view and than switching to the ROADMAP.


Add tests

Is your feature request related to a problem? Please describe.
Development is going at a rapid rate if we don't add tests soon things are gonna break.

just used TDD while implementing common options between selected elements, let's go


Fix bug in redo command

redo command: Misbehaves when redo is called after the undo command is called and another command is run.
Currently, the redo command misbehaves when information is updated/added (running other commands) after an undo. In this case, redo should not be working as there is nothing to redo.
This update fixes this issue and ensures that redo is not possible once an information update/addition is done not related to the undo command.
Fixes #172

Codecov Report

Merging #221 (747ec4e) into master (8fa355d) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #221      +/-   ##
============================================
+ Coverage     58.85%   58.89%   +0.04%
  Complexity      473      473
============================================
  Files            96       96
  Lines          1976     1978       +2
  Branches        223      223
============================================
+ Hits           1163     1165       +2
  Misses          733      733
  Partials         80       80

Impacted Files
Coverage Δ

...in/java/seedu/address/model/HustleBookHistory.java
65.00% <100.00%> (+3.88%)
:arrow_up:

Continue to review full report at Codecov.

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


New version: OSGeo.GeoServer version 2.24.0

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?
[X] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.6 schema?

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with: >  Executable C:\Program Files\GeoServer\wrapper\GeoServer.exe returned exit code: 1   (Automated response - build 836.)

Exe requires more parameters
PS C:\Users\user> $test = Start-Process -FilePath "C:\Program Files\GeoServer\wrapper\GeoServer.exe" -PassThru
JSL Java Service Launcher by Michael Roeschter<EMAIL_ADDRESS>Version 0.99w January 2020
Command line options:
C:\Program Files\GeoServer\wrapper\GeoServer.exe -install [ini] [...]    to install the service
C:\Program Files\GeoServer\wrapper\GeoServer.exe -configure [ini] [...]  to reconfigure an installed service with new dependencies
C:\Program Files\GeoServer\wrapper\GeoServer.exe -remove [ini] [...]     to remove the service
C:\Program Files\GeoServer\wrapper\GeoServer.exe -debug [ini] [...]      to run as a standalone console app for debugging
C:\Program Files\GeoServer\wrapper\GeoServer.exe -run [ini] [...]        to run as a standalone console app
C:\Program Files\GeoServer\wrapper\GeoServer.exe -runapp [ini] [...]     to run as a standalone console app with no console output
C:\Program Files\GeoServer\wrapper\GeoServer.exe -ini ini                to use the specified init file for running as a service (this option is not useful on command line; only use it if you configure the service option in the registry)
Optional parameters: [...] -console hide | attach | new    'hide' will not show any output on console; 'attach' will show output in current console; 'new' will open a new console window
The configurations file used in the -install and -configure commands will be used for running the service.
Initialization file 'C:\Program Files\GeoServer\wrapper\GeoServer.ini' not found

PS C:\Users\user> $test.ExitCode
1

@wingetbot waivers Add Validation-Executable-Error

It looks good for now - I've been waivering these in the past. The difference now is better log filtering.
Should a Commands or ExpectedReturnCode or similar be added to future manifests?

I don't think ExpectedReturnCode works when its related to the automated Validation? ExpectedReturnCode defines the Installer Return Codes
Return Code 1 most likely means Installer Requires Administrator to run, which means we should not mess with it, but in this case the executable probably works in 0/1 depending on success


Allow dropdown to handle invalid values

A Dropdown will currently fault when the underlying Bindable is updated to a value not present in the dropdown.
Here are two ideas to circumvent this:

Add the "invalid" value as a temporary DropdownMenuItem and delete it once the selection is changed.
This would allow to display the selected value temporarily and allow the user to keep it (which may or may not be desirable depending on the situation)
Restore the "default" value and update the Bindable accordingly.
Could be either a fallback to the first item in the list or an optional delegate to retrieve a valid value from an invalid one (more flexible).
This might result in an infinite feedback loop of Bindable updates if used improperly.

Causes ppy/osu#3474

I like the first idea, not a fan of the revert-to-default option.

I'm fine with the first plan, but rather than saying "invalid" it should probably just go blank. More friendly to the end-user in this case.

Proposal

AddDropdownItem(string text, T value) becomes AddDropdownItem(T value)
Move string converstion to Dropdown itself via:

protected virtual string GetDisplayString(T item)
{
	if (item is MenuItem m)
		return m.Text;
    if (item is Enum e)
		return e.GetDescription();

	return item.ToString()
}```

Override as necessary, but should not need overriding in all existing usages.

Wouldn't that require changing every existing use of Dropdown<T> to Dropdown<DropdownMenuItem<T>>?

I don't think this would be required. Is there a particular scenario you see that being required?

Nevermind, I accidentally skipped the last line when reading your snippet. I'm a bit tired atm, so please excuse if I'm somewhat slow ^^"

Yeah that could work. Simplifies the use of dropdowns in many cases, but still allows you to specify text manually by creating a Dropdown<DropdownMenuItem<T>>.

@peppy
About the AddDropdownItem(T) proposal:
What do you think about keeping both methods, with something like
AddDropdownItem(T item) => AddDropdownItem(GetDisplayString(item), item);

and ditching the if (item is MenuItem m) part?
After thinking a bit I found that Dropdown<MenuItem<T>> isn't exactly elegant, since we'd then be dealing with a Dictionary<T, DropdownMenuItem<MenuItem<T>>> internally and the actual selected values would be MenuItems as well, instead of their contained value.

It might be worth mentioning that in most cases, AddDropdownItem isn't used at all, since the dropdown is populated by setting the Items property. So I'm not sure whether the change is that useful to begin with. Unless of course, your primary goal with GetDisplayString was to just generate the "invalid item" label.

Give it a shot

Another point to keep in mind:
I don't like the idea of the label being directly generated from the value of a DropdownMenuItem.
There will likely be situations where you want multiple entries with the same value, but different labels (like a "default" option at the very top).

i'm not sure why we're keeping "both methods". i don't see the issue with my proposal.

code up what you think is right and we'll discuss.

The issue I have with your proposal --unless I'm completely missing your point-- is that it would make it impossible to manually specify the item text without creating either a new subclass of Dropdown or a class wrapping the actual values, which overrides ToString.
(Could you explain what your goal with the MenuItem logic is? It seems like it is supposed to work around this by allowing you to specify a Text, but imho that would get very ugly fast.)
I think there should remain a way to manually set the label for each dropdown entry, hence keeping the Add(string, T) method.
There should also be an option to set a fixed text for every value not present in the dropdown (like "Current resolution" or "Default"). Only in case this FallbackText is not set (null), the GenerateItemText method should be used to create the label.
To be honest, I personally don't believe the addition of Add(T) is that useful in the first place, as it wouldn't be used anywhere, since nearly all usages of Dropdown set the Items property directly.
Please have a look at 0a5d8b98501f3b2366b3fc55eb6db9e2607f26bb if you're free.

This is completely correct – you would subclass the dropdown or you would give the item a description.

But what exactly is the point in making it more difficult than it is right now? I don't see the benefit.

This is how we design components in the whole game. Subclassing is not to be considered "difficulty" (it's a few extra lines at most) and keeps implementation detail where they should be – local to the UI element.
We want to avoid parents defining behaviour of unique children wherever possible.

I'm sure you're aware that this is a major breaking change to both the framework and the main repository, just to remove functionality.

We want to avoid parents defining behaviour of unique children wherever possible.

It also goes against your own philosophy since it takes liberty away from the user by forcing specific behavior on them instead of allowing them to specify item labels freely.
If you're fine with that I'm happy to implement it, but I'm far from convinced this is the right way forward.

i am confident in this direction, but could @smoogipoo @ekrctb (or anyone else) please weigh in on this decision.
for what it's worth we make breaking changes on a regular basis and have no guarantee of API stability yet. One of my main goals is to make a framework that guides people into good coding practices while ensuring flexibility. The dropdown class was designed in an ugly way from the start, and I see no harm in fixing it.

Chiming in that I agree with the direction proposed by @peppy . So long as you can only add items via plain T values, and let all the text be controlled by base/subclasses of dropdowns.

So... am I supposed to hide the Add(string, T) version and create a new subclass for every place that currently uses it, which does nothing but expose said method as public?
Or should I delete everything and have every subclass implement the entire adding logic from scratch?
Also, how would you handle duplicate values by subclassing? The GenerateItemText method can't distinguish between them.

You may want multiple entries with different labels, that correspond to the same value when selected.


Fix security issue

Coverage remained the same at 91.383% when pulling 4722ff4a3113e3ecf922b6d2837ba8f1c7a65f5f on takahi-i:upgrade-jetty into 4d326cbdbad4a2205048910c6e34f7f64ce805a2 on redpen-cc:master.

Coverage remained the same at 91.383% when pulling 4722ff4a3113e3ecf922b6d2837ba8f1c7a65f5f on takahi-i:upgrade-jetty into 4d326cbdbad4a2205048910c6e34f7f64ce805a2 on redpen-cc:master.


CI failures

The green pipeline is failing https://github.com/rancher-sandbox/cOS-toolkit/runs/6660771110?check_suite_focus=true
And the raw disk test on teal as well: https://github.com/rancher/elemental-toolkit/runs/6671951123?check_suite_focus=true

Raw disk is due to https://github.com/rancher/elemental-toolkit/commit/c1cd19241c14ef7496e5f287866560218c721906
Basically we were using recovery/cos-img for the raw disk, but that package no longer exists, so the raw image is basically an empty image with grub in it, no system.
Also, pretty bad in elemental that if we get an error from the luet installer we don not fail and just continue like its no big thing :D

seems now failures are just on the recovery test https://github.com/rancher/elemental-toolkit/runs/6719627524?check_suite_focus=true . cc @Itxaka didn't we already bumped the recovery image version?

we did, and it worked...

@mjura are you working on this? I see you are already working on https://github.com/rancher/elemental-cli/issues/219

Looks like the problem comes after the upgrade its done (active upgrade from recovery), we expect the os to be booted on the Active partition, but its instead booting on the fallback according to the serial logs:
Booting `cOS 0.8.14-1'

error: ../../grub-core/loader/arm64/efi/linux.c:92:invalid magic number.

error: ../../grub-core/loader/arm64/efi/linux.c:334:you need to load the kernel

first.

Press any key to continue...

   Falling back to `cOS 0.8.14-1'

error: ../../grub-core/loader/arm64/efi/linux.c:92:invalid magic number.

error: ../../grub-core/loader/arm64/efi/linux.c:334:you need to load the kernel

first.

Press any key to continue...

   Falling back to `cOS 0.8.14-1 (fallback)'

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

Also, it may be a good idea to drop that iota thing from the testhelpers and use simple strings. Currently its confusing seeing those weird messages of expected 0 got 3, when we could have expected active got passive :)

and indeed that error seems to point out that the kernel is again not linked?
error: ../../grub-core/loader/arm64/efi/linux.c:334:you need to load the kernel

uh... why the vmlinuz does not appear AGAIN in the package? https://rancher-sandbox.github.io/cos-toolkit-package-browser/cos-toolkit-teal-arm64/system/kernel/0.1.2-8/

Also looks like we were not running the test-recovery before on arm64:

PR: https://github.com/rancher/elemental-toolkit/actions/runs/2410732599
Master: https://github.com/rancher/elemental-toolkit/actions/runs/2427626629

lmao, recovery has nothing in place to set the proper arm64 repo, so its defaulting to the x86 one

new failure https://github.com/rancher/elemental-toolkit/runs/6745496594?check_suite_focus=true , but I think I know what's going on as a similar error happened on c3os as well.. having a look

https://github.com/rancher-sandbox/ele-testhelpers/pull/16

Now ARM image fails https://github.com/rancher/elemental-toolkit/runs/6760955814?check_suite_focus=true after https://github.com/rancher/elemental-toolkit/pull/1481 was merged :sweat_smile:

Also something with cosign is not right yet..? https://github.com/rancher/elemental-toolkit/runs/6762728107?check_suite_focus=true but maybe it needs its own card :/

If I'm reading properly, that run didn't include the changes from the new cosign, so it tried to pick the latest signatures from the old repo, but at that time the latest metadata files had their signatures pushed to the new one. Let's wait for tomorrow rebase to see if it's still happening, because that was properly building on the PR with a manual resign of master artifacts...

https://github.com/rancher/elemental-toolkit/pull/1485 for the arm builder

cosign success which doesn't set the COSIGN_REPOSITORY: https://github.com/rancher/elemental-toolkit/actions/runs/2450303215


Extension was interrupted while PDF sharing on IOS

Steps to reproduce
RNFetchBlob.config({
  fileCache: true,
  path: `${RNFetchBlob.fs.dirs.DocumentDir}/${fileName}.${fileExt}`,
  appendExt: fileExit
}).fatch(method, url, headers).then(res => {
  const path = res.path();
  await Share.open({
    type: 'application/pdf',
    url: Platform.OS === 'android' ? `file://${path}` : path,
  });
})

Then try to share with ICloud drive/Whatsapp
Expected behaviour
File is shared
Actual behaviour
I see Extension was interrupted error on ICloud sharing

and Item cannot be shared on Whatsapp sharing

path on device looks like:

Environment
React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: (4) x64 Intel(R) Core(TM) i5-4288U CPU @ 2.60GHz
Memory: 38.09 MB / 8.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 8.12.0 - ~/.nvm/versions/node/v8.12.0/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.4.1 - ~/.nvm/versions/node/v8.12.0/bin/npm
SDKs:
iOS SDK:
Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
Android SDK:
API Levels: 23, 25, 26, 27, 28
Build Tools: 27.0.3, 28.0.3
System Images: android-27 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.55<IP_ADDRESS>56338
Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.1 => 16.6.1
react-native: 0.57.5 => 0.57.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-share
"react-native-share": "^1.1.3"

isn't this related to our troubleshooting section?

btw working only if file in base64 (except Whatsapp and Gmail, it's described in troubleshooting section).
If I using path - no file in IMessage/Mail/Whatsapp etc.

Closed as non reproducible for clean demo

@indapublic
i'm finding on iOS i'm getting a blank pdf when I share?

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>any ideas?

@export-mike Could you repeat it on clean demo? It would be excellent and helpful


Explain method chaining for step 18 of music player

Describe the Issue
This steps comes up a lot on the forum and I think it is because we have never really explained what method chaining is or showed an example.
Let's update the description to include an example so they know what to do.
We should also explain why the join method is needed here so they better understand what is going on.
updated description
Right now the `songsHTML` is an array. If you tried to display this as is, you would see the songs separated by commas. This is not the desired outcome because you want to display the songs as a list. To fix this, you will need to join the array into a single string by using the <dfn>join()</dfn> method.

The `join()` method is used to concatenate all the elements of an array into a single string. It takes an optional parameter called a `separator` which is used to separate each element of the array. For example:

```js
const exampleArr = ["This", "is", "a", "sentence"];
const sentence = exampleArray.join(" "); // Separator takes a space character
console.log(sentence); // Output: "This is a sentence"
```

Chain the `join()` method to your `map()` method and pass in an empty string for the separator.

To chain multiple methods together, you can call the `join()` method on the result of the `map()` method. For example:

```js
array.map().join();
```

Affected Page
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-basic-string-and-array-methods-by-building-a-music-player/step-18
Your code
see explanation above
Expected behavior
see explanation above
Screenshots
No response
System

Device: [e.g. iPhone 6, Laptop]
OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04]
Browser: [e.g. Chrome, Safari]
Version: [e.g. 22]

Additional context
No response

This has been opened for contribution. The first comprehensive PR created will be reviewed and merged. We typically do not assign issues to anyone other than long-time contributors.
If you would like to contribute and have not read the contributors docs, please do so here: https://contribute.freecodecamp.org/#/
If you have any issues with contributing, be sure to join us on the contributors channel, or on the contributors sub-forum
Files that need to be changed
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/15-javascript-algorithms-and-data-structures-22/learn-basic-string-and-array-methods-by-building-a-music-player/654215fe7b4a899ddceb3b60.md
Happy coding


gabionage, amplicative

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[a,g]

/trunk merge


Use promptTemplate arg correctly.

Fix #1328

Test failure seems unrelated to my changes.

Seems like there's flaky


AVRO-2790:Necessity of using Object as parameter of javaEscape method

Make sure you have checked all steps below.
Jira

[x] My PR addresses the following Avro Jira issues and references them in the PR title. For example, "AVRO-1234: My Avro PR"

https://issues.apache.org/jira/browse/AVRO-2790
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain Javadoc that explain what it does

I like the change, more specific is better :-) Can you rebase onto the latest master? The CI seems to fail for an unobvious reason.


fix: refactor sbom dto objects to better represent data model

This is a first attempt to refactor SBOM DTOs to be more inline with the others.

SbomHead now maps all fields from sboms table
SbomSummary is SbomHead+packages
SbomDetails is SbomSummary+advisories
All DTOs now implement from_entity() pattern

Thanks. Now on the second look, other entities are not actually including summaries into details, but using head and duplicate other fields. Perhaps we should do that here as well. Let's hear from @bobmcwhirter :)

So yep, FooHead should be flattened into FooSummary and FooDetails.
It's dependent on your particular use-case if FooDetails should include FooSummary or not.
In some cases, I do not include FooSummary directly in FooDetails, because the summary is simpler, maybe aggregating/averaging scores for vulns or such, while the FooDetails has all of the data points. Maybe it should have the summary variant, dunno.
Since we have very intertwingly DTOs, having the ability to get "just enough" for the context is useful.
e.g.
As list of Vulns (VulnSummary) where each has enough Advisory information (AdvisorySummary) to find it and drill in deeper.  While also possibly saying how many SBOMs are affected without providing entirely too much information for a list-of-vulns page.
But, nothing is set in stone. Do whatever makes sense in your given context.  We can always shift.

@bobmcwhirter thanks for the context. So you're OK with merging this as is?
I think in the future summary and details can diverge, like for example summary having only count of packages (and advisories?) while details have all. But we can deal with that when needed.


spec: define that structs are compared field-by-field as listed in source code

gc handles struct/array comparisons by short-circuiting if it finds any unequal
fields/elements, and this behavior is noticeable because the Go spec requires
comparisons to panic in some cases; e.g., see http://play.golang.org/p/5jqSUAT1xC

However, unlike short-circuiting for evaluating "a && b", it doesn't
seem that short-circuiting of field/element comparisons is specified by the spec.
Arguably, the spec currently requires that instead both comparisons in the above program
should panic.

Not a major issue, but thought I'd file an issue to note it.  A couple possible ways to
address it:

1. Ignore it since it probably doesn't matter in practice.
2. Specify gc's behavior since it's intuitive and easy to explain.
3. Specify a set of allowable behaviors (e.g., allow short-circuiting or not; and/or
allow any particular ordering for element/field comparisons).
4. Change gc to not (visibly) short-circuit comparisons that involve comparing interface
types; e.g., comparing two [512]int arrays can still short-circuit, but comparing two
struct{a int; b, c interface{}; d int} structs would need to always compare the b and c
fields, and a and d could be compared conditionally.

@griesemer, @ianlancetaylor, I closed #38676 as a duplicate of this one but it'd be nice to get a decision here for https://go-review.googlesource.com/c/go/+/230207 ("cmd/compile: improve generated eq algs for structs containing interfaces").
/cc @josharian @mdempsky @randall77

I'm inclined to say the spec should explicitly say the order of field/element comparison is unspecified, and a struct/array with both unequal and incomparable fields/elements may either compare false or panic.
I'd say go ahead with CL 230207.

I agree with @mdempsky.
If we ever decide to implement more struct order of evaluation, this would be another place where we ought to specify the order.

If we go that route (which I support), and we wanted to prevent people from accidentally relying on short-circuiting behavior, we could generate always-panic implementations in -race mode (or under a new flag).

I'd also agree with @mdempsky.
More generally, a principle I like is to assume that anything that is not explicitly defined by the language spec is in is in fact unspecified even if we don't say so explicitly, and thus should no be relied upon.

Isn't one of the goals of Go is to reduce unspecified cases as few as possible?

We want to reduce dependence on unspecified behavior as much as possible. That is not quite the same as saying something is unspecified in the spec.
(For instance, map iteration order is not specified, and by making it random, people cannot rely upon some implementation-dependent iteration order.)

I would not say that it is a goal of Go to reduce unspecified cases as much as possible.  I don't think we're opposed to reducing unspecified cases, but it's not a goal.
If reducing unspecified cases were a goal we would have exact rules of order of evaluation, exact rules for map iteration, etc.

If we go that route (which I support), and we wanted to prevent people from accidentally relying on short-circuiting behavior, we could generate always-panic implementations in -race mode (or under a new flag).

I started implementing this and it got complicated and ugly, so I stopped. If folks actively want it, I can try again. Otherwise, I'm going to throw in the hat.

@griesemer @ianlancetaylor
I understand there are some good reasons of why map iteration orders and expression evaluation orders in some statements are unspecified. But are there any obstacles and disadvantages to keep the current implementation (by field and element orders)?

But are there any obstacles and disadvantages to keep the current implementation (by field and element orders)?

The immediate one is it would prevent optimization CLs like 230207, which users seem more likely to benefit from than to be harmed by it.
More generally, we reserve the right to make changes in behavior as long as they still conform to the language spec.

OK, get it. But I think, from general user point view, predicable behaviors would be better.

Some users want predictable behavior, some users want faster code.  We have to make our best guess as to which is most important for each specific case.

The spec says that structs are equal if all the fields are equal. It also says
"A comparison of two interface values with identical dynamic types causes a run-time panic if values of that type are not comparable."
This doesn't sound ambiguous to me: it sounds like the panic is required.
We could relax the rules and say the panic may or may not happen depending on other struct field values, but if we did that, different implementations would behave differently. Moving code from one system to another might mean a panic appears where it never did before, making people think the new system has a bug.
The spec doesn't say what order fields are compared, but it implies that they are all compared. If there are two different interface fields that cause panics in a particular comparison, it doesn't matter much which one happens, but one has to happen (not zero).
A compiler that wants to short-circuit field comparisons just has to do all the interfaces before it starts being clever.
Moving into proposal process to make sure discussion terminates.

Changing implementations to match the spec could cause code that has been working correctly for years to start panicking. Though there indeed downsides to laxness in the spec, I think in this case changing the spec to be more flexible—to allow the existing implementations and further optimizations—is preferable.

Just as another data point, it looks like gccgo also implements short-circuiting behavior like cmd/compile.
I'm open to making the user-visible behavior be "all struct/array elements are compared", but I think we should first demonstrate we can actually implement that without negative impact on user programs (both performance and breaking existing programs) before committing to that.
I'm reasonably confident it's doable too, but I think implementing invisible short-circuiting might actually be somewhat subtle.
For example, here:
var x1, x2 [10]struct{ i interface{}; x [100]int }
x1[0].i = true
println(x1 == x2)

we should only need to compare the 10 interface values, but naively implemented I think we'd end up comparing 900 ints as well.

Having just spent a week mucking around in the alg generation code, I can confirm @mdempsky’s suspicion. I would like to make it less difficult—it’d allow us to generate better code in many circumstances—but it’ll involve a large, intricate refactoring.

I think this could work:

Change the signature of the eq alg functions from func(*T, *T) bool to func(*T, *T, bool) bool.

Change all callers from eq(p, q) to eq(p, q, true).

Within cmd/compile, we split ASPECIAL into two cases: ASPECIAL_GENERAL (for comparisons containing interface-typed sub-elements, which cannot be short-circuited) and ASPECIAL_COMMON (without interface-typed sub-elements, which can be safely short-circuited).

The eq algorithm pattern would be:
func T_eq(p, q *T, x bool) bool {
    // Recursively and unconditionally call any `ASPECIAL_GENERAL` functions.
    x = T1_eq(&p.general1, &q.general1, x)
    x = T2_eq(&p.general2, &q.general2, x)

    // Afterwards, fallback to today's comparison logic,
    // except that we first short-circuit on "x", and we explicitly pass
    // "true" to any `ASPECIAL_COMMON` functions.
    return x && p.int1 == q.int1 && T3_eq(&p.common1, &q.common1, true)
}

@mdempsky you also need to handle the interaction with inlined comparisons—and currently that interaction is distant. In alg generation we just insert and OEQ and much later during walk we decide whether or not to turn that into a function call.

Maps, of course, use equality under the hood:

The comparison operators == and != must be fully defined for operands of the key type; thus the key type must not be a function, map, or slice. If the key type is an interface type, these comparison operators must be defined for the dynamic key values; failure will cause a run-time panic.

This statement is very vague about when it will cause a runtime panic.
Currently, we will panic on the first hash of such a key. Currently also, that will be on the first insert, lookup, or delete of that key. But I could imagine other implementations that do other things (e.g. going from 0 to 1 element, we really don't need to hash).
Fortunately, we always panic on the hash of a key that would panic on a comparison. So everything that makes it into the map is good, so any subsequent == calls will never panic.

To confirm, it sounds like both cmd/compile and gccgo both currently walk the fields in source code order doing comparisons and stop early. I don't think I realized that when I commented two weeks ago. I am still concerned about making sure that all implementations agree and not giving any latitude in the spec that could produce portability problems between Go toolchains. It sounds like the conservative thing to do - and possibly the right thing to do - is to say that what cmd/compile and gccgo do today is the standard, and write that into the spec.
Compilers could still optimize as long as you cannot observe the change, meaning a non-interface compare can't be reordered across an interface compare.
What do people think of that resolution?

That sounds ok to me.
I'm not sure we actually need to add it to the spec, though. It's really an esoteric corner case. Is there any place we record decisions about making consistent implementations, that isn't in the spec? Things like

complex NaN / Inf behavior
defer of a nil function
defer of recover

@rsc to be clear, does that resolution entail rolling back CLs 230207 and 230208?
That resolution seems better than changing the implementations to match the spec as written, but I think I am still on the side of more implementation flexibility. I believe bugs in this arena will be rare, the benefits tangible, and the spec simpler.

I think we would have to make 230207 and 230208 a bit more complex.  Instead of p.type == q.type we would have to generate something like p.type == q.type && (isComparable(p.type) ? true : panic("oh noes")).
I think the question is whether we want to grant more implementation flexibility at the cost of having a program that works under one implementation panic under a different one.  Is this a simple difference in order of evaluation, which we normally ignore, or is the difference more significant due to the panic?

I believe bugs in this arena will be rare, the benefits tangible, and the spec simpler.

You are taking the compiler-writer point of view. I am taking the user point of view. I realize those are in tension, but we've been burned almost every time we allow wiggle room in implementations as soon as a new implementation comes along.
I see that @josharian thumbs-up-ed @ianlancetaylor's previous comment.
My comment a week ago was proposing to define that fields are compared in order and that any unequal comparison stops the overall comparison. Does anyone object to this, or do we have consensus?

You are taking the compiler-writer point of view. I am taking the user point of view.

Sorry, Russ, but I find this unfair and a bit patronizing.

I see that @josharian thumbs-up-ed @ianlancetaylor's previous comment.

I thumbed-up Ian's comment because I thought the technical suggestion in it was sound, and the reformulation of the question sensible. Ian's comment did not suggestion a particular resolution to  the question.

Does anyone object to this, or do we have consensus?

We do not have consensus, but I will obviously accept the proposed outcome.

My comment a week ago was proposing to define that fields are compared in order and that any unequal comparison stops the overall comparison. Does anyone object to this, or do we have consensus?

My first preference is still to leave it explicitly unspecified, and allow comparisons of structs/arrays with both non-equal and non-comparable elements to either evaluate false or panic. But my second preference would be to codify the existing (at least up to Go 1.14) practice of implementing in-order comparison with short-circuiting, as you suggest.
I think if we want to start constraining order of evaluation within the spec, there are more fruitful areas for us to start than here. It's been 5+ years since my initial report on the subject, and I'm not aware of any user reports touching on the same. (Granted it probably helps that cmd/compile and gccgo both happen to implement the same non-specified behavior here.)

We should probably revert CLs 230207 and 230208, and re-attempt them (or a modified version of them) if appropriate for 1.16. I am AFK and will be for a few days, and the beta is soon (I hope). Any chance someone would do the reverts for me? Thanks.

On it.

@josharian

You are taking the compiler-writer point of view. I am taking the user point of view.

Sorry, Russ, but I find this unfair and a bit patronizing.

Sorry it came across that way. I was only trying to point out that there are two different sides to this that are always in tension and we were prioritizing the two differently. Apologies.

Acutally, Josh, I don't think CL 230207 needed to be reverted. Only 230208 introduces observable changes in interface comparison behavior.

Thanks, Keith.

Acutally, Josh, I don't think CL 230207 needed to be reverted.

I’m still AFK, but I think they make equivalent changes to algs for
type T struct {
a, b, c, d, e interface{}
}
as to
type T [5]interface{}

I can't get any ordering violations with CL 230207 reapplied.
No hurry, we can reapply if it is safe for 1.16.

OK. Are you using structs with > 4 fields? That might be necessary, since we inline “small” comparisons, and that goes through a different code generation path. (I recently filed an issue to unify them, but can’t find it on my phone.)

(I recently filed an issue to unify them, but can’t find it on my phone.)

cmd/compile: unify and improve struct/array equality comparisons #38674

Just a note that I think that we made a decision here: we compare structs for equality by comparing field by field, and exiting early when two fields are unequal.  But I don't think that decision was ever added to the spec.  (@griesemer)

To nag again, this issue affects array comparison order too, and it remains unconfirmed whether arrays were intentionally dropped from the accepted retitling on June 10, 2020.

It seems to me that the same problems that might occur with unspecified struct field comparison order would apply to array comparisons.

I feel like my comments aren't being heard.
My original issue report from 2014 mentions structs and arrays equally: they were both mentioned in the issue title and the very first sentence of the issue body. Whenever I replied mentioning structs, I wrote "struct/array" (1, 2, 3).
@rsc retitled it in June 2020 to remove the mention of arrays. I explicitly asked that same day if that was intentional, and never got a response.
I asked again 6 days ago after @ianlancetaylor  pinged the issues, and still I'm not getting any acknowledgement.

I agree with @griesemer that this should apply to arrays as well as structs.


Filter by Track is not update when delete torrent

Describe the bug
After delete torrent if we open filter then we show old trackers list that are deleted.
Expected behavior
Update filter information after deleting any torrent
https://user-images.githubusercontent.com/91112485/215066001-b3332fc8-d222-4f56-9bdd-362b280bf077.mp4
Are you working on this issue? (Yes/No)
Yes

is anyone working on this issue? If not, then I would like to pick this up

@cscipher i already submitted pull request on this issue.


Retry option not working from profiles

Summary
Retry option not working from profiles
Expected Behavior

When adding --retry option to a profile, cucumber should use it and retry the given number of times the failing steps.
Current Behavior

Retry option seems to be ignored in profiles.
For instance, if I have a profile like this:

test_profile: --format pretty --retry 2

When running `cucumber -p test_profile`, all steps are executed only once, even if they fail.

Steps to Reproduce (for bugs)

Add --retry option to any profile
Run cucumber with the given profile
See it runs all steps only once, even if they fail

Context & Motivation

It would be useful to include retry into profiles and not have to write --retry on each execution.
Your Environment

Version used: 3.0.0.pre.1
Operating System and version: macOS 10.11.6 "El Capitan"

After banging our heads on the wall for a couple days, I came across this issue to explain why we weren't getting this --retry flag working. We am having the same issues, except we tried it with versions 3.0.0 and I just now also tried with 3.0.1 with no luck.
For convenience, we pretty much exclusively use profiles so this is highly frustrating.

I unfortunately am having the same problem. I can do the retry from the command line but the exact same syntax will not trigger a retry from a profile. Anyone find what the issue is?

I haven't seen an update to the gem beyond 3.0.1 yet. Any ETA for releasing a version that includes this fix?


where to get /usr/local/bin/pairsqc/pairsqc.py

Hi, in the "run-pairsqc-single.sh" script, there's another py file "pairsqc.py". How should I get this one? Thanks!

It seems it is under pairix folder. I installed pairix using Anaconda, and I cannot open "anaconda/myenv/bin/pairix", it looks like this:
anaconda/myenv/bin $ ll -h pairix -rwxrwxr-x 2 root 85K Mar 26  2021 pairix*

cd pairix
-bash: cd: pairix: Not a directory

Hi Jiangshan,
From the pairsqc-single.sh script, you will see pairsqc.py comes from the pairsqc directory, rather than pairix. You can see this file and learn more here: https://github.com/4dn-dcic/pairsqc. I hope this is helpful!

Hello, Clara,
Thanks for your pipeline for hic analysis. Now I basically go through all
the steps and can generate .hic file from the beginning of .fastq file. But
I am not sure if restriction enzyme information was used during this
process. There are two steps that we use restriction enzyme information,
one is "run-addfrag2pairs.sh" and another is "Restriction Enzyme Check"
in 4dndcic/4dn-re-checker/v1.1. Those two steps are most like QC steps.
However, in Hic-Pro pipeline, the restriction enzyme cutting site is used
to removed some reads. So I am not sure if the restriction enzyme
information is taken into steps of 4DN-hic pipeline.
Thanks,
Jiangshan
Clara @.***> 于2023年1月30日周一 12:54写道：

Hi Jiangshan,
From the pairsqc-single.sh script, you will see pairsqc.py comes from the
pairsqc directory, rather than pairix. You can see this file and learn
more here: https://github.com/4dn-dcic/pairsqc. I hope this is helpful!
—
Reply to this email directly, view it on GitHub
https://github.com/4dn-dcic/docker-4dn-hic/issues/79#issuecomment-1409065109,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AR5WZOXM5G4H2TGMDDIGHZTWU756NANCNFSM6AAAAAAUFZ6QRY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi Jiangshan,
I have just replied to your helpdesk request, but in case others look have the same question: yes. Restriction enzymes are used for contact filtering within fragments for in-situ Hi-C, dilution Hi-C, and capture Hi-C experiments. Here is our documentation for reference.

You are correct that both of the steps mentioned do use restriction enzyme information for the purpose of QC. However, in the second half of the pipeline (hi-c-processing-pairs), the pairs2hic step employs Juicer pre, which does perform filtering based on restriction enzymes. It may be helpful to read more (or ask the maintainers) about both Juicer and pairsamtools, which are used throughout the pipeline, if there is a more specific kind of filtering for which you are looking!


Fix table

@mistercrunch please review the fix for #318
The logic is taken from viz.py @ panoramix v0.7.0

looks like i need to rebase with master.


pre-commit: PATH prepending shadows "system" hook binaries

Describe the bug
The pre-commit binary wrapper prepends directories to PATH before calling the hidden python .pre-commit-wrapped wrapper. pre-commit allows to run arbitrary system commands, these PATH manipulations intefere with that: https://pre-commit.com/#system
I believe it's an instance of this more general issue: https://github.com/NixOS/nixpkgs/issues/24128
Steps To Reproduce
A made a small repository which reproduces the issue: https://github.com/iwanb/pre-commit-nix-bug
With pre-commit installed (nix-shell -p pre-commit), ./test.sh calling pre-commit fails because it uses python from the nix store, while ./test-unwrapped.sh works because it uses python from bin/python as expected.
Expected behavior
No directories are prepended to PATH (and ideally not appended either) and the "system" hook behaves like executing commands in the calling terminal.
Maybe it's just a matter of disabling the wrapper, but I'm bit lost as to how this wrapping works.
Notify maintainers

@borisbabic
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.58, NixOS, 22.11 (Raccoon), 22.11.20220730.7b9be38`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.10.3`
 - channels(root): `"nixos, nixos-unstable"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Hi @iwanb
I was able to clone your repo and reproduced your problem.
If you look at "pre-commit"
cat /nix/store/vbjb7f4782pyc64pqg9fx880hq0wj53g-python3.10-pre-commit-2.20.0/bin/pre-commit
you will see that it is including all the runtime dependencies, which are necessary for pre-commit to run. These needs to be preprended to guarantee that the pre-commit uses what the person who packaged pre-commit intended to.
#! /nix/store/2ispfz80kmwrsvwndxkxs56irn86h43p-bash-5.1-p16/bin/bash -e
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/0q1cnb8m8454mj91hjjr42s0jznszy8z-python3.10-virtualenv-20.16.5/bin'':'/':'}
PATH='/nix/store/0q1cnb8m8454mj91hjjr42s0jznszy8z-python3.10-virtualenv-20.16.5/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/6scjy9g9gi1dklh6qyf1pzwpqp3s1j70-python3.10-nodeenv-1.7.0/bin'':'/':'}
PATH='/nix/store/6scjy9g9gi1dklh6qyf1pzwpqp3s1j70-python3.10-nodeenv-1.7.0/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/0102sd2mn3l1byc5p5a84f7f9xrizv95-python3.10-identify-2.5.5/bin'':'/':'}
PATH='/nix/store/0102sd2mn3l1byc5p5a84f7f9xrizv95-python3.10-identify-2.5.5/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/vbjb7f4782pyc64pqg9fx880hq0wj53g-python3.10-pre-commit-2.20.0/bin'':'/':'}
PATH='/nix/store/vbjb7f4782pyc64pqg9fx880hq0wj53g-python3.10-pre-commit-2.20.0/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
PATH=${PATH:+':'$PATH':'}
PATH=${PATH/':''/nix/store/wyhbl43ycqn43d08v5fqj1j6ynf7nz73-python3-3.10.7/bin'':'/':'}
PATH='/nix/store/wyhbl43ycqn43d08v5fqj1j6ynf7nz73-python3-3.10.7/bin'$PATH
PATH=${PATH#':'}
PATH=${PATH%':'}
export PATH
export PYTHONNOUSERSITE='true'
exec -a "$0" "/nix/store/vbjb7f4782pyc64pqg9fx880hq0wj53g-python3.10-pre-commit-2.20.0/bin/.pre-commit-wrapped"  "$@"


Add windows build instruction. Fix #2951

Description of the pull request:
Add Windows instructions to CONTRIBUTING.MD
Fixes the following issues:
#2951
Is breaking:
No
Reviewers:
Yep

So normally, you'll only need to run the build:local ones locally. Curious why you need to run bundle:release for Windows. Here's the breakdown of the scripts.

bundle:test - Bundles only Ractive and the tests. Designed since it makes no sense bundling everything when just testing.
bundle:release - Bundles Ractive and essentials (polyfills, bins, package.json, bower.json, etc.) for publishing.
build:ci:pr - Travis runs this one on PRs.
build:ci:dev - Travis runs this one on dev commits and after merges. It's build:ci:pr with bundle:release in preparation for publishing.
build:local - Similar to build:ci:pr but doesn't run Sauce Labs tests nor report to coveralls. Meant for local build, the one you want to run locally before submitting your PR.
build:local:fast - A trimmed down version of build:local. Skips linting and node tests for fast iterations.

Curious why you need to run bundle:release for Windows.

bundle:release builds a Ractive release on Windows without a dependency on external shells, gitbash and what not. I don't see a reason why shells should be needed to build Ractive. It raises the barrier to entry unnecessarily.

The build:* scripts are just shorthands for multiple operations which are stored in shell scripts.  It doesn't run any sort of testing.

Agreed, we just need to highlight the commands on the contributing.md page because Windows users who want to contribute need to look at shell scripts to figure out which commands to run.
Also, any command that uses lint fails on Windows with:
Expected linebreaks to be 'LF' but found 'CRLF'  linebreak-style
This line in .eslintrc is the cause:
"linebreak-style": [ "error", "unix" ],
Is that line needed?

"linebreak-style": [ "error", "unix" ],

This is to enforce consistent line endings. The expectation now is that your editor uses LF and Git keeps it LF. If you're encountering line ending errors on lint, then you probably either:

Use a text editor that doesn't understand unix line endings (i.e. Notepad).
Git on Windows is usually pre-configured to convert LF -> CRLF on files.

Windows understands unix line endings just fine. It's just that some editors (again, notepad) don't know LF or know but have their newline settings set to CRLF by default because they're on Windows. Git on Windows by default also converts LF to CRLF on checkout and vice versa on check-in, which is only useful if you're using an editor that doesn't understand unix line endings.
The root of the problem is just the editor. It's suggested that you use a better text editor - one that knows LF or one with editorconfig support. We have an editorconfig file in place that enforces LF. Supporting text editors will automatically detect this file and use LF. Also, you can turn Git on Windows' line ending conversion by doing:
git config --global core.autocrlf input

@fskreuz thanks it was git. This command did fix it
git config --global core.autocrlf input
We should also mention that in the contribution.md for Windows users.


[HOT FIX]: resolve value error in startup_technical_ideas llm app

@aybruhm thanks! Can we change the SDK in a way that this is not needed
def chat(messages:MessagesInput)->str:

Sure, sure. I'll do that.


Fix Makefile.PL script to generate resource details in META files.

Hi Nils, please review the above change.
Many Thanks.
Best Regards,
Mohammad S Anwar

Hi Mohammad! Thank you very much for your fix - merged!


The fuels-forc / fuels-core packages don't install the binaries when used via bun

If we use bun to install the SDK, it doesn't install the binaries served via @fuel-ts/fuels-forc and @fuel-ts/fuels-core which are supposed to be installed via the install script.
We are not sure if this is a bug on our end, or an issue with bun. This needs to be investigated.

@Dhaiwat10 this is caused by Bun not running postinstall scripts for packages not in the list of default-enabled trusted dependencies
Adding the package name to "trustedDependencies": ["@fueld-ts/fuels-core"] may do it, when in the root project's package.json


Upgrade to Rails 7.0.4

RailsDevs is currently running <IP_ADDRESS> and Rails 7.0.4 was released about a month ago.
A PR addressing this issue should:

[ ] Upgrade the codebase to Rails 7.0.4
[ ] Review the changelog and ensure nothing breaks

Hi
Can I work on this.

Awesome, thanks @kaushikhande!

Closed via #684.


Java.type(x) === Java.type(x).class violates identity invariant

The following code will evaluate to true in Graal.js:
var javaType = Java.type(name);
javaType === javaType.class;

If you examine the two objects in-depth with, say, Object.getOwnPropertyNames, the results will be different:
var File = Java.type("java.io.File");
Object.getOwnPropertyNames(File).length === Object.getOwnPropertyNames(File.class).length;

This is alarming and breaks JavaScript expectations for identity comparisons.
Furthermore, typeof File.class evaluates to "function" when the design of Java dictates that <type>.class returns an object (i.e., an instance of java.lang.Class).

I agree that javaType === javaType.class should be false. It is a bug in truffle (isIdentical message of HostObject should not return true in this case).

Furthermore, typeof File.class evaluates to "function" when the design of Java dictates that <type>.class returns an object (i.e., an instance of java.lang.Class.

The fact that something is function does not mean that it is not an object (as well). typeof o returns function when o is executable (i.e. you can do o()) or instantiable (i.e. you can do new o()). Considering that you can do new (java.io.File.class)('somePath'), it is expected that typeof java.io.File.class === 'function'.

The fact that something is function does not mean that it is not an object (as well).

That is known, but I'm using the term in the sense that internally, in Java, a java.lang.Class is not callable and a value upon which typeof is called returns "function" when it is callable.

typeof o returns function when o is executable (i.e. you can do o()) or instantiable (i.e. you can do new o()).

But java.lang.Class objects are not themselves executable.

Considering that you can do new (java.io.File.class)('somePath'), it is expected that typeof java.io.File.class === 'function'.

But why is that done when it doesn't work that way in Java and java.lang.Class objects are not executable?

But why is that done when it doesn't work that way in Java and java.lang.Class objects are not executable?

This is JavaScript code (not Java code) and this way there is a nice consistency between Java and JavaScript classes. Compare
> class JavaScriptClass {}
> typeof JavaScriptClass
function
> JavaScriptClass() // cannot be executed
TypeError: Class constructor JavaScriptClass cannot be invoked without 'new'
	at <js> null(Unknown)
	at <js> :program(<shell>:3:1:0-16)
> new JavaScriptClass() // can be instantiated
{}

with
> let JavaClass = java.lang.Object.class;
> typeof JavaClass
function
> JavaClass() // cannot be executed
TypeError: execute on java.lang.Object failed due to: Message not supported.
	at <js> :program(<shell>:8:1:0-10)
> new JavaClass() // can be instantiated
JavaObject[java.lang.Object]

But why is that done when it doesn't work that way in Java and java.lang.Class objects are not executable?

This is JavaScript code (not Java code) and this way there is a nice consistency between Java and JavaScript classes. Compare
> class JavaScriptClass {}
> typeof JavaScriptClass
function
> JavaScriptClass() // cannot be executed
TypeError: Class constructor JavaScriptClass cannot be invoked without 'new'
	at <js> null(Unknown)
	at <js> :program(<shell>:3:1:0-16)
> new JavaScriptClass() // can be instantiated
{}

with
> let JavaClass = java.lang.Object.class;
> typeof JavaClass
function
> JavaClass() // cannot be executed
TypeError: execute on java.lang.Object failed due to: Message not supported.
	at <js> :program(<shell>:8:1:0-10)
> new JavaClass() // can be instantiated
JavaObject[java.lang.Object]

I am perfectly aware that this project is a JavaScript interpreter and not a Java interpreter, . What is your point?
How do your examples a relevant consistency?
Your example actually demonstrates two inconsistencies:
A. java.lang.Class objects are not executable (in the Java sense) yet they are callable in Graal.js.
B. class Example {} is the only function can construct Example objects (Reflect.construct and Object.setPrototypeOf don't count), yet there are two different functions that can construct, e.g., java.io.File objects.

Java type/class identity is fixed by https://github.com/oracle/graal/commit/1e76a6d85d810d851b4d93ea44c538ff37da814e.
Regarding java.lang.Class objects being instantiatable and typeof "function", I don't see a problem with that. In fact, it's convenient that you can pass in java.lang.Class objects and instantiate them with new.


No docs on Plugin API

At http://karma-runner.github.io/1.0/dev/plugins.html there are no docs on the api.
Seems like each should list what is required instead of just listing examples.
From karma-coffee-preprocessor what is:
line 5 what are all the objects passed in as arguments and how are they selected
$inject line 51
'config.coffeePreprocessor' line 51 (how would I know to do that)
... line 51
'preprocessor:coffee' line 55
'factory' line 55 (what options are there?)
Basically need to how the initializer works needs to be defined
Then the function returned needs docs.

Duplicate of #2850. Please discuss plugin API docs there.


Changes to fix multiple problems with k2cli

What this PR does / why we need it:
Several issues with k2cli have come up, including correct error management, correct use of global variables, and some cleanup of technical debt. is required.
I dont think I captured all the things for https://github.com/samsung-cnct/k2cli/issues/112
so any additional work needed can be done in this PR now, or later.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
https://github.com/samsung-cnct/k2cli/issues/107
https://github.com/samsung-cnct/k2cli/issues/138
https://github.com/samsung-cnct/k2cli/issues/112
Release note:

Fixes global flags issues
Fixes error output, panics limited to very deep level issues

blocked for CI

@coffeepac fixed unit tests that causes CI to always fail. CI passes, wohooo!

@coffeepac made the changes you requested and some simplifications. Let me know if its what you expected or not.


Move test helper "ajax helper" to sl-ember-test-helpers repository

https://github.com/softlayer/sl-ember-test-helpers/pull/54 added the ajax helper to sl-ember-test-helpers

The AjaxHelper has been removed from sl-ember-components as of #271.

https://github.com/softlayer/sl-ember-components/pull/271 removed the ajax helper from this repository


[T4A4][T11-B2]Sun Mingyang

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


Running meltano elt with --select and --full-refresh should carry forward state of non-selected streams

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2351
Originally created by @aroder on 2020-09-10 17:24:13

Version: 1.48.0
What is the current bug behavior?
When running meltano elt <tap> <target> --select stream2 --full-refresh --job_id <job>, stream2's state is the only state saved.
After last incremental run, the state is:
{
	"singer_state": {
		"bookmarks": {
			"stream1": {...},
			"stream2": {...}
		},
		"currently_syncing": null
	}
}

Then, after running with --select stream2 --full-refresh, the state is:
{
	"singer_state": {
		"bookmarks": {
			"stream2": {...}
		},
		"currently_syncing": null
	}
}

What is the expected correct behavior?
The previous state for non-selected streams should be included in the new state
Steps to reproduce
meltano elt --job_id <job> --select <stream2> --full-refresh

View 2 previous comments from the original issue on GitLab


Add VPC CloudFormation stack

Add launch-stacks subcommand to rf-stack.py with supporting CloudFormation templates for an Amazon VPC with a VPC endpoint for S3.

Testing
Ensure that default.yml has at least the following contents:
[staging]
Region: 'us-east-1'
StackType: 'Staging'
KeyName: 'rf-stg'
IPAccess: '<IP_ADDRESS>/32'
AvailabilityZones: 'us-east-1a,us-east-1b'
NATInstanceType: 't2.micro'
BastionHostInstanceType: 't2.micro'

Then, run the following command:
$ ./rf_stack.py launch-stacks --aws-profile rf-stg --rf-config-path default.yml --rf-profile staging

Note: This process makes use of the rf-stg API keys, which is different than the API keys associated with rf-dev. You can find the rf-stg keys on the file share.

@azavea-bot rebuild

Reliably fails with the following message if a key for PublicHostedZoneName
is not set.
boto.exception.BotoServerError: BotoServerError: 400 Bad Request
{"Error":{"Code":"ValidationError","Message":"Parameters: [PublicHostedZoneName] must have values","Type":"Sender"},"RequestId":"52ec0a15-775e-11e5-8cd0-3982dc52bf9a"}

I believe that this was addressed in https://github.com/azavea/raster-foundry/commit/3dffa20361e1d725de7595a723e0a7222c5a08d1.

Successfully created a VPC and checked that the proper resources were created. +1


Adding 'Assign' label once the issue is assigned to a person.

Is your feature request related to a problem? Please describe.
Once the Issue is assigned for anyone then Github bot has to add the assign label to the respected Issue.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Screenshots/Proof of Concept

/assign


HTML

HTML
User Story
As a bootcamp student
I want the prework notes to be structured on a webpage
so that I can easily find and read information
##Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Git, and JavaScript with associated notes listed

Acceptance Criteria have been met after following instructions given by BootCamp Spot for Prework Course


Multi-level inheritance validation

ASP.NET Core
Hi! In my system I have a complex multiple-role based authorization on a form with a lot of inputs and for that I have view model inheritance on multiple levels that extends the forms input fields. Anyways.. It looks something like this:
class Class1
{
     public string FirstName { get; set; }
}
class Class2 : Class1
{
    public string JobTitle { get; set; }
}
class Class3 : Class2
{
   public int FeeType { get; set; }
}
class Class4 : Class3
{
    public int Role { get; set; }
}

Now every class needs to inherit all of the validation downwards. This is how I registered my services in startup:
services
                .AddTransient<IValidator<Class2>, Class1Validator>()
                .AddTransient<IValidator<Class3>, Class2Validator>()
                .AddTransient<IValidator<Class4>, Class2Validator>();

Notice Class3 doesn't have it's own validator class but Class4 does.
The viewmodels seems to get the first level of inherited validation but not on the levels beneath. If I register services for all of the inherited classes for example:
   .AddTransient<IValidator<Class3>, Class1Validator>()
It only seems to validate using the last registered one.
I thought about usingAbstractValidator.Include()but since Class3 doesn't even require it's own validator i couldn't. I could make a sample project after the weekend 👍

Hi, that's not really an issue with FluentValidation but I think it's a limitation of how MVC's service registration process works. It'll only allow you to have a type registered once, even if the interface type is different, and the last always takes precedence.

Oh, yeah. Is there any other way this can be implemented?

You'll need to create a validator for each class. To reuse the rules within the validators you can either use an Include statement or you can do validator inheritance with generics.

Ok. Thanks a lot!


ci(.github/workflows/release.yml): using GH_TOKEN as env and secret

Description
Regarding the action, Release ,
replaces GITHUB_TOKEN environment variable w/ GH_TOKEN and updates the value to use the secret of the same name. GITHUB_TOKEN secret is a special secret that can't be set, so if you're writing into a protected branch, you'll need to add a PAT of a user that can write to said protected branches.
Compatibility

OS
Implemented

iOS
N/A

Android
N/A

Windows
N/A

Checklist

[ ] I have tested this on a device/simulator for each compatible OS
[ ] I added the documentation in README.md
[ ] I mentioned this change in CHANGELOG.md
[ ] I updated the typings files (privateTypes.ts, types.ts)
[ ] I added a sample use of the API (example/App.js)

--
it sucks that there isn't a good way to test actions locally

I always forget to add the [skip ci] jazz

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

so if you're writing into a protected branch, you'll need to add a PAT of a user that can write to said protected branches.

Yep, that's my experience

it sucks that there isn't a good way to test actions locally

Yep, that's my experience ;-)
There is actually a project to do local runners and stuff, but it's a total yak shave I think vs the typical tasks + time taken to just bull through it on master, so I just bull through it on master as well. And, it's okay. Not awesome, but okay, and at the end everything works and is then awesome :-)


GKE - Node Integrity monitoring

Bug Description
GKE's Node Integrity monitoring can cause problems for the agent.
Need to validate that this is the case & check if there is a workaround for it (without disabling it preferably)
Steps to Reproduce

Create GKE cluster with Integrity monitoring turned on.
Exec mirrord and check there is no error.

Backtrace
No response
Relevant Logs
No response
Your operating system and version
macOS 13.5 (22G74)
Local process
any
Local process version
No response
Additional Info
No response

Not reproduced on GKE with relevant security features enabled


Mark Katacoda as pending removal

This is a Feature Request

What would you like to be added
For pages that have a button to launch Katacoda tutorials, change that page to:

revise the appearance of the Katacoda button to make the banner really obvious

this could be, for example, an explanatory text with a link to an article, and then a checkbox
when the box is checked, use CSS to reveal the Katacoda launch button.

include a pageinfo-style banner at the top that Katacoda will no longer be available from [specified date]

We can use .HasShortcode to decide whether or not to show the banner
Why is this needed
Katacoda will be shut down.
We should let users know that the removal is due.
Comments
We'll need to agree that date with O'Reilly, who run Katacoda but are discontinuing the public service.
We can also announce the removal work in the blog. Maybe a replacement, too, if we can staff that.

/area web-development
/priority critical-urgent
IMO

/triage accepted

Want to help on this? Feel free to reply with questions - as this is urgent work, SIG Docs should prioritize giving you answers!

/triage accepted

Communication channels we need to reach out to

Blog post
Slack
Mailing List (k-dev) - is there any other?
KubeWeekly (CNCF newsletter – submissions accepted till Thursdays at 12pm CT  - email content to<EMAIL_ADDRESS>LWKD w/ Josh Berkus
Localization teams

To coordinate the efforts on sending out these communications, we should form a team to get started on the messaging, create issues, and track the ongoing work to get this done. The first priority of the team should be to make sure we have a completed list of tasks and an estimation of how much time it will take to complete the work. This can be used to coordinate a reasonable turn off date for Katacoda.
For this effort, our priority is on communicating this change around the upcoming shut down of the the tutorials and cleaning up the tutorial pages. There is a separate and parallel conversation to be had around finding a suitable replacement for Katacoda, see this discussion for more information and to share your thoughts: https://github.com/kubernetes/website/discussions/38878
This affects 25 pages tutorial pages (and their localizations) as well as a whole separate repo: https://github.com/katacoda-scenarios/kubernetes-bootcamp-scenarios. This issue comment has the pages listed: https://github.com/kubernetes/website/issues/33936#issue-1247534383.
cc: @natalisucks @divya-mohan0209 @sftim @reylejano I brought over a summary of our discussion from the community meeting earlier this week. Hopefully its accurate :)

I have less cycles for this than I did for the Dockershim thing. Happy to help a bit though.

A couple of updates:

Taylor (@onlydole) is checking with CNCF folks about the possibility of them hosting the Katacoda content from O'Reilly, given the CNCF is looking for content to share with universities and educational facilities to teach folks about cloud native projects. We'll update this issue with any progress on that front
In parallel, I am in the process of drafting up communication about the Katacoda shutdown, which I will link to here once a draft is ready for review (my aim is this weekend). I'd be happy for folks to volunteer to help turn this communication into smaller snippets for the different distribution options that are listed above. As a note, I am volunteering to run this part of the work
There will need to be another work stream setup for the removal of Katacoda content/links to content (creating issues, tracking work), which we acknowledge would be done after communications about the removal are completed. For folks interested in this work stream, please let us know. We envision running this similar to the Dockershim removal, where a separate Slack channel/Project Board is created to manage the work, so as not to flood main channels and repos

There will need to be another work stream setup for the removal of Katacoda content/links to content (creating issues, tracking work), which we acknowledge would be done after communications about the removal are completed. For folks interested in this work stream, please let us know. We envision running this similar to the Dockershim removal, where a separate Slack channel/Project Board is created to manage the work, so as not to flood main channels and repos

I'd be happy to help with this work

Update: We've gotten in touch with O'Reilly with a proposed shutdown date and have a draft blog post in the works, which can be used as the main source of information for the other communication channels mentioned by @a-mccarthy above. Will link to the draft once a PR has been opened 👍

Draft of @sftim's banner PR for the proposed shutdown is here: https://github.com/kubernetes/website/pull/39257

/triage accepted

/close
Katacoda is removed / gone


Validation messages in the form config are ignored for min/max length

I'm submitting a ...  (check one with "x")
[ x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request

Current behavior
When setting validation.messages.minLength / validation.messages.maxLength, the message is not used
Expected behavior
The same behaviour as for validation.messages.required or validation.messages.pattern
Minimal reproduction of the problem with instructions
https://stackblitz.com/edit/angular-rfcmjm
What is the motivation / use case for changing the behavior?
So we don't some internationalization for this errors as well

Angular version: 7

Thanks a lot for all the effort with the library! :D it's awesome!

try with a lowercase name, since angular return an inconsistent key for these validators: https://stackblitz.com/edit/angular-rfcmjm-jacgfu

thanks for the fast reply! :D


Select audio output device based on display

Description of the new feature / enhancement
Apologies in advance if this has been discussed in the past. I searched for "output device" and "speakers" and didn't find anything that sounded similar.
My idea is to have an app's audio output devices be relative to the monitor it's displaying on. So if an app is on my primary display, it would automatically use the output device defined for that display. If I move the app to my secondary display, the output device would change.
Scenario when this would be used?
I regularly use Teams on my external monitor, but I put meeting participants on my laptop display so that I can look at them and my camera at the same time. For this reason, I have Teams default to using my laptop's speakers. It would be great if a PowerToy could determine the output device for me, as Teams sometimes forgets after I've undocked and redocked my laptop.
This could also be beneficial for videos. Sometimes I'll start a Youtube video on my external display and then move it over to my laptop to keep running while I do something else. I could envision an optional setting to either have the audio change on the fly or wait until the stream is stopped/paused and restarted.
Supporting information
I don't have anything other to add, besides my thanks to everyone who has contributed to PowerToys!

Interesting idea but I don't think we'd build this out.  i think you'll hit a lot of edge cases.

Teams can be on both monitors (share 1 and the actual meeting on the other)
Listening to audio on the background on one monitor and working on the other.

No worries. Thanks for the consideration!

Sad to hear. I was looking for the same feature.
When one window crosses multiple screens, use the the screen where most of the window is located.


🐛 [Bug] Navigating to cockpit and using back, does not correct the main menu

🐛 Bug

Navigating to cockpit and using back, does not correct the main menu. It still shows cockpit on top.
This error might be wise to ignore till we implement the cockpit - the error might go away.
Make sure to investigate if using the browser back-navigation works as expected before closing this issue.

Fixed by #1327 (there is no animation though)


pfe-tabs | Could we remove unique IDs from tab-panel sets and use attributes instead?

On pfe-tabs, if we use IDs to connect the tabs and the panels, Adobe Test & Target will automatically register those IDs and try to use them to apply A/B styles for tests.  Unfortunately, those IDs are not static and so the tests would break because a new ID would show up each time the page is reloaded.  If we can - in general, and here specifically - avoid using randomly generated IDs for this, it will make A/B testers jobs easier.

@markcaron Any reason we need to use IDs specifically?  Is there an accessibility purpose?  If we use data attributes to connect the two, does that detract at all?

Closing this issue now; there is an accessibility reason to use IDs (aria-labelledby).


Doc suggestion: Using debug in WebWorkers / SharedWorkers

Just a quick note that localStorage isn't available in web workers. The dynamic approach described under "Set dynamically" works fine in this environment but it might be worth adding a sentence or two in the "Browser Support" section of the docs to hint people in the right direction.
Thanks for a helpful library!

FYI for others coming here, you can get around this by doing:
// sw.ts
import debug from 'debug'

globalThis.addEventListener('message', event => {
  if (event.data && event.data.type === 'DEBUG_JS_ENABLE') {
    debug.enable(event.data.debugString)
  }
})

// app.ts
    navigator.serviceWorker.ready.then((registration) => {
      const debugString = localStorage.getItem('debug')
      if (debugString) {
        registration.active?.postMessage({
          type: 'DEBUG_JS_ENABLE',
          debugString
        })
      }
    })


some branches are missing if checkout with --depth

https://github.com/uber/cadence/blob/46de15c53172ee521c44fd43dcf2bcd44e308b33/docker/Dockerfile#L67
We need to remove that.  Can it be closed?


Make the commit lint workflow a reusable workflow across all build-trust repositories

We have a workflow that checks commits when a pull request is created, it entails

Checking if users sign their commits
Checking if users commit messages follows a naming convention
Checking if users PR have a linear commit history

The workflow file can be found here in the ockam repository and here in the ockam-website repository, we should create a parent workflow which we can reuse across the two repository, so that we do not repeat code

Hey, I'm participating of Hacktoberfest and I would like to take this issue, can you assign to me, please?

Hi @metaclips, will parent workflow be stored in a new repository?

Hi @metaclips, will parent workflow be stored in a new repository?

It'll be stored in this repository

Ok. I am working on this. Assign it to me.

Nice. Done, please ask if anything

Hi @metaclips, how should I set common jobs from both of repo in parent workflow file?

Hi @metaclips, how should I set common jobs from both of repo in parent workflow file?

We can create a composite action in the ockam repository that we can reuse


Switch setup configuration to to pyproject.toml

In this PR I've migrated the setup configuration from the older setup.py and setup.cfg procedure to a pyproject.toml approach. There is an additional configuration file for flake8 because flake8 doesn't support the pyproject.toml format.

Checklist

[x] Testing comment in the PR documents testing used to verify the changes

Testing
I ran the configure script with this command:
./configure_polaris_envs.py --conda ~/miniforge3/ --env_name polaris-test --verbose --recreate

and it worked as expected. Then, I loaded the environment via the load script and received this error:
Loading conda environment
Done.

Loading Spack environment...

Lmod is automatically replacing "gcc-native/12.3" with "gcc/12.2.0".

The following have been reloaded with a version change:
  1) gcc/12.2.0 => gcc/11.2.0

The following have been reloaded with a version change:
  1) craype/2.7.30 => craype/2.7.20

Lmod has detected the following error:  The following module(s) are unknown:
"libfabric/<IP_ADDRESS>"

Please check the spelling or version number. Also try "module spider ..."
It is also possible your cache file is out-of-date; it may help to try:
  $ module --ignore_cache load "libfabric/<IP_ADDRESS>"

Also make sure that all modulefiles written in TCL start with the string #%Module

Done.

I'm not sure if the error is due to this update, though, because I get the same error when I run the configure script and source the load script on main.

No, unrelated to this and something we'll fix in the 0.5.0 version update.


HDDS-5166. Remove duplicate assignment of OZONE_OPTS for freon and sh

What changes were proposed in this pull request?
The option of "OZONE_OPTS" was assigned twice for Freon and SH, so the error of "duplicate jdwp options" prompts. Need the remove the duplicate assignment of "OZONE_OPTS".
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-5166
Please replace this section with the link to the Apache JIRA)
How was this patch tested?
Manually test. The following command works normal now.
 export OZONE_FREON_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5011
 bin/ozone freon randomkeys --num-of-volumes=1 --num-of-buckets 1 --num-of-keys 10  --replication-type=RATIS --factor=THREE

 export OZONE_SH_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5011
 bin/ozone sh volume ls /

@adoroszlai Thanks for the review.


scripts: add scripts/clippy

What problem does this PR solve?
The official clippy configuration is in a shell script that runs against all targets.
What is changed and how it works?
Add a helper ./scripts/clippy to run clippy against individual targets.
Check List
Tests

Manual test ./scripts/clippy -p PACKAGE

Release note
None

/merge


[MAINT] Require Bleeding Edge of Sphinx Dependencies to Suppress Warning

Fixes related to https://github.com/mne-tools/mne-python/pull/10825.

Please push without skip CI when ready. You can add skip azp and skip actions to have it just run circle

I was waiting for https://github.com/executablebooks/sphinx-design/pull/76 to merge, otherwise I don't think it will fix the warnings...

Okay maybe let's just merge this if it comes back green


How to use N4 bias correction?

My image is in DICOM format and mask in NIFTI format, the dtype are both uint8 or uint16.
I don't know how to operate N4 bias for my MR images. I tried several examples but failed.
There are dtype errors, mismatch errors and so on.
How should I choose the parameters as the examples I see are all used nii format.
Maybe something need to change.
This is one of the code I used but didn't work.
def fun():
    image=input('Enter the name and path of the image : ')
    img=sitk.ReadImage(image)
    data=sitk.GetArrayFromImage(img)
    print type(data)
    img_data=sitk.Cast(img,sitk.sitkFloat32)
    img_mask=sitk.BinaryNot(sitk.BinaryThreshold(img_data, 0, 0))
    corrected_img = sitk.N4BiasFieldCorrection(img, img_mask)
    mask=input('Enter the name of the mask image to be saved : ')
    sitk.WriteImage(img_mask,mask)
    new_img=input('Enter the name of the Bias Field Corrected Image : ')
    sitk.WriteImage(corrected_img,new_img)
    print "Finished N4 Bias Field Correction....."

if __name__=='__main__':
   fun()

Thank you for your questions. If your problem is not resolved you are welcome to reopen the issue.

Im trying to apply this code on multiple image (more than 100) i just put this code on for loop how with different methods, however i got the following errors. It run on one by one images however in loop i got the errors.
Error: 51749 N4BiasFieldCorrectionImageFilter_swigregister = _SimpleITK.N4BiasFieldCorrectionImageFilter_swigregister
RuntimeError: Exception thrown in SimpleITK N4BiasFieldCorrectionImageFilter_Execute: d:\a\1\sitk-build\itk-prefix\include\itk-4.13\itkImageToImageFilter.hxx:241:
itk::ERROR: SubtractImageFilter(000001E58DCBF980): Inputs do not occupy the same physical space!
InputImage Origin: [8.0516953e+01, -1.3090556e+02, 1.4494916e+02], InputImage_1 Origin: [1.9875000e+01, -2.6875000e+01, 3.1875000e+01]
Tolerance: 1.0000000e-06
InputImage Spacing: [1.0000000e+00, 1.0000000e+00, 1.0000000e+00], InputImage_1 Spacing: [2.6875000e+01, 3.1875000e+01, 1.9875000e+01]
Tolerance: 1.0000000e-06.
implementation:
First method:
baseDir=os.path.normpath('C:\Bias_Correction\Data')
files=glob('*.nii')
for f in files:
def N4():
print("N4 bias correction runs.")
inputImage = sitk.ReadImage(f)
maskImage = sitk.ReadImage("06-t1c_mask.nii.gz")
maskImage = sitk.OtsuThreshold(inputImage,0,1,200)
#sitk.WriteImage(maskImage, "p04_mask.nii.gz")
inputImage = sitk.Cast(inputImage,sitk.sitkFloat32)
corrector = sitk.N4BiasFieldCorrectionImageFilter();
output = corrector.Execute(inputImage,maskImage)
#sitk.WriteImage(output,"p04.nii.gz")
sitk.WriteImage(outputs, os.path.join(baseDir, f[:3] + '_BC' + '.' + 'nii.gz'))
print("Finished N4 Bias Field Correction.....")
if name=='main':
N4()
second method:
import SimpleITK as sitk
import os
from glob import glob
import nibabel as nib
import numpy as np
baseDir = os.path.normpath('C:\Bias_Correction\Data2')
files = glob('*.nii.gz')
print(files)
for f in files:
load nii file
print("N4 bias correction runs.")
print(f)
inputImage = sitk.ReadImage(f, sitk.sitkFloat32)
maskImage = sitk.ReadImage("06-t1c_mask.nii.gz")
maskImage = sitk.OtsuThreshold(inputImage, 0, 1, 200)
sitk.WriteImage(maskImage, "P1.nii.gz")
print("maskImage")
#sitk.WriteImage(maskImage, os.path.join(baseDir, f[:3] + 'maskimage' + '.' + 'nii.gz'))
CastImage = sitk.Cast(inputImage, sitk.sitkFloat32)
print("CastImage")
corrector = sitk.N4BiasFieldCorrectionImageFilter()
print("corrector")
outputs = corrector.Execute(CastImage, maskImage)
print("outputs")
sitk.WriteImage(outputs, os.path.join(baseDir, f[:3] + '_BC' + '.' + 'nii.gz'))
sitk.WriteImage(output,"06-t1c_output3.nii.gz")
print("Finished N4 Bias Field Correction.....")
print('_____________________________')

This issue should be address in the lates SimpleITK under development which used ITKv5. You can download the latest python binaries here:
https://github.com/SimpleITK/SimpleITK/releases/tag/latest


Error when trying to update the firmware "The state of the DFU process does not allow this operation"

I get the following error after putting my Puck.js in DFU state (the led being green), and clicking the "Update Firmware (DFU mode)" and pairing with DfuTarg.
Error: The state of the DFU process does not allow this operation

The LED turns blue after pairing.
I originally did this on a chrome browser that had uBlock Origin running, but tried it again on a chrome browser with no plugins, and it had the same effect.
My Puck.js has a label saying Puck.js 2.1a

I've tried it from my android phone and it seems to have successfully updated the firmware