New version: GitTools.GitVersion version 6.0.2

Pull request has been created with komac v2.3.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

Installing it locally works

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-08-12 12:33:34.007 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005
2024-08-12 12:32:47.548 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
(Automated response - build 887.)

@arturcic on my machine a virus was detected:

Here's screenshot from Windows Security:

Ha, that's interesting. We are building the tool in GitHub actions using the standard dotnet publish command.
Interesting that the arm64 version as shown in the screenshot is fine, no viruses detected. Can that be a false positive?

I'd guess a false positive too :shrug:

I will give it a try today on an intel machine and see if I get same thing. But I wonder if it's a false positive, will I have to manually check it for every new release?

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-08-13 11:17:11.415 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005
2024-08-13 11:16:26.706 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
(Automated response - build 887.)

/azp run

@stephengillie  here is the test on a win11 x64:

and a VirusTotal scan
https://www.virustotal.com/gui/url/272fd483e551b0c3e401001d8acff01063840864da37cf1a3c67c60cd9bd196f?nocache=1

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-08-15 16:07:48.917 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005
2024-08-15 16:19:09.485 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
(Automated response - build 887.)

/azp run

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-08-20 08:59:30.941 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
Automated error analysis suggests 80004005 may mean Resource missing
(Automated response - build 887.)

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-08-20 08:59:30.941 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
Automated error analysis suggests 80004005 may mean Resource missing
(Automated response - build 887.)

/azp run

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Packages\GitTools.GitVersion__DefaultSource\gitversion.exe returned exit code: 1
Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Links\gitversion.exe returned exit code: 1
Installation failed with exit code -1978335187
2024-08-22 08:49:30.173 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
Automated error analysis suggests 80004005 may mean Resource missing
(Automated response - build 887.)

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Packages\GitTools.GitVersion__DefaultSource\gitversion.exe returned exit code: 1
Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Links\gitversion.exe returned exit code: 1
Installation failed with exit code -1978335187
2024-08-22 08:49:30.173 [FAIL] Installer failed security check. Url: https://github.com/GitTools/GitVersion/releases/download/6.0.2/gitversion-win-x64-6.0.2.zip Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
Automated error analysis suggests 80004005 may mean Resource missing
(Automated response - build 887.)

@stephengillie is it possible that you can also perform that manual check as you did here?

Manual Validation ended with:

Detected 0 Defender (with signature version 1.417.268.0) errors:

(Automated response - build 888.)

/azp run

@stephengillie @wingetbot The removal of the dependency was on purpose as we removed it from GitVersion.

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Packages\GitTools.GitVersion__DefaultSource\gitversion.exe returned exit code: 1
Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Links\gitversion.exe returned exit code: 1
Executable C:\Users\VALIDA~1\AppData\Local\Temp\B3CD9143-1C28-46D3-9031-464AE326DEDB\DismHost.exe returned exit code: -2147024809

(Automated response - build 888.)

@ stephengillie @wingetbot The removal of the dependency was on purpose as we removed it from GitVersion.

@ stephengillie

Hi @arturcic,
Thanks for the confirmation. I usually ignore the label https://github.com/microsoft/winget-pkgs/labels/Manifest-Metadata-Consistency - either the metadata change is immaterial, or there's a good reason for it. I was waiting for the pipeline to complete, and got distracted approving 450+ PRs.

@ stephengillie @wingetbot The removal of the dependency was on purpose as we removed it from GitVersion.

@ stephengillie

Hi @arturcic,
Thanks for the confirmation. I usually ignore the label  Manifest-Metadata-Consistency - either the metadata change is immaterial, or there's a good reason for it. I was waiting for the pipeline to complete, and got distracted approving 450+ PRs.

I can understand that, no worries


Limit board sizes

See title.

Cool. I wasn't sure if || was a binary operator, so I played safe.


[crypto] Add tests for checks on RSA prime generation.

Adds OTBNsim tests that check various candidate primes that violate different preconditions on p and q, as well as candidates that satisfy all conditions, and checks that the implementation accepts/rejects these correctly.
No constant-time tests here because the check_p and check_q functions are expected to discard composites early; they're not supposed to be constant-time.

Everything is passing except Kokoro, but this PR doesn't touch RTL and Kokoro is failing on other PRs as well at the moment, so I'll consider it safe to merge.


Geometry intersection with invalid geometry does not hard error and returns a null

We need to clip large polygons with a bounding box of an area of interest. We were using Gdal bindings from the old lib and it worked fine. Occasionally geometry issues (self touching) are leading to soft errors where data is missing and gdal-next is not throwing an error.
We can use isValid to check before running an intersection, however throwing an error would be preferable.
Old Gdal bindings can return a legit intersection on two geometries even with geometry invalid (self touching polygon).
Gdal-next returns a Null rather than throwing an error. It would be preferable that an error would be thrown. However, is there a reason why gdal-next is being more fussy on geometry validation? Or is that a change to the underlying C lib?
Have created a quick Gist as an example.
https://gist.github.com/markgis/2218363320779f8239d3cb9459650aa6

Gdal returning intersection of both geometries.

Self touching geometry issue causing Null return in gdal-next
@tickticktrack

There weren't any changes in the binding code related to validation or intersections so I would assume this is just a change in the underlying gdal behavior - it may be possible to return the old behavior but I'll have to check the gdal changelog and see what changed here + add some tests.

As a test, you can try installing gdal-next in shared mode + make sure you have an older version of gdal (maybe 2.x? an early 3.x?) on your local. If you get the same results then the issue is in our binding code - if you get the expected results on the older version, then the issue is with a change in gdal.
Let me know what you find out since that can save me quite a bit of time debugging.

@contra Sorry about the late reply,  I am guessing you mean install from gdal source? as in;
To link against shared libgdal, install using:

# requires libgdal-dev (debian: sudo apt-get install libgdal-dev)
$ npm install gdal --build-from-source --shared_gdal

@markgis Yeah - with that you're building it from scratch and telling it to link against a version of GDAL on your system, not the one included in the repo. If your issue is fixed by this it means the breakage is with the version in our repo vs. an older version that your system has and gives us a good place to start looking. Let me know what the result is + which version of GDAL you linked against.

@markgis, there have been very significant changes in GDAL 3 when it comes to geometry operations (they added 3D support based on SFCGAL) and the libgeom (which provides the intersection algorithm) support has been reworked.
As far as I am concerned, the correct response is the one provided by GDAL 3. The old one was, in fact, a bug.
As the GDAL documentation states, you have to call geom.isValid() before calling geom.intersection(), otherwise the result is undefined.
If you call geom.isValid() on your gdalGeom / nextGeom it will return false with gdal.lastError set to 'Ring Self-intersection at or near point<PHONE_NUMBER>25'
As for modifying the API, even if I have to admit that what you are proposing makes sense and it is more in line with the JS design principles than the current solution, I am afraid that this will be a decision where disadvantages far out weight the benefits. For an incompatible API change to happen, the old API must really be broken beyond repair.
What I suggest is that you simple do the following in your code:
const gdalGeomIntersection = gdal.Geometry.prototype;
gdal.Geometry.prototype = function(geom) {
  if (!this.isValid() || !geom.isValid())
   throw new Error('invalid geom');
  return gdalGeomIntersection.call(this, geom);
}

If you want to support different GDAL versions, you can check the value of gdal.version - there is code in the async unit tests that does it

Hey @mmomtchev, thanks for the details. We had already implemented a isValid but thought it was worth bringing up the difference in behaviour. Many thanks for checking that out.

I think this is something worth noting in the docs (Behavior differences between GDAL 2 vs. GDAL 3) since this library supports both.


Failed to resolve entry for package "vite-plugin-pwa".

Failed to resolve entry for package "vite-plugin-pwa". The package may have incorrect main/module/exports specified in its package.json. [plugin externalize-deps]
../../node_modules/.pnpm/esbuild@0.18.20/node_modules/esbuild/lib/main.js:1373:27:
  1373 │         let result = await callback({
       ╵                            ^

how are you using the pwa plugin?

how are you using the pwa plugin?

cd vite-plugin-pwa/examples/vue-router
pnpm i
pnpm run dev
just like other rep

You need to run pnpm install  from root folder

fixed.

in repo root folder: pnpm i && pnpm build
use example/react-router as an example: pnpm -C examples/react-router/ run dev


Add option to limit the number of selected images

Add an optional option (which when provided) gives the developer the option to limit the maximum number of images the user can select.
When a user will try to select a number greater than the maximum defined number, he will be shown a toast saying that the limit had been reached.
When a maximum parameter is defined, the number under the title will show the amount of selected images out of the maximum number defined.

Same is planned for next release. I have now total 4 points to be done in next release.

Pushed a pull request with this new feature


Could you tell me the concrete version of python,tensorflow and cuda?

Could you tell me the concrete version of python,tensorflow and cuda? Thanks a lot!

Could you tell me the concrete version of python,tensorflow and cuda? Thanks a lot!

Cuda 10.0, python 2.7.18, tensorflow-gpu 1.14.0 works for me.


The code is wrong.....

There are some issues with the code, including fatal errors, making it difficult to complete the experiment well.....

I also get usage of deprecated packages, in the train.py there are errors with unpacking and I agree that is complicated to make it work fine following only the tutorial itself.


atelectasis placement

atelectasis MP:0001177 is currently placed under abnormal respiratory system physiology MP:0002133
Consider placing MP:0001177 under abnormal respiratory system morphology MP:0002132 (see HPO placement of Atelectasis HP:0100750)
Also, review its EQ which currently uses:
has part some (collapsed and (characteristic of part of some lung) and (has modifier some abnormal))

EQ is ok to use characteristic of part of  in this case

atelectasis MP:0001177 is now placed under abnormal respiratory system morphology MP:0002132.


Problem with pre-training

Hi there, thanks for your great work, I'm currently running into a problem while running train_transformer.py. After downloading the pretrained ct-vit model checkpoint and feeding it to the parameter pretrained_cvivit_path on https://github.com/ibrahimethemhamamci/GenerateCT/blob/main/train_transformer.py#L58, I get RuntimeError: Error(s) in loading state_dict for CTViT: Missing key(s) in state_dict: "vq._codebook.embed_avg". on https://github.com/ibrahimethemhamamci/GenerateCT/blob/main/transformer_maskgit/transformer_maskgit/ctvit.py#L406. I presume there is a problem about the checkpoint file ctvit_pretrained.pt ? Let me know if you have some idea about this error. Thanks in advance!

It might be caused by vector_quantize_pytorch version mismatch. Can you try running pip install vector-quantize-pytorch==1.1.2 in your current env? This version should be installed  in your env if you run pip install -e for transformer_maskgit though.

I am closing this for now. Let us know if you have further question.


(PUP-6966) Allow file fifo and socket ensure absent

Prior to this commit:

The remove_existing method didn't check the self[:backup] attribute before calling can_backup and backup_existing.
The remove_existing method reported that it could not remove a file instead of reporting that it could not backup a file.
The can_backup method returned true for all file types.

This caused File (and Tidy, which uses File) to fail to remove fifo and socket files and report a misleading error.
This commit allows File (and Tidy) to remove fifo and socket files.

CLA signed by all contributors.

Thank you @tkishel. It looks like there are valid test failures, can you have a look.

Accidentally merged to master, I reverted in c2df18b50d4f80600caec89d8644fa7419182d03. @tkishel to open a new PR


Improve ockam relay show <RELAY_ROUTE> --output json by generating JSON output

Current behavior
After a user has enrolled and created a relay using the following commands
ockam enroll
ockam tcp-outlet create --to 6000
ockam relay create

And they run ockam relay show <RELAY_ROUTE> --output json where <RELAY_ROUTE> is something like forward_to_default, then plain text output is generated and not JSON. You can see this in the screenshot below.

Desired behavior
Instead of plain text output, JSON output should be generated for this command and argument combination.
Implementation details
Please take a look at this file to get started.

Some tips for newcomers:

Create a new branch for the issue you are working on (don't push directly to your fork's develop branch)
In the PR description, include the issue that's being solved
Run cargo fmt. You can configure the editor to run it automatically every time a file is saved
Run cargo clippy to make sure the code compiles + follows rust standards/best practices
You don't need to keep your branch updated with develop until there is a merge conflict. If you still want to update it, use git rebase develop instead of git merge develop

We love helping new contributors! ❤
If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

If there is no one working on this issue, please assign it to me. I would love to work on it.

@0x61nas awesome! Thank you, all yours.
Please let us know if your have any questions as you explore. You can also ask questions on the contributors discord https://discord.gg/RAbjRr3kds


Added HttpResponseEntity::json()

Coverage increased (+0.008%) to 97.708% when pulling 6bdfcb6d241f13e7a3d66a058e879e740bf5cdc2 on feature/httpresponseentity-json into a34b7b0ea54d98b1f2ed31716e6a3a9646714d3c on master.


v-html directives has some bug

Version
2.6.11
Reproduction link
https://codesandbox.io/embed/unruffled-sea-tuvm3?fontsize=14&hidenavigation=1&theme=dark
Steps to reproduce

What is expected?
https://mps.hikvision.com/specialPriceApproval/specialPriceCreate?id=1212&spaNo=asdfasf&isThirdPart=0&page=04&currentActiveTabName=waitForApproval&recordSource=1
What is actually happening?
https://mps.hikvision.com/specialPriceApproval/specialPriceCreate?id=1212&spaNo=asdfasf&isThirdPart=0&page=04¤tActiveTabName=waitForApproval&recordSource=1

This is not a valid reproduction. Please read the rationale here.

this is how html works
https://codepen.io/jkarczm/pen/WNpNgRK?editors=1000


[SR-1589] Add non-throwing testCase() wrapper function.

This is useful in clients which would like to use Swift type inference to
define the allTests array. If none of the tests in the class throw, Swift
will infer the type of that array as (String, (T) -> () -> ()) which is not
convertible to the type expected by the testCase method.

Resolves: https://bugs.swift.org/browse/SR-1589

Thanks for the PR @ddunbar! This is a nice improvement. I left one minor comment on the code.
A little testing seems to indicate that the alternative allTests form can be used in all cases, including when mixing throwing and non-throwing tests. So I wonder if we should actually update our tests and change the recommended form to use this now?
class FooTests: XCTestCase {
  func testFoo() {}
  // Notice use of type inference to avoid boilerplate.
  static var allTests = {
    ("testFoo", testFoo)
  }()
}

@swift-ci please test

Yes, the alternative form will work in all cases now, because either of the types Swift infers will work. I think it would be a good idea to update to this as the standard recommendation as it reduces some of the redundant boilerplate that currently needs to be copied and then modified (to change the test case name).
I can follow up on that.

@swift-ci please test

The Linux test failure is caused by the ongoing issues with Foundation's test suite. I tested it locally and it looks good to go.
@ddunbar If you don't have time, I have no problem updating the other tests and docs here myself. Thanks for bringing this up!


Keycloak clustering

Hi,
Thanks for the great job you did with this project (and its documentation).
I try to achieve manually (without the cloud formation) the steps you described. Everything works fine if I run only one fargate task.
As soon as I add a second task, the keycloak admin console doesn't work anymore.
My guess: It's because the clustering is not done between the 2 tasks.
[0m[0m20:04:36,334 INFO  [org.infinispan.CLUSTER] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel ejb: [ip-10-0-1-57|0] (1) [ip-10-0-1-57]

I see those logs on both tasks.. => I get 2 clusters of one node instead of 1 cluster of 2 nodes.
I the documentation you provide, I didn't noticed anything special about keycloak clustering.
I tried multiple options from the "Clustering" section of the keycloak docker image documentation without success.
Is there something I'm missing?
Thanks again

There're two things you need to pay attention,

You need to enable ALB sticky session which will route traffic to the same instance. This is a preferred way from the official doc https://www.keycloak.org/docs/latest/server_installation/#sticky-sessions
(Optional) Add JGROUPS_DISCOVERY_PROTOCOL=JDBC_PING in your container runtime env. This is a kind of service discovery mode for jgroups which's using your database as a central info store. Check https://www.keycloak.org/2019/08/keycloak-jdbc-ping for some details.

Thanks for the reponse.
I aready found the JDBC_PING solution. It works well. The sticky sessions is also an important thing.
For the record, here is the environment variable I added to achieve the JDBC_PING configuration:

JGROUPS_DISCOVERY_PROTOCOL= JDBC_PING
JGROUPS_DISCOVERY_PROPERTIES=datasource_jndi_name=java:jboss/datasources/KeycloakDS,initialize_sql="create table if not exists jgroupsping ( own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data BYTEA DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name))"

The properties are needed to reference the datasource to use...and to enable the table creation (for a postgres database) By default, the table is not created. So you can provide the creation script.
Reference:

http://www.fafonso.com/jgroups/unicast/postgresql/jdbc/ping/cluster/2016/08/07/jgroups-with-postgresql.html
https://developer.jboss.org/docs/DOC-16351

Maybe you could add a section in your documentation to explain this part.
Thanks again!

@stephane-dereppe I found the reason why you need to set initialize_sql  in JGROUPS_DISCOVERY_PROPERTIES .
From the source code: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/JDBC_PING.java#L55-L60
    protected String initialize_sql =
        "CREATE TABLE JGROUPSPING (" +
        "own_addr varchar(200) NOT NULL, " +
        "cluster_name varchar(200) NOT NULL, " +
        "ping_data varbinary(5000) DEFAULT NULL, " +
        "PRIMARY KEY (own_addr, cluster_name) )";

The ping_data varbinary(5000) data type is not supported in postgres db. therefore, you need to create that table in another way.

Yep.
Make sense.
Thanks for the information
Le dim. 23 mai 2021 à 05:53, wchaws @.***> a écrit :

@stephane-dereppe https://github.com/stephane-dereppe I found the
reason why you need to set initialize_sql in JGROUPS_DISCOVERY_PROPERTIES
.
From the source code:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/JDBC_PING.java#L55-L60
protected String initialize_sql =
    "CREATE TABLE JGROUPSPING (" +
    "own_addr varchar(200) NOT NULL, " +
    "cluster_name varchar(200) NOT NULL, " +
    "ping_data varbinary(5000) DEFAULT NULL, " +
    "PRIMARY KEY (own_addr, cluster_name) )";

The ping_data varbinary(5000) data type is not supported in postgres db.
therefore, you need to create that table in another way.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-samples/keycloak-on-aws/issues/95#issuecomment-846497335,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2VHLSWS3TQHOSSDHF7CHTTPB35LANCNFSM44WZOMTQ
.


Define the DEBUG symbol on Release

Fixes https://github.com/aspnet/Logging/issues/216
@kichalla @Eilon

Updated

:shipit:

Yup, this is the evil trick! :shipit:


CTC repeat char

Fix #2292
I added the case of  l's = b or l'{s-2} = l'_s. in creation of recurrence relation.

Is this bug fix? or enhancement?

Thanks for comments. I applied them. Please review again.

Is this bug fix? or enhancement?

This is bug fix. As it is mentioned in #2352, this case is considered in the original paper.

OK.
LGTM!


Current app crashes

The Issue

I got this to happen once after publishing to a channel and then searching for that channel. Might be related to navigation/search.

Desktop Error: /Applications/LBRY.app/Contents/Resources/app.asar/index.html

   TypeError: Cannot read property 'toLowerCase' of undefined
   at t.forEach.e (file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:52236)
   at Array.forEach (<anonymous>)
   at a.createSelector (file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:51991)
   at file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:114815
   at file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:114245
   at file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:114945
   at file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:114245
   at Function.t.a.Object [as mapToProps] (file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:200:217284)
   at r (file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:60017)
   at Function.r.mapToProps (file:///Applications/LBRY.app/Contents/Resources/app.asar/ui.js:1:60153)

Happens on a claim like detailsJson that was manually crafted without a title.

Desktop Error: /C:/Program%20Files/LBRY/resources/app.asar/index.html

   TypeError: Cannot read property 'replace' of undefined
   at a.createSelector (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:22811)
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114815
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114945
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at Function.t.a.Object [as mapToProps] (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:200:303370)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)
   at Function.r.mapToProps (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60153)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:61353
User(824249) Desktop Error: /C:/Program%20Files/LBRY/resources/app.asar/index.html

   TypeError: Cannot read property 'replace' of undefined
   at a.createSelector (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:22811)
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114815
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114945
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at Function.t.a.Object [as mapToProps] (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:200:303370)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)
   at Function.r.mapToProps (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60153)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:61353

Possibly happens after accessing a channel right after an update (via SDK)

User(915443) Desktop Error: /C:/Program%20Files/LBRY/resources/app.asar/index.html

   TypeError: Cannot destructure property `name` of 'undefined' or 'null'.
   at t.sortFunctions.(anonymous function).forEach.e (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:200:129430)
   at Array.forEach (<anonymous>)
   at c.render (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:200:129358)
   at Po (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:63001)
   at To (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:62796)
   at Io (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:66630)
   at qi (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:90674)
   at $i (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:91058)
   at Pl (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:97945)
   at Sl (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:269:97325)

not sure about this one, user was on 0.32.1

Desktop Error: /C:/Program%20Files/LBRY/resources/app.asar/index.html

   Error: URI does not include name.
   at je (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:17199)
   at Ze.a.createSelector (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:21540)
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114815
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114945
   at file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:114245
   at Function.Object [as mapToProps] (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:200:280567)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)
   at Function.r.mapToProps (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60153)
   at r (file:///C:/Program%20Files/LBRY/resources/app.asar/ui.js:1:60017)

System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

I don't think these are workable without the URLs or steps to recreate the issues.


chore: fix typos in un-/subscribing attnets logs

Motivation
Just some typos I picked up when looking into https://github.com/ChainSafe/lodestar/issues/6319, and since those are info logs, I feel like it's worth updating them.
Description
Fix typos in un-/subscribing attnets logs

:tada: This PR is included in v1.16.0 :tada:


await consumer.stop() hangs indefinitely in v1.14.0

The consumer.stop() promise is resolved within a function when you emit the the 'consuming-close' event from the runner.js:
https://github.com/tulios/kafkajs/blob/02bc8a3c19504d182df131914ee9af4661bf060c/src/consumer/runner.js#L172
This means that the resolve() is only executed if the client is listening out for the close event.  I had to change my code to the following to avoid stop() hanging:
 this.consumer.stop();  this.consumer.on(this.consumer.events.STOP, ()=> doSomething);
Thanks

hey @hughlivingstone not sure I follow your logic, CONSUMING_STOP is always emitted on scheduleFetch, what's happens now is that the consumer is waiting for all requests to finish before it stops, so I would double-check if your eachMessage or eachBatch handler are not blocking the shutdown.

I was stopping the consumer with an await within the eachMessage function after a message is processed. I see that this won't work now with the new implementation.
I guess the workaround I put in works as the event listener will get called after the eachMessage has finished.

I have found something similar with my producer not retrying a connection when it hits an onError.  The scenario here is that i am trying to connect a producer but the kafka server does a ECONRESET on the TCP connection.
      const kafka = new Kafka({
      clientId: `wait-until-ready-${uuid()}`,
      brokers: [`${KAFKA_HOST}:${KAFKA_PORT}`],
      connectionTimeout: READY_WAIT_TIMEOUT,
      logLevel: logLevel.DEBUG
      });
      const producer = kafka.producer();
      await producer.connect();

This causes the await producer.connect() to hang indefinitely.  I tracked the hang to the following place in kafakjs.
https://github.com/tulios/kafkajs/blob/7ac93f55dadff2ba8063d4f2fa235a70e04594dc/src/network/requestQueue/index.js#L222-L237
Like in the consumer.stop()The promise resolve is wrapped inside a function within the emitter.  Therefore unless i have a listener on that event it does not get triggered.  I changed the code to resolve like the following and the producer kept trying to reconnect as expected.
  waitForPendingRequests() {
    return new Promise(resolve => {
      if (this.pending.length === 0 && this.inflight.size === 0) {
        return resolve()
      }

      this.logger.debug('Waiting for pending requests', {
        clientId: this.clientId,
        broker: this.broker,
        currentInflightRequests: this.inflight.size,
        currentPendingQueueSize: this.pending.length,
      })

      this.once(REQUEST_QUEUE_EMPTY, () => resolve())
      this.logger.debug('waitForPendingRequests end')
      resolve()
    })
  }

Is it expected that we need an event listener on these events for the lib to retry the connection?


[stable/Jenkins] Update plugins version

Update plugins to avoid deprecated errors and update docs:

CLA did!

/lgtm
/ok-to-test

@davidkarlsen I did it!

/lgtm
/ok-to-test

/approve

/lgtm


FW-1430: Upgrade Redux ~3.5.3 => ^4.0.5

Upgrade Redux ~3.5.3 => ^4.0.5
Dropped redux-logger, wasn't being used

Let's hold off on merging them until release 3.4.2 is complete.

Tested full e2e suite with cypress, the following tests did not pass:
•	DialectFilterList-Phrases.js (Stop browsing by phrasebook was actually stop browsing by category)
•	DialectFilterList-Words.js (Sorting while filtering by categories issue, Further testing required)
•	LangAdminViewEdit-Word.js (uncaught error when clicking on words button from testlanguage 2)
•	LangAdminViewEdit-Phrase.js (Element detached from DOM)
•	Navigation (Dog element detached from DOM)
•	RecApprovalCreateDelete-Phrase.js (Test phrase detached from the DOM)
•	RecApprovalCreateDelete-Word.js (Test word detached from DOM)
•	RecorderCreate-Phrase.js (Testvideo missing, may be an issue with the test)
•	RecorderEnable-Word.js (Failed to login to testlanguagefive, uncaught error)
•	RecorderPublishUnpublish-Word.js (Timeout clicking testword because element is detached from DOM)
•	SearchDialect-Phrases-Private.js (Query that should return empty was not empty)
•	SearchDialect-Phrases-Public.js (Query that should return empty was not empty, possibly just a timing issue as empty page was shown after)
•	Word crud (Possible issue with updating definition, requires further testing)
All other tests passed

Thanks @bronson-c


Remove Hobby Shop preset

...because no one knows what it is. See Wiki: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dhobby
My hobby is OpenStreetMap - would I buy a map in a Hobby Store?:)
This preset has terms: manga, figurine, model - we already have separate presets for these ones - shop=anime, shop=collector and shop=model.
I suggest addding "hobby" as a term for these presets:

shop=anime
shop=bicycle
shop=boat
shop=books
shop=brewing_supplies
shop=collector
shop=craft
shop=doityourself
shop=fishing
shop=games
shop=hunting
shop=model
shop=music
shop=musical_instrument
shop=outdoor
shop=scuba_diving
shop=sports
shop=toys
shop=video
shop=video_games

So one can easily find the right preset.

@maro-21 I agree people should use more specific tags if they exist. But it's also useful to have a general category for some cases, as evidenced by the hundreds of uses of the tag. Some shops brand themselves as hobby shops after all—there are five entries in the NSI.
Anyway, you'll need to get more buy-in from the community before we can remove an existing preset like this. You can't just edit the wiki and open an iD issue 😄

You can't just edit the wiki and open an iD issue

To be clear - the only thing I did was expanding the list of suggested replacements:
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dhobby&diff=2017292&oldid=1806009
Everyone can see how the Wiki page looked like before my edit:
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dhobby&action=history
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dhobby&oldid=1806009

when the hobby presets/brands were added to iD/NSI last year, there was no discussion cd1a842

Exactly :)

Some shops brand themselves as hobby shops after all—there are five entries in the NSI.

This has been fixed: https://github.com/osmlab/name-suggestion-index/commit/59d701f2e0d87da49dc2abe79d459eebbdc43cce


Get version # from CVEv5

From natural language/CVEv4, try to get a vulnerable version# of the target application from CVEv5. Also try to get any other structured data about how the version is exploitable.

already pushed


Show incidentCauseDetail on desktop public side if it exists

and show default disclaimer if it is null. I think this functionality was removed when the bug for defaults was fixed. It works on the mobile version already.

Not sure I understand the change to the component. Why not check the value in an ngIf on the incident-info-panel level?

@sukhpalp right now it is just the generalIncidentCauseCatId being passed to the SuspectedCauseCardComponent. I'm changing it to pass the full incident so that the incidentCauseDetail can be used if it's not null, and if not generalIncidentCauseCatId can be used to set a default. I'm not sure what an ngIf would look like at the higher level as there are two different values that possibly need to be used?


Machine learning: CNTK generates CNTKv2 models that aren't supported by WinML

Using Fast-RCNN to do some object detection/localization (https://docs.microsoft.com/en-us/cognitive-toolkit/Object-Detection-using-Fast-R-CNN#train-on-your-own-data), recommended via the Train AI Model (https://docs.microsoft.com/en-us/windows/uwp/machine-learning/train-ai-model) and I discovered it spits out a model in CNTKv2 format, which isn't supported by WinML or conversion tools.
A note about Microsoft not supporting their own CNTKv2 format might be relevant on the Conversion Samples page at a minimum (https://docs.microsoft.com/en-us/windows/uwp/machine-learning/conversion-samples).

CNTK to ONNX: https://github.com/onnx/tutorials/blob/master/tutorials/CntkOnnxExport.ipynb

Thanks for raising the issue! We'll clarify how you can use conversion tools to obtain an ONNX model to use with Windows ML.

Thanks @serenaz, this doesn't work for many CNTK models (filed a separate bug for this https://github.com/Microsoft/CNTK/issues/3033)


cannot find module pino

Error: Cannot find module 'pino'
Require stack:
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>- /Users/calebcushing/IdeaProjects/briggo/services/app-lib/graph/packages/app/src/shared/logging/LoggerConfig.ts
- /Users/calebcushing/IdeaProjects/briggo/services/app-lib/graph/packages/app/src/context/ContentfulConfig.ts
- /Users/calebcushing/IdeaProjects/briggo/services/app-lib/graph/packages/app/src/ApolloServerConfig.ts
- /Users/calebcushing/IdeaProjects/briggo/services/app-lib/graph/packages/app/src/App.ts
- /Users/calebcushing/IdeaProjects/briggo/services/app-lib/graph/packages/app/src/index.ts
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:965:15)
    at Function.Module._load (internal/modules/cjs/loader.js:841:27)
    at Module.require (internal/modules/cjs/loader.js:1025:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at Object.<anonymous> (/Users/calebcushing/IdeaProjects/briggo/services/node_modules/@new10com/axios-logger/src/logger/logger.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:1137:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Module.require (internal/modules/cjs/loader.js:1025:19)

using yarn 2 I added the following to the yarnrc, this adds dependencies to the package, and then the module is working fine.
packageExtensions:
  '<EMAIL_ADDRESS>    dependencies:
        pino: '^6'
        pino-pretty: '^4'

Thanks, will check where pino is still used, because i think i removed it since we didn't need it anymore.

I had a problem with publishing new versions of the library to npm from Github. Now it should be fixed in v0.1.3 - can you please give it a try ? @xenoterracide

looks good


Refactor fugue sql

Codecov Report

Merging #327 (d46dd45) into master (3c51e28) will decrease coverage by 0.01%.
The diff coverage is 96.87%.

@@             Coverage Diff             @@
##            master     #327      +/-   ##
===========================================
- Coverage   100.00%   99.98%   -0.02%
===========================================
  Files          102      100       -2
  Lines         9531     9439      -92
===========================================
- Hits          9531     9438      -93
- Misses           0        1       +1

Impacted Files
Coverage Δ

fugue_sql/_visitors.py
99.81% <96.15%> (-0.19%)
:arrow_down:

fugue_sql/workflow.py
100.00% <100.00%> (ø)

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 3c51e28...d46dd45. Read the comment docs.


Update sites.yml

This PR is:

[

[ ]

[ ]

[ ]

[x] Adding a new domain

[ ] Updating existing domain size

[ ] Changing domain name

[ ] Removing existing domain from list

[ ] Website code changes (512kb.club site)

[ ] Other not listed

[x] I used the uncompressed size of the site
[x] I have included a link to the Cloudflare report
[ ] This site is not an ultra lightweight site
[x] The following information is filled identical to the data file

I confirm that I have read the FAQ section, particularly the two red items around minimal pages and inappropriate content and I attest that this site is neither of these things.

[] Check to confirm

- domain: janandrei.pages.dev
  url: https://janandrei.pages.dev/
  size: 86.74
  last_checked: 2024-01-30

Cloudflare Report: https://radar.cloudflare.com/scan/6bfbee55-e6f6-4c3a-afe5-a8c699a8a7e1/summary

Thanks!


Enable MET graphics and other variants, enable gsi-env in unified-dev template

Summary

Add variants +graphics +lidar2nc +modis to MET in configs/common/packages.yaml, making the MET packages look like this:

    met:
      version: ['11.1.0']
      variants: +python +grib2 +graphics +lidar2nc +modis
    metplus:
      version: ['5.1.0']

Enable gsi-env in unified-dev template
Added pic variant to a number of packages in configs/common/packages.yaml, required to build MET and its dependencies on Ubuntu CI with the Intel compiler. Credits for these changes go to @eap who first proposed them, but the PR went stale and never got merged (https://github.com/JCSDA/spack-stack/pull/625). I don't think that adding these variants hurts building on systems/in environments were static libraries are used, but maybe @AlexanderRichert-NOAA can test building the static ufs-weather-model environment (which, by the way, needs updating before the release) on Acorn?

Testing

[x] CI
[ ] @climbfuji's macOS: still running
[ ] Todo: Narwhal with Intel and GNU (pick one of the trickiest platforms and see how far it gets)

Applications affected
List all known applications (UFS WM, JEDI, SRW, etc.) intentionally or unintentionally affected by this PR.
Systems affected
List all systems intentionally or unintentionally affected by this PR.
Dependencies

[ ] waiting on https://github.com/JCSDA/spack/pull/316

Issue(s) addressed
Resolves https://github.com/JCSDA/spack-stack/issues/739
Resolves https://github.com/JCSDA/spack-stack/issues/689
Checklist

[x] This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
[ ] These changes have been tested on the affected systems and applications.
[ ] All dependency PRs/issues have been resolved and this PR can be merged.

I'd been meaning to follow up on the MET graphics/lidar/modis question. This adds a number of dependencies, and I'm still not clear on whether it was needed by the original user, or if that original user's needs were based on a UFS/JEDI application. Would it be good enough to have the functionality in the recipes in case users want to build their own MET, but not enable it in the unified environment unless/until it's needed for UFS or JEDI?

I'd been meaning to follow up on the MET graphics/lidar/modis question. This adds a number of dependencies, and I'm still not clear on whether it was needed by the original user, or if that original user's needs were based on a UFS/JEDI application. Would it be good enough to have the functionality in the recipes in case users want to build their own MET, but not enable it in the unified environment unless/until it's needed for UFS or JEDI?

I am pretty sure that JEDI will want those options soon, too. We just started adding MET to our workflow and experimenting with its features. But things like modis and lidar are likely going to be needed. I've got it all working now, and the additional dependencies aren't that many. But I'd also like to hear from @mathomp4 on what he thinks.

We could, for the time being, enable these variants only in CI so that at least we know it's working?

Looks good to me! As to the MET package, how the modules are formed, is it possible to add another env. variable? For example, MET_INSTALL_DIR variable is one of the commonly used in MET package; it is identical to MET_ROOT but MET_INSTALL_DIR is hard-coded into the package, so it needs to be set in either case. Currently installed MET packages used with SRW also have another variable defined in the modulefile, MET_BIN_EXEC. This variable, however, may not be required for MET, and set for convenience with the use with SRW workflow.

Thanks for reviewing. I will let @weiwilliam and @AlexanderRichert-NOAA weigh in on which variables should be set or not, since they recently discussed this in detail (in https://github.com/JCSDA/spack-stack/issues/757).

I mean, I only asked if you could add the variants as a local user here builds MET with them. If spack-stack can't, I suppose the user can keep building by hand. But we'd love if you could!

I think we can, the question is whether we make them the default everywhere or just in CI + Discover until JCSDA needs them everywhere (if that is the case).

Ah. Okay. Well, I suppose that if/once it's on Discover, I can have my user try it out with his workflow.

@climbfuji @natalie-perlin
As I know, MET_INSTALL_DIR is defined when the spack-stack (at least JCSDA fork) installs METplus.
https://github.com/JCSDA/spack/blob/a041f7d05c59a90c2a37b281ac73052c9786a130/var/spack/repos/builtin/packages/metplus/package.py#L54-L56
        metplus_config.filter(
            r"MET_INSTALL_DIR = /path/to", "MET_INSTALL_DIR = {}".format(met_prefix)
        )

So, it means users don't need to specify the MET_INSTALL_DIR in main.conf anymore.
It is in the default.conf under $metplus_ROOT/parm/metplus_conf folder.
@natalie-perlin is MET_BIN_EXEC pointed to run_metplus.py?
It could be helpful to ensure the use of the correct python script but not required because the $metplus_ROOT/ush will be prepended in the $PATH.
Then direct running run_metplus.py should always use the right one.
@climbfuji For the application I have (GridStat), the current set of env variables is sufficient to use. I'm not sure if there are other env variables needed for other applications (I believe it's not).

Thanks @weiwilliam. @natalie-perlin looks like everything is set correctly?

@AlexanderRichert-NOAA Please let me know if you would like me to revert the default variants for MET and enable them only in CI and on Discover for now, or leave as is. Thanks!

@climbfuji if you think those variants are likely to be used for JEDI then it's no problem. For me the main thing is that our general approach is to not needlessly add more dependencies, but I'm not worried about this particular instance.

I think a compromise is the best solution for now; build in CI and on Discover (this is also where the JEDI folks exploring MET are working mostly, because they deal with geos, aerosol and all that atmospheric composition stuff). I'll make the change!

@AlexanderRichert-NOAA @natalie-perlin @mathomp4 @ulmononian Ready for your final review.


Integrate Phone Sign In

Add Firebase Phone Sign-In as one of the authentication options and enable it in the dropdown of "Authentication".

Hi I would like this issue

Could you assign this issue to me

This issue is currently not open to accept public contributions, so as you can see it's assigned to me. Actually, I'm doing some refactoring of this project structure. Once, it's done I will open a new set of issues having a "Hacktoberfest" label by this week.

Oh ok nevermind.


set linkColor rgba

Hello,
I'm trying to update the alpha values of edges by changing linkColor in the config, but it does not appear to work. I can set the alpha value on first load however.
Ideally, I tried graph.setConfig({ linkColor: [128,128,178,.5] }); first, as well as by string "rbga(128,128,178.5)"
(Almost there, hopefully I can send a link to you tomorrow, when we have https working so you can see our application of cosmograph)

Hi @awaterho! Thank you for your issue! We found the bug.  Fixing 🛠

@awaterho Fixed in 1.3.0-beta.3


fix timeout description

Closes #361
I think there is a wrong word here in the description of how timeout works.

Thanks. Merged (rebased, which github doesn't handle gracefully).


Handle Homebrew renaming mobile-shell to mosh

Homebrew left in an alias for mobile-shell so the mosh package
actually installs correctly, but Salt's pkg.installed state then tries
to verify the installation by checking the installed packages.
That list only shows mosh and not the mobile-shell alias,
causing the state the fail.
Update to the new name, which is also consistent with everyone else.

This change is

The upstream change is at https://github.com/Homebrew/homebrew-core/pull/18636.
r? @larsbergstrom or @edunham

:pushpin: Commit db0781e has been approved by larsbergstrom

@bors-servo r+

:hourglass: Testing commit db0781efcf20d7473c1ce451fea6e33b03c9752e with merge f52d6098c61fd7b8046deed54579bd75d459743e...

:sunny: Test successful - status-travis
Approved by: larsbergstrom
Pushing f52d6098c61fd7b8046deed54579bd75d459743e to master...


Higher-precision types defined in packages

@stevengj pointed out this doesn't support other types with higher precision than Float64 such as DecFP.jl, DoubleFloats.jl, or QuadMath.jl.
There are two potential issues:

Where does the method definition live? We could either use package extensions, or this could be added as a dependency to those packages? One advantage of adding this as a package dependency, is that those packages could then define their own custom suffix (e.g. DecFP.jl could export const _dec128 = SuffixConversion.SuffixConverter{Dec128}(), which would allow users to write 1.2_dec128 (I'd be happy to transfer this to JuliaMath to facilitate this).

How to define the conversion efficiently? Currently the BigFloat method will call parse(BigFloat, ::String) at runtime: I'm not too worried about BigFloat performance, but for other types we would typically want to make sure the conversion is constant folded. Note that parse isn't constant folded for built-in types (see https://github.com/JuliaMath/ChangePrecision.jl/issues/14 for a related issue), let alone user-defined ones.

Actually the following might work generally
Base.@assume_effects :foldable Base.:*(x::Number, ::SuffixConverter{FT}) where {FT} = parse(FT, string(x))


Update readme sample in creating-a-javascript-action.md

What's being changed (if available, include any code snippets, screenshots, or gifs):
On doc page https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action#creating-a-readme there is a markdown sample with a ready to copy button.

If you copy/paste that sample as a new file, the output is the following:

This PR slightly improves that sample with the following two changes:

The input and output are now h3 instead of h2, to differentiate from the input/output headers.
The yaml sample is now inside triple-backtick for yaml code.

If you copy/paste this modification, the output is as follows:

Side-by-side screenshots

Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

@TrianguloY Thanks so much for opening a PR! I'll get this triaged for review :zap:


Deep import error on Core or imported libs

Hi, my application a Monolith angular with domains.
So:
src/app/domains
src/app/domains/domain1
src/app/domains/domain2
src/app/shell
src/app/shell/.... shell stuffs
I installed sherif and add a sheriffConfig with:
import { noDependencies, sameTag, SheriffConfig } from '@softarc/sheriff-core';

export const sheriffConfig: SheriffConfig = {
  excludeRoot: true,
  version: 1,
  tagging: {
    libs: {
      'ui-<ui>/src': ['domain:shared', 'type:ui'],
      'util-<util>/src': ['domain:shared', 'type:util'],
    },
    'src/app': {
      'domains/<domain>': {
        'feature-<feature>': ['domain:<domain>', 'type:feature'],
        'ui-<ui>': ['domain:<domain>', 'type:ui'],
        data: ['domain:<domain>', 'type:data'],
        'util-<ui>': ['domain:<domain>', 'type:util'],
        '+state': ['domain:<domain>', 'type:state'],
      },
    },
  },
  depRules: {
    root: ['*'],

    'domain:*': [sameTag, 'domain:shared'],
    'type:feature': ['type:ui', 'type:data', 'type:util'],
    'type:ui': ['type:data', 'type:util'],
    'type:data': ['type:util'],
    'type:util': noDependencies,
  },
};

I know that I need to add index.ts file in all my folder, but I just do a test and execute ng lint.
Then I start receiving lint error on some import that are not in my application.
For example, in the sheriff.config.ts file I got a DeepImport error (Deep Import (internal error): invalid path mapping detected: @app/: app/. )  on:
import { noDependencies, sameTag, SheriffConfig } from '@softarc/sheriff-core';
Or in my app.component.ts I got the same error on
import { Component, inject } from '@angular/core';
I miss something, any idea?
Maybe because I got some custom path in tsconfig?
"baseUrl": "src",
"paths": {
"@src/": ["./"],
"@app/": ["app/"],
"@domains/": ["app/domains/"],
"@environmments/": ["environmments/"],
"@fuse/": ["./@fuse/"],
"@shared/": ["app/domains/shared/"],
"@shell/": ["app/shell/"]
}

Hi @pdsavard, would it be possible to paste all import commands of your app.component.ts? Not just the first one?

@rainerhahnekamp I have a lot of impote because of FontAwesome.
I will add the proper index.ts in my domains folders, but I got error on @angular/core or other libs on files outside my domains. Can I exclude the check for all files outside src/app/domains?
Here the import on app.component.ts. The error append on the first on only:
import { Component, inject } from '@angular/core';
import { CommonModule, registerLocaleData } from '@angular/common';
import { RouterOutlet } from '@angular/router';
import { AppStore, SplashScreenService } from '@shell/app';
import { DialogModule } from '@progress/kendo-angular-dialog';
import { ConfigStore } from '@shell/config';
import { HelperService } from<EMAIL_ADDRESS>
// FONT AWESOME ------------
import { FaIconLibrary } from '@fortawesome/angular-fontawesome';
//pro-solid FAS
import { faCommentExclamation as fasCommentExclamation } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faCommentExclamation';
import { faCheck as fasCheck } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faCheck';
import { faHome as fasHome } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faHome';
import { faTh as fasTh } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faTh';
import { faIndustry as fasIndustry } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faIndustry';
import { faSquareArrowLeft as fasSquareArrowLeft } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faSquareArrowLeft';
import { faChevronLeft as fasChevronLeft } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faChevronLeft';
import { faChevronRight as fasChevronRight } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faChevronRight';
import { faChevronUp as fasChevronUp } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faChevronUp';
import { faX as fasX } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faX';
import { faTasks as fasTasks } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faTasks';
import { faUser as fasUser } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faUser';
import { faCartShopping as fasCartShopping } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faCartShopping';
import { faArrowsUpDownLeftRight as fasArrowsUpDownLeftRight } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faArrowsUpDownLeftRight';
import { faChartArea as fasChartArea } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faChartArea';
import { faSitemap as fasSitemap } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faSitemap';
import { faCloudArrowDown as fasCloudArrowDown } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faCloudArrowDown';
import { faChartColumn as fasChartColumn } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faChartColumn';
import { faBuildingColumns as fasBuildingColumns } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faBuildingColumns';
import { faDollarSign as fasDollarSign } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faDollarSign';
import { faListOl as fasListOl } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faListOl';
import { faTruck as fasTruck } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faTruck';
import { faArrowsRotate as fasArrowsRotate } from '../../node_modules/@fortawesome/pro-solid-svg-icons/faArrowsRotate';
//pro-regular FAR
import { faTriangleExclamation as farTriangleExclamation } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faTriangleExclamation';
import { faBars as farBars } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBars';
import { faExpandArrows as farExpandArrows } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faExpandArrows';
import { faSearch as farSearch } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faSearch';
import { faBookmark as farBookmark } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBookmark';
import { faEdit as farEdit } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEdit';
import { faPlusCircle as farPlusCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPlusCircle';
import { faMinusCircle as farMinusCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faMinusCircle';
import { faCheckCircle as farCheckCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCheckCircle';
import { faTimesCircle as farTimesCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faTimesCircle';
import { faPencil as farPencil } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPencil';
import { faBookHeart as farBookHeart } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBookHeart';
import { faInbox as farInbox } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faInbox';
import { faEnvelopeOpen as farEnvelopeOpen } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEnvelopeOpen';
import { faBell as farBell } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBell';
import { faCog as farCog } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCog';
import { faCogs as farCogs } from '../../node_modules/@fortawesome/pro-regular-svg-icons';
import { faBolt as farBolt } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBolt';
import { faMoon as farMoon } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faMoon';
import { faSun as farSun } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faSun';
import { faChevronRight as farChevronRight } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faChevronRight';
import { faUserCircle as farUserCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faUserCircle';
import { faSignOut as farSignOut } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faSignOut';
import { faCircleInfo as farCircleInfo } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCircleInfo';
import { faEye as farEye } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEye';
import { faEyeSlash as farEyeSlash } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEyeSlash';
import { faCheck as farCheck } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCheck';
import { faArrowFromLeft as farArrowFromLeft } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faArrowFromLeft';
import { faChartLine as farChartLine } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faChartLine';
import { faUserLock as farUserLock } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faUserLock';
import { faPuzzlePiece as farPuzzlePiece } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPuzzlePiece';
import { faRetweet as farRetweet } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faRetweet';
import { faPaperPlane as farPaperPlane } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPaperPlane';
import { faGrid2Plus as farGrid2Plus } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faGrid2Plus';
import { faCirclePause as farCirclePause } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCirclePause';
import { faPause as farPause } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPause';
import { faFaceSleeping as farFaceSleeping } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faFaceSleeping';
import { faPenCircle as farPenCircle } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faPenCircle';
import { faFloppyDiskCircleArrowRight as farFloppyDiskCircleArrowRight } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faFloppyDiskCircleArrowRight';
import { faXmark as farXmark } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faXmark';
import { faLock as farLock } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faLock';
import { faCircleArrowRight as farCircleArrowRight } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCircleArrowRight';
import { faCircleArrowLeft as farCircleArrowLeft } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCircleArrowLeft';
import { faKey as farKey } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faKey';
import { faBarcode as farBarcode } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBarcode';
import { faSquareCheck as farSquareCheck } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faSquareCheck';
import { faListTree as farListTree } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faListTree';
import { faEllipsisVertical as farEllipsisVertical } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEllipsisVertical';
import { faArrowRotateLeft as farArrowRotateLeft } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faArrowRotateLeft';
import { faFaceFrown as farFaceFrown } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faFaceFrown';
import { faEllipsis as farEllipsis } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faEllipsis';
import { faArrowRightArrowLeft as farArrowRightArrowLeft } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faArrowRightArrowLeft';
import { faCreditCard as farCreditCard } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCreditCard';
import { faScaleBalanced as farScaleBalanced } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faScaleBalanced';
import { faMoneyBill1 as farMoneyBill1 } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faMoneyBill1';
import { faChartLineUp as farChartLineUp } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faChartLineUp';
import { faBug as farBug } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faBug';
import { faCircleExclamation as farCircleExclamation } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCircleExclamation';
import { faArrowsRotate as farArrowsRotate } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faArrowsRotate';
import { faCircleXmark as farCircleXmark } from '../../node_modules/@fortawesome/pro-regular-svg-icons/faCircleXmark';
//pro-light FAL
import { faBars as falBars } from '../../node_modules/@fortawesome/pro-light-svg-icons/faBars';
import { faEllipsisHAlt as falEllipsisHAlt } from '../../node_modules/@fortawesome/pro-light-svg-icons/faEllipsisHAlt';
import { faPercent as falPercent } from '../../node_modules/@fortawesome/pro-light-svg-icons/faPercent';
//pro-dustone FAD
import { faSyncAlt as fadSyncAlt } from '../../node_modules/@fortawesome/pro-duotone-svg-icons/faSyncAlt';
import { faCodeMerge as fadCodeMerge } from '../../node_modules/@fortawesome/pro-duotone-svg-icons/faCodeMerge';
// Brand  FAB
import { faAngular as fabAngular } from '../../node_modules/@fortawesome/free-brands-svg-icons/faAngular';
import { faProductHunt as fabProductHunt } from '../../node_modules/@fortawesome/free-brands-svg-icons/faProductHunt';
import { NotificationStore } from '@shell/notification';
// FONT AWESOME ------------
import localeFrCa from '@angular/common/locales/fr-CA';
import localeFrCaExtra from '@angular/common/locales/extra/fr-CA';
import { BroadcastService } from './domains/shared/services/broadcast';

Thanks @pdsavard, I think I have now everything I require. Looks like a bug.

@rainerhahnekamp ok! Feel free if you need direct access to my computer. I can shared it if that help. Thanks

Thanks, but it is not necessary. I guess it is related to paths. We heavily rely on TypeScript's API for the parsing part and detecting the imports. Unfortunately, paths is something that TypeScript does not support; it "outsources" that work to bundlers (webpack, vite, etc.).
So Sheriff has to do that manually and there's some potential for bugs like this one.

Ok I see!
I will check for the next update. But I think that do not stop me to implement it. I will just ignore these errors or add eslint ignore comment for now.

OK, not it do not work. I will remove Sheriff for now and add it later when the correctif will be posted.

Fixed in version 0.14.5. Please confirm once you have the time try it out. Thanks

@rainerhahnekamp not shure. But I am in lurning curve with Sheriff.
I use a simple rule that not supposed to block anything.
export const sheriffConfig: SheriffConfig = {
  excludeRoot: true,
  version: 1,
  tagging: {
    'src/app/domain/shared': 'shared',
  },
  depRules: {
    '*': anyTag,
  },
};

and I got some error like
import { anyTag, SheriffConfig } from '@softarc/sheriff-core';  in my sheriff.config.ts or a lot of:
C:\Data_Dev\Angular\KelvinV3-2\src\app\domains\auth+state\auth.state.ts
1:1  error  Deep Import (internal error): invalid path mapping detected: @environmments/: environmments/. Please verify that the path exists      @softarc/sheriff/deep-import
1:1  error  Dependency Rule (internal error): invalid path mapping detected: @environmments/: environmments/. Please verify that the path exists  @softarc/sheriff/dependency-rule
C:\Data_Dev\Angular\KelvinV3-2\src\app\domains\auth+state\auth.store.ts
1:1  error  Deep Import (internal error): invalid path mapping detected: @environmments/: environmments/. Please verify that the path exists      @softarc/sheriff/deep-import
1:1  error  Dependency Rule (internal error): invalid path mapping detected: @environmments/: environmments/. Please verify that the path exists
I will continu to test.

yes, but that means that ./src/environments does not exist. Can you check if that folder is really there?

And please double-check if you are on version 0.14.5

Hooo my bad, a typo error in the path in my tsconfig.json.
Now everything work. I got some warning on " Use the module's index.ts or path".
With basic sherrif config without any dependency, only index.ts error will pop, i think?

Just to be shure in domains folder, do you create a index.ts in the root of each domain or in subfolder ?
domains

auth

index.ts
data
ui
feature
...

Without sheriff.config.ts you only get the message of the index.ts
I usually try to avoid having nested index.ts. So I would not put it into auth, unless auth is an nx library. In that case, I would put one index.ts in auth and one per subfolder.

Thanks for your help!

Pierre, I am going to close this issue. If new questions rise up, please let me know and open a new issue.


Keep cursor icon when resizing and moving mouse

Cursor icon should indicate which edge is being resized.

Done in 2fd6612


Franklin 0.9.14 broke code sections

E.g. from https://julialang.org/blog/2020/08/invalidations/
f(x::Int) = 1
applyf(container) = f(container[1])

Looks like #610 is the problem.

thanks for the quick reaction; will look into this

Hmm it's the prerendering via highlight that messes up ...

ok I have a fix for it, am doing a round of testing then will push a patch release


[MI200][Reduction] Fails when all dimensions of a destination tensor are 1

When dimensions of source tensor are {15, 12, 3, 5} and dimensions of destination tensor are {1, 1, 1, 1} I get the following runtime error:
gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp:45:32: error: use of undeclared identifier 'CK_PARAM_TOREDUCE_DIMS'
using toReduceDims  = Sequence<CK_PARAM_TOREDUCE_DIMS>;
                               ^
gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp:46:32: error: use of undeclared identifier 'CK_PARAM_INVARIANT_DIMS'
using invariantDims = Sequence<CK_PARAM_INVARIANT_DIMS>; // this could be empty
                               ^
2 errors generated when compiling for gfx90a.
MIOpen Error: /long_pathname_so_that_rpms_can_package_the_debug_info/data/driver/MLOpen/src/tmp_dir.cpp:45: Can't execute cd /tmp/miopen-gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp-b189-3965-5db3-f0ee;  /opt/rocm-5.0.0/llvm/bin/clang++  --std=c++17 -DCK_AMD_GPU_GFX90A -DCK_USE_AMD_BUFFER_ATOMIC_FADD=0 -DCK_BLOCK_SYNC_LDS_WITHOUT_SYNC_VMEM=1 -DCK_USE_AMD_BUFFER_ADDRESSING=1 -DCK_PARAM_SRC_DATATYPE=1 -DCK_PARAM_DST_DATATYPE=1 -DCK_PARAM_REDUCE_COMPTYPE=1  -DCK_PARAM_BLOCKSIZE=256 -DCK_PARAM_THREAD_BUFFER_LENGTH=8 -DCK_PARAM_ACCESSES_PER_THREAD_INBLOCK=2 -DCK_PARAM_ACCESSES_PER_THREAD_INWARP=2 -DCK_PARAM_REDUCE_OP=3 -DCK_PARAM_NAN_PROPAGATE=0 -DCK_PARAM_REDUCE_INDICES=0 -DCK_PARAM_IN_DIMS=4 -DCK_PARAM_OUT_DIMS=1 -DCK_PARAM_SRC2D_PADDING=1 -DCK_PARAM_DST1D_PADDING=1 -mcpu=gfx90a -Wno-everything --cuda-gpu-arch=gfx90a:xnack- --cuda-device-only -c -O3  -Wno-unused-command-line-argument -I. -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false -x hip -isystem /opt/rocm-5.0.0/hip/../include -isystem /opt/rocm-5.0.0/llvm/lib/clang/14.0.0/include/.. -D__HIP_PLATFORM_HCC__=1 -D__HIP_PLATFORM_AMD__=1 -isystem /opt/rocm-5.0.0/hip/include -isystem /opt/rocm-5.0.0/include --hip-link  -DHIP_PACKAGE_VERSION_FLAT=5000022042 gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp -o /tmp/miopen-gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp-b189-3965-5db3-f0ee/gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp.o

I noticed that if I change only 1 dimension in the destination tensor to be equal that in the source tensor the issue goes away. Also, other cases with different shapes of source tensor can pass, e.g.  {5, 3, 2, 9}.
Is there a workaround for this issue? The current workaround seems to be avoiding the cases when all dimensions of the destination tensor are 1.
MIOpen 2.16
ROCm 5.0.0

Reproducer (clickable)
#include <functional>
#include <numeric>

#include "miopen/miopen.h"

#define CHECK_MIOPEN(f, msg) \
    do { \
        const auto ___status___ = f; \
        if (___status___ != miopenStatusSuccess) { \
            throw std::runtime_error(msg); \
        } \
    } while (0)
#define CHECK_HIP(f, msg) \
    do { \
        const auto ___status___ = f; \
        if (___status___ != hipSuccess) { throw std::runtime_error(msg); } \
    } while (0)

int main() {
    auto status_miopen = miopenStatusSuccess;
    auto status_hip = hipSuccess;

    const int ndims = 4;
    //int src_dims[ndims] = {5, 3, 2, 9};
    int src_dims[ndims] = {15, 12, 3, 5};
    int dst_dims[ndims] = {1, 1, 1, 1};
    //int src_strides[ndims] = {54, 18, 9, 1};
    int src_strides[ndims] = {180, 15, 5, 1};
    int dst_strides[ndims] = {1, 1, 1, 1};
    float beta = 0.0f;
    float alpha = 1.0f;

    auto nan_prop_mode = miopenNanPropagation_t::MIOPEN_NOT_PROPAGATE_NAN;
    auto indices_mode
            = miopenReduceTensorIndices_t::MIOPEN_REDUCE_TENSOR_NO_INDICES;
    auto indices_type = miopenIndicesType_t::MIOPEN_32BIT_INDICES;
    auto op_kind = miopenReduceTensorOp_t::MIOPEN_REDUCE_TENSOR_MAX;

    void *workspace = nullptr;
    size_t workspace_size = 0;

    // Create handle
    miopenHandle_t handle {};
    status_miopen = miopenCreate(&handle);
    CHECK_MIOPEN(status_miopen, "Couldn't create handle.");

    // Create Tensor descriptor
    miopenTensorDescriptor_t src_desc;
    status_miopen = miopenCreateTensorDescriptor(&src_desc);
    CHECK_MIOPEN(status_miopen, "Couldn't create src desc.");
    miopenTensorDescriptor_t dst_desc;
    status_miopen = miopenCreateTensorDescriptor(&dst_desc);
    CHECK_MIOPEN(status_miopen, "Couldn't create dst desc.");
    miopenReduceTensorDescriptor_t reduce_desc_;
    status_miopen = miopenCreateReduceTensorDescriptor(&reduce_desc_);
    CHECK_MIOPEN(status_miopen, "Couldn't create reduce desc.");

     Maybe an unsupported case or a potential bug in reduction implementation.

@densamoilov
I could not reproduce the mentioned issue on ROCM.5.1 using your codes.  And you can also do verification using [densamoilov](https://github.com/densamoilov)
I remember the issue has been solved by some P.R.
You can check the codes of the file gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp,   which does not have CK_PARAM_TOREDUCE_DIMS and CK_PARAM_INVARIANT_DIMS used

@qianfengz, thanks for the quick response. I have one more question just to make sure I understand how it works. Since this issue is in MIOpen and I use the latest available MIOpen release (2.16) does it mean that ROCm can include MIOpen version that is not officially released?

@densamoilov
2.16 should be the major version of the MIOpen package,   you can get the complete version of MIOpen on ubuntu by #> dpkg -s miopen-hip.   And for each ROCM release/installation, there is a corresponding MIOpen release branch.  For example for ROCM 5.1,  the release MIOpen branch should be release/rocm-rel-5.0.
Also,  I just checked the codes rocm-rel-5.0 gridwise_generic_reduction_second_call_threadwise_reduce_all_dims.cpp,  it seems the mentioned issue have been solved by ROCM-5.0.
You can verify by compiling your codes against the headers provided with the package miopen-hip, rather than against any downloaded miopen source.  Like,
#> hipcc -I/opt/rocm/miopen/include -L/opt/rocm/miopen/lib -lMIOpen -o test_reduce test_reduce.cpp

I can confirm that the issue is fixed. Thanks again for the detailed explanation!


Fix login

Codecov Report

Merging #1206 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1206   +/-   ##
=======================================
  Coverage   43.61%   43.61%
=======================================
  Files          32       32
  Lines        3572     3572
  Branches      580      580
=======================================
  Hits         1558     1558
  Misses       1872     1872
  Partials      142      142

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 ca6caef...a78a11d. Read the comment docs.

I don't like the commit title.

Thanks!

Thanks!

I use the commit and repo search a lot to find issue for current problems. Titles like this makes searching for error fixes and problem a bit more complicated. I would recommend you to be more aware of your commit text next time.
Because a fix login is a really broad term. A better option would be "fixed login for x example file". But thanks for your contribution :)

@reliefs thank you for your comment. I would recommend you to comply with the Instabot License agreement and put a link to the Instabot project in your Instabotai project sources because you use my Intellectual property. The full list of license conditions can be found in the Apache 2.0 license.
I will not contact any legal services so this action will remain on your conscience.

@reliefs are you for real? I understand your point but you earning money of my work and especially @ohld and complaining about that you've to open a PR so you can merge it into your own bot is just crazy. Mind share your income from the bot with us? I might be able to listen to you.

Sure do what you want, you first signed the License today.. Also instabot is only a small part of the code. I have not earned more than $11, so there isn't really anything to do.. the code is too buggy now.
I really don't understand your question last time you wanted my entire script over to your repo.. Instabot is only 10% of the script..
Do you want me to put your License into my instabot folder ?
I am now focusing on http://www.rankbabes.com which will release in a few days.. and the instabotai part is taken fully out of the.. If instabotai does not get fixed i will either go away from python to php, because my issues are process issues.
Same process each user delete each other.. Also i have the api start request error.. But i have focused most on rankbabes.com

Instabot is only 10% of the script

This doesn't matter at all. Think about it.
I know that this is my mistake - I've created a license file a couple of years ago and I thought that it would have the power I want. I've contacted GitHub support and they told that "sorry, you have to sign it first". I've trusted the GitHub's helper window that told that "Copyright notice" is one of the required License conditions.
But the point is the developer ethics. There would be no problem if you forked the project, make all the fixes you want and use your forked repo as git submodule - in that case, GitHub handles all copyrighting by itself, this is very useful. But you just copypasted sources into your project, put your own license there, removed all links to original contributors like every line was written by you.
I think your future colleagues should be aware of that situation that you have appropriated the source code written by other people, even if it was legally possible by my mistake. I'm attaching all screenshots I made - I really hope that they can help to prevent this or similar behavior from the future and can save a lot of effort and time.

I learned a lot from this situation, so thank you - next time I will be smarter.

Please stop cotacting me, I am not doing anything wrong.. What you are doing now isharrasment and illegal.
Here are danii begging me to move my repo to his organisation because 10% of my code is instabot haha..
https://i.imgur.com/jDR1J9x.png

I also have contributed a code to the old license, now because you changed license i do not agree with the new terms.. So i want all my contributions deleted..
Thanks for understanding.

lol

kk i will contact github have a nice day.

https://github.com/instagrambot/instabot/commit/7dfe19d92ebfa6102f05b25b5afb438759098432#commitcomment-36698234
just make a reference link so we have all your excuses everywhere to be seen

can i just add this to the irony 🤣:
http://instabotai.com/
More scripts
you even made a url mistake that links to this use (instagrambot and your repo. Do not bother changing it. Since it is on pastbin already:
https://pastebin.com/ecZDJ3kv
I also got a copy from it.

@bruvv This is not a mistake - "instabotai" project was in "instagrambot" organization a while ago. Since this project was started and maintained by @reliefs, he decided to create his own organization and transfer the repo to it.
Thank you @bruvv for your support, I really appreciate that. But please, don't try to be rude. As for me, this looks unprofessional. I truly believe that @reliefs understand the whole situation and will do the right thing soon.

No you are lying i created the repo months before and then you asked me to transfer it to your repo.. i did that.. No one has contributed to instabotai except me, so after i started in your organisation you wanted a lot of stuff from me and my bot got more issues so i transferred it out again.. Then you complained for 7 months now.
You have never contributed to my code that is nonsense, if you don't delete my code from your repo i will file a DMCA takedown and and copyright issue for your code.. You have never written anything of instabotai that is nonsense and 90% of it all is free open source templates we both use.. so what is your issue.
For me that you now try to say you created instabotai is complete nonsense, you have not contributed one line of code except for import instabot.. out of 5000-10.000 lines i have written myself.

https://github.com/instagrambot/instabot/commit/7dfe19d92ebfa6102f05b25b5afb438759098432


Mattresses and conveyor belts

Give mattresses and conveyor belts a place within the levels. Both blocks and the robot will bounce on a mattress, and blocks will be moved by a conveyor belt (you can't change their x-velocity, because they will automatically return to the speed of the conveyor belt ).
For example, you can make a block that can only be moved to the left because there is a wall on the right, and then let the player move it left so that it falls down on a conveyor belt, which then throws the block on a mattress even further down, so that it bumps back up to the right on a new platform.

This issue is almost complete.


temp: attempt to store feature qualifiers

Changes:
Note:

By the updates in this PR, complete, the converter can accurately round trip conversion for all iGEM distribution GenBank files of the form BBF10K_000***.gb (86 test files).
A leader test file - iGEM_BBF10K_000***.gb has been added to test/test_files/sbol3_genbank_conversion to represent all related test files, and a unit test - test_round_trip_iGEM_BBF10K is added in place for it.
The only case when absolute memory-based file diff would not return identical status is when either of the following is true:

The Keywords field is not sorted in the given GenBank file. (see the 2nd TODO below)
A few features are off of their correct position (based on FeatureLocation's lexicographic sort) in the given GenBank file.

Refactoring:

Complete handling of Sequence Features creation and linking of corresponding Feature Qualifiers during conversion from GenBank to SBOL is now done by helper function _handle_features_gb_to_sbol.
Similar handling of Sequence Features for conversion from SBOL to GenBank is done by helper function _handle_features_sbol_to_gb

Updates:

Added new test file test/test_files/sbol3_genbank_conversion/feature_qualifier_storage.gb to test storage and resetting of feature qualifiers, and updated a few other test files.
New class Feature_GenBank_Extension extends the sbol3.SequenceFeature class, to include extra text properties of Qualifier keys and Qualifier values.
A builder build_feature_qualifiers_extension is also registered for the same in the Converter's init to use this new class to parse SequenceFeatures encountered in an SBOL file.
Many files in the iGEM distribution Suite have incorrect positioning of the topology information in the data_file_division section of the GenBank file. To resolve this, an extra check is added while parsing topology information:

topology = "linear"
if "topology" in record.annotations:
    topology = record.annotations["topology"]
# sometimes topology is specified in the 'data_file_division' field
elif record.annotations['data_file_division'] in ['circular', 'linear']:
    topology = record.annotations['data_file_division']

Since the order of storage of ListTextProperties can get messed up while storing it in SBOL, in order to get the correct Qualifier value for a Qualifier key, we store the keys and not values not simply as their string formats, but with an id pre-pended by which we shall sort the array while resetting the qualifiers in conversion from SBOL to GenBank.

Eg: If Feature Qualifiers are ['qual_a': 'val_a', 'qual_b', 'val_b']; they will be stored in extended sequence feature class's Qualifier keys as ['1: qual_a', '2: qual_b'] and in Qualifier values as ['1: val_a', '2: val_b']. Thus, even if the order among keys and values is not preserved, we sort the items in both arrays by the integer before ':' and then iterate through them, ensuring that correct values are mapped to their respective keys.

keys = sorted(obj_feat.qualifier_key, key=lambda x: int(x.split(":", 1)[0]))
values = sorted(obj_feat.qualifier_value, key=lambda x: int(x.split(":", 1)[0]))

TODO:

[x]  Remove temporary iGEM distribution test files from PR.
[x] Although, as per discussion on slack, sorting the list of Keywords before outputting Genbank files should be fine (see https://www.ncbi.nlm.nih.gov/Sitemap/samplerecord.html#KeywordsB), I am open to having the order maintained during conversion, using a similar workaround as we did for Taxonomy (storing the list as a string). This might reduce the amount of "false negatives" our converter test throws (A correct conversion is determined as incorrect due to different order of Keywords).

@jakebeal this PR adds a lot of iGEM genbank files. Do we want those added to this repository? Or should they be used by reference somehow, like downloading them from GitHub during testing, or making the iGEM repo a submodule, or some other approach. I assume the iGEM genbank files will change over time.

@tcmitchell  @jakebeal, I have implemented the storage and resetting of feature qualifiers as per our discussion in the last meeting; this should be good to merge unless there are any issues with the review.

@tcmitchell  @jakebeal  I have included the storage of Keywords as a string instead of a sorted list, and also a couple of small refactors as suggested by Tom, this PR should be good to merge.

I think this PR is related to issue #166 (Support all of the sample files in the iGEM distribution). Is that correct?
Does this PR close #166 or is it another step on the path to #166?

I think this PR is related to issue Support all of the sample files in the iGEM distribution #166 (Support all of the sample files in the iGEM distribution). Is that correct?

Yes

Does this PR close Support all of the sample files in the iGEM distribution #166 or is it another step on the path to Support all of the sample files in the iGEM distribution #166?

Yes, it adds support for a big chunk of those files, only a few remain now


Cathay Pacific

thankyou dear kolos 26 for giving me such a wonder full opportunity to upload my aircrafts

I don’t think kolos26 accepts fictional liveries
Your livery looks really odd

The font is wrong
Just use Sitka it's a better font for Cathay pacific

I don’t think kolos26 accepts fictional liveries

Your livery looks really odd

And the text is not flipped

and the livery doesnt look odd

The font is wrong Just use Sitka it's a better font for Cathay pacific

thanku very much, i will change it.

sorry but i think you are not aware that its not a fictional livery

It is fictional livery, somebody made it in Photoshop


Add Django 1.7 migrations, and use django.contrib.admin.utils to support django 1.7

Adding Django migrations for Django > 1.7.
And change import in users.admin module to use django.contrib.admin.utils
To remove deprecation warning RemovedInDjango19Warning in Django 1.8

Coverage increased (+0.04%) to 94.14% when pulling eb56fcab69e5d9e18732801f6630b3181b4ce388 on moemen:master into b06743b08ab2ffc066f1fad0fc6ef924574f31aa on mishbahr:master.

Coverage increased (+0.04%) to 94.14% when pulling eb56fcab69e5d9e18732801f6630b3181b4ce388 on moemen:master into b06743b08ab2ffc066f1fad0fc6ef924574f31aa on mishbahr:master.

+1

Oops. I did not see this pull request.
I fixed all these issues.. just today. Not published on pypi just yet... waiting for django-nose to support django=1.8. Travis build is failing for django==1.8
Thank you for your pull request.

@moemen I would love to add you as a contributor to this repo.. if that's okay with you... Let me know otherwise.


HTTPS required for security

Correct me if I'm wrong, but this solution will not be secure unless it is used over HTTPS. I feel like that should be called out in the README.

+1


docs(cli/prisma2): Update npm package in README

Added changes in main PR https://github.com/prisma/prisma2/pull/1947


Remove Image unused and keep is per image instead of per database.

Before submitting the bug

[x] Ensure you are able to reproduce it on the latest released version (we release often)
[x] Verified this bug is not already reported in an issue
[x] Verified errors are not related to permissions
[x] Can reproduce in a clean PowerShell session (clean = powershell -NoProfile)

Describe the bug
When running the command:
Remove-DcnImage -unused -keep 1
I would expect the command to remove unused images and keep the most recent image for each database. However, removes all unused and keeps the most recent image.
For example, I have 3 database images created on 1/7 and generate a new image for each database on 2/7. This gives me the below table:

ImageID
Database
Used?
Created

1
Db1
unused
1/7/2021

4
Db1
unused
2/7/2021

2
Db2
unused
1/7/2021

5
Db2
unused
2/7/2021

3
Db3
unused
1/7/2021

6
Db3
unused
2/7/2021

When you run the above command it would remove all images, leaving only 1 image (ImageID 6). I would expect it to only remove the oldest image per database, leaving us with ImageID 4, 5, and 6.
Is this intended? Are you meant to specify the database when using -unused -keep [x]?
I'm using dbaclone version:
0.10.38

For the time being I'm using the below code:
Get-DcnImage |
Select-Object -Unique -Property DatabaseName |
ForEach-Object {
    Remove-DcnImage -Database $_.DatabaseName -Unused -keep 1
}

We could make the default value for -Keep  to be 1 so that it would always keep the latest one?
The parameter Unused is meant to delete all the images that are unused without looking at new ones at all.
Would that be a solution?

The main issue is when I run Remove-dcnImage with the 2 params I would expect it to apply per database, not to all images.
I have 10 images all for different databases. I run the remove command with the -unused -keep 1 and it removes 9 images. I would expect it to remove none because each image is for a different database.
We have 2 automated scripts one to create new images which we run every month, and one to remove the old images which we run every day.
The removal script original just did the below:
Remove-dcnImage -unused -keep 1

But we found that removes all unused images instead of per database. We changed the script to run the below instead:
Get-DcnImage | Select -Unique DatabaseName |
ForEach-Object {
    Remove-DcnImage -Database $_ -Unused -keep 1
}

I guess the question is:
Should these 2 parameters be treated as per database instance or as all images?


[NBS]: Create authorization integration test

Add all access service mocks (new/old).

Done in #1939


Remove Sprache dependency

Depends on #1667

What does the pull request do?
Change SelectorGrammar to use the Reader class used in binding path parsing (moved up to Avalonia.Markup in #1667). Also, update Reader to be a ref struct with a ReadOnlySpan<char> to represent the member.

I've included some perf numbers below:
Sprache:
               Method |     Mean |    Error |   StdDev |   Gen 0 | Allocated |
--------------------- |---------:|---------:|---------:|--------:|----------:|
 ParseComplexSelector | 90.55 us | 1.764 us | 2.167 us | 52.2461 |  80.41 KB |

No Sprache:
               Method |     Mean |     Error |    StdDev |  Gen 0 | Allocated |
--------------------- |---------:|----------:|----------:|-------:|----------:|
 ParseComplexSelector | 3.921 us | 0.0695 us | 0.0879 us | 1.4420 |   2.22 KB |
Span-ified:
               Method |     Mean |     Error |    StdDev |  Gen 0 | Allocated |
--------------------- |---------:|----------:|----------:|-------:|----------:|
 ParseComplexSelector | 3.966 us | 0.0650 us | 0.0576 us | 1.1978 |   1.84 KB |

Sprache is the code in master. No Sprache is a Selector parser based on the Reader class that still uses strings and StringBuilders. Span-ified is the version at the tip of this PR branch (1133c3e).
Checklist:

[x] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

There's a few workarounds in here for our Android projects that I can move into our packages so users don't need to work around it as well, but this PR is no longer blocked on Xamarin.Android!
@grokys @jmacato can you take a review pass at this?


Update to use qtpy imports

Hello team!
The plugin documentation for napari has a set of best practices for developers, which includes a clause recommending not to depend directly on PyQt5 or PySide2 to allow end-users to choose their bindings freely. More details here.
The files using PyQt5 instead of qtpy are listed here -> https://github.com/HelmholtzAI-Consultants-Munich/napari-organoid-counter/blob/224eff90e17cc5a62353e04f179cfe2d39969b4e/napari_organoid_counter/_widget.py#L9
Also I suggest you do not use the * import. That is generally not recommended
Some options might include changing this code
from PyQt5.QtCore import Qt
from PyQt5.QtWidgets import *

To

from qtpy.QtCore import Qt
from qtpy.QtWidgets import QWidget   # and explicitely list everything that is needed

Or to

from qtpy import QtCore
from qtpy import QtWidgets

# And then use it like

class OrganoidCounterWidget(QtWidgets.QWidget):

I favor option 1 as it is more explicit in what needs to be imported for a given module.
Is there a reason you need PyQt5 explicitly? Could these imports be updated to use qtpy for the next release?
If you have questions, or need some help, let me know :)
Thanks! 🚀

Thanks so much for your tips @goanpeca! #25 includes these changes, I will push a new version now :)


[Unitary Hack draft] quantum modular arithmetic

Partially addresses #49 as part of the Unitary Fund's 2024 hackathon (see message on #49).

Hey @khnikhil, I really like this! The explanation to code to explanation flows nicely and I really like the references to other HierarQcal tutorials. So far I only have a few minor comments, when you're done with the draft I'll go through everything again but you're on the right track.
Comments

Motivation paragraph: I like the tone and general idea that it tries to communicate. On the more technical side, for quantum computing the operators are unitary but not necessarily Hermitian (for example a rotation gate is not Hermitian $R_z(\theta)R_z(\theta)\ket{\psi}=R_z(2\theta)\ket{\psi}$). But the Unitarity requirement alone does restrict us to reversible computation because $U^\dagger=U^{-1}$ and $U^\dagger$ always exists (the inverse is already encoded in the structure of the matrix). So update the paragraph but keep the tone and main idea. Out of interest, and seeing if I can remember myself

The restriction of Unitarity ensures whatever states we create are always normalized, $\braket{0|U^\dagger U|0}=1$ and so our probabilities sum to one. But there's many reasons one can give, you can also take it as one of the postulates that the evolution of a state is unitary. The "log" of the circuit is Hermitian though, by solving the Schrodinger equation we can write  $U\ket{\psi}=e^{-\frac{i}{\hbar}\hat{H}t}\ket{\psi}$, and this $\hat{H}$ is Hermitian (it's the Energy operator and we want energy to be real )

I really like the transition from half adder to full adder!
The picture of the full adder is a bit small, maybe you can find a bigger one?


ClassDirectives.java:172-176: Implement different way to...

The puzzle 108-537ed26f from #108 has to be resolved:
https://github.com/objectionary/jeo-maven-plugin/blob/a7176742502b8a335026f8500cb7edad6af89bbb/src/main/java/org/eolang/jeo/representation/asm/ClassDirectives.java#L172-L176
The puzzle was created by @volodya-lombrozo on 29-Sep-23.
Estimate: 90 minutes,  role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 108-537ed26f has disappeared from the source code, that's why I closed this issue.


Tree shaking doesn't work and my app size gets bloated

Describe the bug
Tree shaking doesn't work.
I have below code in my app ( please refer https://github.com/yugandhar-pathi/tree-shaking)
if (process.env.NODE_ENV === 'development') {
  makeServer(); // This will include
}

When I run npm run build contents meant for dev environment also get included in bundle.
I see that there 2 chunks created, size of all the chunks is close to 1.7MB.
My app hardly has one source file, why the size is so high ?
Environment
I am using latest version of react-scripts
  "dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.5.0",
    "@testing-library/user-event": "^7.2.1",
    "react": "^16.13.0",
    "react-dom": "^16.13.0",
    "react-scripts": "3.4.0"
  },

Expected behavior
App bundle is supposed to exclude what ever I have under process.env.NODE_ENV === 'development'
Actual behavior
App bundle has all the libs which I included for dev purpose.

(Write what happened. Please add screenshots!)
Reproducible demo
Please refer https://github.com/yugandhar-pathi/tree-shaking

you can use dynamic import instead
if (process.env.NODE_ENV === 'development') {
  import('./server').then(({makeServer}) => {
      makeServer(); // This will include
  });
}