Escape special characters

According the spec: https://docs.influxdata.com/influxdb/v1.2/write_protocols/line_protocol_reference/#special-characters
Some special characters must be escaped.
Found this by trying to store a quote in a string value.
It can be handled by the caller site, but it is probably more correct to check this on this site.
This is not finished yet as added test fails on shouldEqualLine.sortLine as there is a problem with parts parsing now (it doesn't handle escaped characters).
@atilaneves please let me know if this is the right direction and so I should solve the failing test too.
Also there should be probably added unescape for the read values.

It's in the right direction, yes. And yes, the tests can't fail. It looks like they do due to auto parts = line.split(" ");, and since there's an escaped space there it splits it incorrectly. That's the line to change to fix the tests. Thanks.

Ok, so I reworked it a bit. Tests are green again.

Finally all green. Didn't found a better way for the older compilers through a lot of trial and errors..


Add mirotalk-bro recipe

Pre-flight Checklist
Please ensure you've completed all of the following.

[] I have read the Contributing Guidelines for this project.
[X] I agree to follow the Code of Conduct that this project adheres to.

Description of Change
New release - add MiroTalk Live Broadcast to recipes.
MiroTalk WebRTC Live broadcasting involves the real-time transmission of audio, video, and data streams from a broadcaster to multiple viewers. Instead of relying on a centralized server to distribute the stream to viewers, WebRTC enables a direct connection between the broadcaster and each viewer. This approach offers several advantages, such as lower latency, scalability, and reduced infrastructure costs.
Live demo: https://bro.mirotalk.com/
GitHub: https://github.com/miroslavpejic85/mirotalkbro
Note: Unlimited time, unlimited rooms each having a broadcast and many viewers.
Thank you!

This is very strange as per default the .editorconfig is configured correctly.
And also on my repo from where I sent the PR seems ok to me.
I missing something? :)
Thank you.

@all-contributors please add @miroslavpejic85 for code

Yes, already there, thank you so much guys!


Type inference error with funny type variable names.

I want to report this funny error:
 type Type =
    static member M1 v (h:'E1->_) = let f (t:^t) = (^t : (static member M2: _ -> _) v) in f Unchecked.defaultof<Type> h
    static member M2 (m:Choice<'T,'E1>) = fun (h:'E1 -> Choice<'T,'E2>) -> match m with Choice1Of2 v -> Choice1Of2 v | Choice2Of2 e -> h e

This gives:
~vs4DD6.fsx(3,48): error FS0001: Type mismatch. Expecting a
'E1 -> 'a
but given a
'E11 -> Choice<'T,'E2>
The type ''E1' does not match the type ''E10'

Which is funny because there is no mention of 'E10 nor 'E11 in the code. Where it came from?
There are million ways of workaround this, for instance inverting the order of the static members solves the issue but I thought it might be worth to investigate.

Where it came from?

Maybe compiler does some standardization apart before unification/constraint solving?

This is a ramification of various simplifications we make when presenting type information. See minimalStringOfTwoTypes here for example: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/NicePrint.fs#L1891.
It is corner-case enough that I will close this as by design. However I do believe it's (obviously) possible to improve the situation, and an experimental PR to do that would always be welcome.


Readme: Remove incorrect reference to got options

Readme docs reference got docs for http options, but the package actually uses request at the moment. Request doesn't support retries (shown as to be default behavior).

Thanks for info. If that's urgent, do PR please.


[#438] Several deployments fail with "Run From Package Initialization failed."

Fixes # 438
Description
This PR fixes an issue where the AzureWebApp@1 task fails with a Kudu Zip Deployment error (Failed to deploy web package to App Service.).
This issue was caused due to two set of configuration steps that made the App Service to restart and fail when processing the uploaded Zip:

There was missing the WEBSITE_RUN_FROM_PACKAGE setting from the ARM Template.

When the variable is not set, the AzureWebApp@1/runFromPackage method will update the variable showing the Updated App Service Application settings and Kudu Application settings message, otherwise will show App Service Application settings are already present. avoiding the App Service restart.

Using Microsoft.Web/sites/config to configure the Virtual Network Subnet was causing the restart of the App Service.

Changing the resource type to configure the Subnet in the App Service with Microsoft.Web/sites/virtualNetworkConnections solved the issue.

Specific Changes

Added WEBSITE_RUN_FROM_PACKAGE explicitly for DotNet and JS bots.
Replaced Microsoft.Web/sites/config with Microsoft.Web/sites/virtualNetworkConnections.
Replaced AzureWebApp@1 zipDeploy with runFromPackage.

Testing
The following image shows the list of Deploy pipelines runs and the Kudu Zip deploy error.

Promoted to MS in PR# 442


NugetCommand does not use Azure Credential Provider for Linux

Required Information
Question, Bug, or Feature?
Type: Bug
Enter Task Name: NugetCommand
Environment

Server - Azure Pipelines

Issue Description
When using the NugetCommand task on a Linux agent, a warning is spit out by nuget.

WARNING: The credential plugin model used by '/home/vsts/work/_tasks/NuGetCommand_333b11bd-d341-40d9-afcf-b32d5ce6f23b/2.164.0/CredentialProvider/CredentialProvider.TeamBuild.exe' is deprecated. Please contact the provider of the plugin for an alternative. More information about the recommended plugin model can be found at 'https://aka.ms/nuget-cross-platform-authentication-plugin'.

We are also seeing this old plugin crash sometimes, providing instability to our builds.
Therefore we'd like to update to the new plugin model. It looks like some logic was added to the NugetCommand task to use the next version of the credential plugin, but it's Windows only (#8367).
One option would be to integrate with the recently added= task NugetAuthenticate. The NugetCommand task currently does not use the plugin setup by the NuGetAuthenticate task.

The fix to this issue will be blocked by #12524

The NuGetAuthenticate task is intended to be used with a script task instead of the NuGetCommand task, so we just set up authentication and get out of the way and you can call nuget.exe however you want

Ah, gotcha, thanks for the explanation. In that case, this issue is not blocked by #12524 but is still an issue all the same.

Hey @schultetwin1 - are you able to use NugetAuthenticate and script instead of NugetCommand? That is our recommended path moving forward.

Hi @herenhuang, definitely! Currently we use NugetAuthenticate and a script instead of NugetCommand.
I had this issue open to point out that if you run NugetAuthenticate to install the Azure Credential Provider plugin, and then use NugetCommand, NugetCommand will not use that plugin.
Up to you guys how you want to proceed.

Got it! We've got it in our bug log. And to confirm, this isn't currently blocking right?

Thank you!!

And to confirm, this isn't currently blocking right?

That is correct. This isn't currently blocking.


Update README.md

Contribution Guidelines
Please ensure your pull request adheres to the following guidelines:

Search previous suggestions before making a new one, as yours may be a duplicate.
Make an individual pull request for each suggestion.
Use the following format: Bookmark Title: Description.
The title usually consists of several words. For bookmarks of an article or tutorial, use the title of the article.
The description consists of one-two sentences about the bookmark. It is required.
If the resource has 2 or more links please provide the Github repo link.
Additions should be added to the bottom of the relevant category.
New categories or improvements to the existing categorization are welcome.
Check your spelling and grammar.
Make sure your text editor is set to remove trailing whitespace.
The pull request and commit should have a useful title.

Thank you for your suggestions!

Hello @JBAhire, thanks for the Pull Request and congratulations on the fantastic blog. That said, we already have a decent coverage of ideas around word vectors.
Hence, not merging this.


MCS-342 validate types

This is really awesome, but the ticket (MCS-342) was originally written to implement this behavior in the scene generator. Should we make a separate ticket to add typeguard to the scene generator?

This is really awesome, but the ticket (MCS-342) was originally written to implement this behavior in the scene generator. Should we make a separate ticket to add typeguard to the scene generator?

Once we understand an approach, it'll take very little work to integrate into the scene generator. I was more concerned at the time with prototyping as well as thinking about how to protect our Python API.


Issue with odd number of shards

Facing problem with reconstructing file while using odd number of data shards(5,2):
var dataShards = flag.Int("data", 5, "Number of shards to split the data into, must be below 257.")
var parShards = flag.Int("par", 2, "Number of parity shards")
My terminal output:
$ ./simple-encoder README.md
Opening README.md
File split into 7 data+parity shards with 287 bytes/shard.
Writing to README.md.0
Writing to README.md.1
Writing to README.md.2
Writing to README.md.3
Writing to README.md.4
Writing to README.md.5
Writing to README.md.6
$ rm README.md.0 README.md.1
$ mv README.md README.md.bkp
$ rm -rf README.md
$./simple-decoder README.md
Opening README.md.0
Error reading file open README.md.0: no such file or directory
Opening README.md.1
Error reading file open README.md.1: no such file or directory
Opening README.md.2
Opening README.md.3
Opening README.md.4
Opening README.md.5
Opening README.md.6
Verification failed. Reconstructing data
Writing data to README.md
$ sha1sum README.md README.md.bkp
a1376818a75bdb3daa925eb84787deaea08f70a3  README.md
16bcbf011764251da257a7ab39b7cdc02395748d  README.md.bkp

Newly constructed files includes control characters "^@^@^@"
Please suggest how to solve this.

Hi!
The "simple-encoder" has some limitations listed in the source. The important one is the first:

If the file size of the input isn't (divisible) by the number of data shards the output will contain extra zeroes.

The solution for this is listed below and requires you to store the expected output size somewhere else, (along with a hash for each shard for checking whether a shard is good).

Sure. Storing and verifying hash of each shard separately works for my system. Thanks.


Fix problem that not uses proxy

This change is

I signed it! for CLA

@nkreeger PTAL

@haoyunfeix I encountered the proxy problem and just wrote the same code change. I'm looking forward to using the fixed version of tfjs-node module.

I'd really like to the fixed module in my hands-on. Could you publish it on npm repository? 🙏 🙏 🙏


Fix: Section 8 seed data

What
Link to story
The section 8 proceeding types were added but the service levels were not.
The scope limitations are handled by the EligibleScopesService which makes the ProceedingTypeScopeLimitation model and ProceedingTypeScopeLimitationPopulator outdated so this PR removes them and replaces the calls to the original table with uses of EligibleScopesService
Checklist
Before you ask people to review this PR:

Tests and rubocop should be passing: bundle exec rake
Github should not be reporting conflicts; you should have recently run git rebase main.
There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
The PR description should say what you changed and why, with a link to the JIRA story.
You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
You should have checked that the commit messages say why the change was made.

Agreed that removing the table is odd - it was a matter of expediency.  The eligible scopes class handled everything I needed and the table was under populated
I will raise a ticket in jira to review this decision with links to this PR and the commits within


fix: Modal widget background issues

Description
The following issues were caused because of the recent changes with respect to auto height instant update.
In the recent change, we removed a few wrappers around containers which seemed unnecessary. This led to the fact that in deploy mode, these wrappers were not present. The issue with this was that, these wrappers were responsible for the modal widget's background color styling. This also led to an issue where the background color was not applied in edit mode.
To fix this, we've added a wrapper in the component and removed all styling logic from the widget. This is because, the component is responsible for the actual rendering and what users see. The widgets should act as an interface, and as a result, should not deal with styling.
Fixes #20434
Fixes #20405
Fixes #20436
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Manual
Cypress

Checklist:
Dev activity

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

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=c59324d

/ok-to-test sha=5cc263c

/ok-to-test sha=5cc263c

QA done for the fixes. @riodeuno


Wrong example in subtyping.md?

The subtyping section has the following text:

If mutation is by-value, then the old location that remembers extra details is moved out of, meaning it can't use the value anymore. So we simply don't need to worry about anyone remembering dangerous details. Put another way, applying subtyping when passing by-value destroys details forever. For example, this compiles and is fine:
fn get_box<'a>(str: &'a str) -> Box<&'a str> {
    // String literals are `&'static str`s, but it's fine for us to
    // "forget" this and let the caller think the string won't live that long.
    Box::new("hello")
}

If mutation is by-reference, then our container is passed as &mut Vec<T>. But &mut is invariant over its value, so &mut Vec<T> is actually invariant over T. So the fact that Vec<T> is covariant over T doesn't matter at all when mutating by-reference.

Explanations of subtyping always push me to my limit, so when I can't see how the example relates to the discussion, my first assumption is not "Oh, the text is wrong"! But I suspect that the example here is just the wrong text, because there's no mutation going on anywhere, nor any &mut Vec<T>.

Ah, interesting. We could definitely do with a better example here. And yeah following text should refer to the same type and also probably have its own example.
I will however assert the example is both correct and relevant to the text that precedes it. It takes a Box<'static> and passes it by-value (by returning it) to someone expecting a Box<'a>. This is only sound because passing the Box by-value is a statically verified assertion that no one else has access to the Box, and therefore no one exists who remembers the Box is "supposed" to be 'static.
This is in contrast to e.g. Java where having a MyType<Animal> tells you nothing about who else may have access to that value, and so it would be unsound to construct such a type by "forgetting" that it was a MyType<Cat>, because MyType<Animal> implies that a Dog should be fine to store inside, which will break anyone who knows a Cat should be there.

this chapter was completely rewritten and is much clearer now.


Solution to Installation Problem - Error: Cannot find module 'nan'

Issue Description
After initiating a git pull and merging from upstream / master the following installation error is raised when running npm install.
➜  github-proxy git:(master) npm install

><EMAIL_ADDRESS>install /github-proxy/node_modules/glob-watcher/node_modules/fsevents
> node-gyp rebuild

internal/modules/cjs/loader.js:976
  throw err;
  ^

Error: Cannot find module 'nan'
Require stack:
- /github-proxy/node_modules/glob-watcher/node_modules/fsevents/[eval]
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:973:15)
    at Function.Module._load (internal/modules/cjs/loader.js:855:27)
    at Module.require (internal/modules/cjs/loader.js:1033:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:120:20)
    at Object.runInThisContext (vm.js:311:38)
    at Object.<anonymous> ([eval]-wrapper:10:26)
    at Module._compile (internal/modules/cjs/loader.js:1144:30)
    at evalScript (internal/process/execution.js:94:25) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/github-proxy/node_modules/glob-watcher/node_modules/fsevents/[eval]'
  ]
}
gyp: Call to 'node -e "require('nan')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/.nvm/versions/node/v13.6.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:321:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Darwin 18.7.0
gyp ERR! command "/.nvm/versions/node/v13.6.0/bin/node" "/.nvm/versions/node/v13.6.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /github-proxy/node_modules/glob-watcher/node_modules/fsevents
gyp ERR! node -v v13.6.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/glob-watcher/node_modules/fsevents):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

Solution to Problem
As documented on the Stack Overflow ...

https://stackoverflow.com/questions/34464673/error-cannot-find-module-nan

This issues was overcome by completely deleting node_modules and reinstalling with npm install as below.
rm -rf node_modules && npm install
Potential Next Steps
Please let me know if you'd like this issue documented in the project for future development reference and I'll raise a pull request.
👍

I think now the dependencies are stable - this should not be a problem


Slightly generalize

We have
at
    :: ((() -> Identity b) -> s -> Identity t)
    -> (i -> b)
    -> (i -> s)
    -> i
    -> t

But () isn't really the only reasonable target type. We could have, for example,
data Rec1 a b = Rec1 { _foo :: a, _bar :: b }
data Rec2 a b c = Rec2 { _baz :: Rec1 a b, _quux :: c }

There are two different reasonable ways to build a Rec2 starting with Rec2 () () ():

Use baz . foo, baz . bar, and quux to build from an a, a b, and a c.
Use baz and quux to build from a Rec1 a b and a c.

at currently only supports option 1. We can support option 2 using this type:
atg
    :: Full u => ((u -> Identity b) -> s -> Identity t)
    -> (i -> b)
    -> (i -> s)
    -> i
    -> t

Should the type of at be changed, or should a new function be added with the more general type?

The situation for on is similar, I believe. Suppose we have
data Sum1 a b = A a | B b
data Sum2 a b c = AB (Sum1 a b) | C c

We currently support matching on Sum2 using _AB . _A, _AB . _B, and _C, but not using _AB with _C. The target of _AB just can't be made Void; it needs to be made Sum1 Void Void.
We should be able to fix this the same way:
ong
    :: Empty v
    => ((a -> Either a v) -> s -> Either a r)
    -> (a -> o)
    -> (r -> o)
    -> s
    -> o

@treeowl: I would be fine with generalizing at / on so that we don't need to add additional utilities.  I'm guessing that it doesn't lead to any type inference issues?

@treeowl: I would be fine with generalizing at / on so that we don't need to add additional utilities.  I'm guessing that it doesn't lead to any type inference issues?

I'm still thinking through the type inference question.

I'm still thinking through the type inference question.

There definitely are type inference issues... Thinking about this...

There definitely are type inference issues... Thinking about this...


Subnet can't be deleted if used in a VPC endpoint

Description
Deploying a VPC with an endpoint with 3 AZs, then reducing the number to 2 AZs fails.

[x] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]:

Terraform version:
1.6.1

Provider version(s):
registry.terraform.io/hashicorp/aws v5.22.0

Reproduction Code [Required]
provider "aws" {
  region  = local.region
  profile = local.profile
  default_tags {
    tags = local.tags
  }
}

data "aws_availability_zones" "available" {}

locals {
  name    = "ex-${basename(path.cwd)}"
  region  = "us-east-2"
  profile = "sandbox-daniel.hook.AWSAdministratorAccess"

  vpc_cidr = "<IP_ADDRESS>/16"
  azs      = slice(data.aws_availability_zones.available.names, 0, 3)

  tags = {
    Example    = local.name
    GithubRepo = "terraform-aws-vpc"
    GithubOrg  = "terraform-aws-modules"
  }
}

module "vpc" {
  source = "../../"

  name = local.name
  cidr = local.vpc_cidr

  azs             = local.azs
  private_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k)]
}

module "vpc_endpoints" {
  source = "../../modules/vpc-endpoints"

  vpc_id = module.vpc.vpc_id

  create_security_group      = true
  security_group_name_prefix = "${local.name}-vpc-endpoints-"
  security_group_description = "VPC endpoint security group"
  security_group_rules = {
    ingress_https = {
      description = "HTTPS from VPC"
      cidr_blocks = [module.vpc.vpc_cidr_block]
    }
  }

  endpoints = {
    ec2messages = {
      service             = "ec2messages"
      private_dns_enabled = true
      subnet_ids          = module.vpc.private_subnets
    }
  }
}

Steps to reproduce the behavior:
Deploy the module as above.
Change the line:
azs      = slice(data.aws_availability_zones.available.names, 0, 3)
to
azs      = slice(data.aws_availability_zones.available.names, 0, 2)
Plan the module.  It will show that it's deleting and changing a number of resources.  Apply the plan.
Expected behavior
The plan is applied, deleting the third subnet.

Error: deleting EC2 Subnet (subnet-0710ac7c70335c514): DependencyViolation: The subnet 'subnet-0710ac7c70335c514' has dependencies and cannot be deleted.
│       status code: 400, request id: 648b69ac-01eb-4435-a95c-ee2652a156d2
Additional context
Trying to delete the subnet from the console will say  "Subnets have network interfaces and cannot be deleted".  This is because an ENI still exists.  I believe this occurs because terraform tries to delete the subnet before it runs this modification on the vpc_endpoint:
# module.vpc_endpoints.aws_vpc_endpoint.this["ec2messages"] will be updated in-place
  ~ resource "aws_vpc_endpoint" "this" {
        id                    = "vpce-07a71fd7508ad8fd8"
      ~ subnet_ids            = [
          - "subnet-0710ac7c70335c514",
            # (2 unchanged elements hidden)
        ]

I believe this occurs because terraform tries to delete the subnet before it runs this modification on the vpc_endpoint:

Correct. Its the order of operations that cause a chicken vs the egg type scenario:
Since the VPC endpoints module relies on the subnet IDs output from the VPC module, Terraform starts with the VPC module and attempts to remove the subnet. This subnet cannot be removed due to the fact that a endpoint is provisioned there


error in generating dependency files

@EgbertRijke gets errors after updating Lean to the newest version and building from source. Last week it worked fine, but now he gets errors in the dependency files, but only for the standard library, not for the HoTT library. For example the contents of binary.d is
/home/egbert/Documents/Lean/library/algebra/binary.olean: \
 /home/egbert/Documents/Lean/library/error:\ file\ 'binary'\ not\ found\ in\ the\ LEAN_PATH

The LEAN_PATH seems to point to the right thing and the file binary does exists.
> echo $LEAN_PATH
/home/egbert/Documents/Lean:

This is done on Ubuntu, after cleaning the whole Lean folder using git clean -Xf.

I just tried on my Ubuntu box, but I couldn't reproduce the problem. @fpvandoorn, could you reproduce it on your machine?

No, for me it works fine...

@EgbertRijke, could you do the following and let us know if it works?
cd /home/egbert/Documents/Lean/library
git clean -fxd
../bin/linja

My apologies for having been unresponsive...
I have just run these commands: and the first error message that I get is:
[6/190] "/home/egbert/Documents/Lean/b...Lean/library/data/finset/equiv.ilean"
FAILED: "/home/egbert/Documents/Lean/bin/lean"  /home/egbert/Documents/Lean/library/data/finset/equiv.lean -o "/home/egbert/Documents/Lean/library/data/finset/equiv.olean" -c "/home/egbert/Documents/Lean/library/data/finset/equiv.clean" -i "/home/egbert/Documents/Lean/library/data/finset/equiv.ilean"
/home/egbert/Documents/Lean/library/data/finset/equiv.lean:6:0: error: invalid import, unknown module 'init'

We don't use linja anymore on the latest version.


Modernized a bunch of stuff

Changed name from toolbelt to cli.
Use current s3 url
Use heroku buildpacks
Avoid HEROKU_ config var prefix
Use buildpack-stdlib
Add heroku to path in profile.d script

Thanks for this and I'm sorry I didn't see it before deprecating the repo. :/

no worries. I think we want a Heroku provider version of this anyway to point folks at.


Add more helper methods for settings result on Activity

Currently, activity has extension methods
https://github.com/microsoft/Omex/blob/a6ac88ec960000bc14562fa2215a7bbb8b486140/src/Extensions/Abstractions/Activities/ActivityExtensions.cs#L60
It looks like they are using a lot, so it would be nice to have additions methods to simplify interactions, for example:
public static Activity MarkAsSuccess(this Activity activity) { ... }
public static Activity MarkAsSystemError(this Activity activity) { ... }
public static Activity MarkAsExpectedError(this Activity activity) { ... }

They would be calling SetResult inside, also some simple unit tests needed for it.

i want to do this isssue

@AndreyTretyak how can i push my changes there?

@MatusTomko you need to

fork a repository

Then you would be able to push your local branch to the forked repository (if you already have a branch in your local copy you can just replace the URL of the remote or add a second remote to push). https://docs.github.com/en/free-pro-team@latest/github/using-git/changing-a-remotes-url
Then you can use GitHub UI to create a pull request from a branch in your fork into the master of this repository. https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request

Please let me know if you would have problems with any of the steps.

@AndreyTretyak I have a problem with Perform CodeQL Analysis, do you know what is problem?

@MatusTomko I think it was intermittent (that build stage not required), I've restarted pipelines and it looks successful now.


Adding support for Sublime 3

Many thanks for creating the plugin.
Since it failed to work with Sublime 3, I ended up fixing it on my side, and here are the changes I happened to do to make it work.
Also added the Mod extension, as it is the common one from Native Oberon files.

@pjmlp Will this still work for Sublime 2?

I cannot guarantee it, as I was forced to do these changes to make your plugin work on Sublime 3, given the breaking changes introduced in regards to begin_edit() and end_edit().
https://www.sublimetext.com/docs/3/porting_guide.html
As I don't have Sublime 2 around to test it, I am not sure if it will still work with it.

OK, I guess we don't have to care much about supporting version 2 since there are no many users anyway :) I'm merging this PR.


Nonsensical static methods?

Hello,
I am currently parsing your documentation and I stumble over a lot of (at least to me) nonsensical static methods.
One example:
sap.m.FlexBox has a static method:
sap.m.FlexBox removeItem(vItem)
Why is this and is there a deeper meaning behind those methods?
I am using the current API doc (1.52)
Thanks & regards

No, these are bugs in the JSDoc. The meaning of @name is often misunderstood. In this case the documentation for addItem was repeated and a
 `* @name sap.m.FlexBox.addItem`

was added instead of
 `* @name sap.m.FlexBox.prototype.addItem`

or even better @name should be omitted.
If you - by accident - have a list of those methods, I'll take care to fix them (on the master branch).
Our API extract (api.json, e.g. https://openui5nightly.hana.ondemand.com/test-resources/sap/ui/core/designtime/api.json ) unfortunately 'inherits' such bugs, much as our SDK which reads all the api.json files.

Ah ok, Thanks a lot. I could try to get info where this happens and can post it here, if you like.

OK, I'll post it here when I got all


Fix grammar in README.

That's what happens when you fast type...

Thanks - I just did a cleanup of the README in master and fixed these anyway :)


Regression in rocm 5.3 and newer for gfx1010

Since when pytorch 2 was officially released, i wasn't able to run it on my 5700XT, while i was previously able to use it just fine on pytorch 1.13.1 by setting "export HSA_OVERRIDE_GFX_VERSION=10.3.0"
There are many reporting the same issue on the 5000 series, like for example
https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/6420
--precison-full and --no-half are also needed because the card seems like can't use fp16 on linux/rocm, as already reported here https://github.com/RadeonOpenCompute/ROCm/issues/1857
i also read about the PCI atomics requirement, following this issue https://github.com/pytorch/pytorch/issues/103973
....But that doesn't seems to be my case. the command "grep flags /sys/class/kfd/kfd/topology/nodes/*/io_links/0/properties" returns:
/sys/class/kfd/kfd/topology/nodes/0/io_links/0/properties:flags 3
/sys/class/kfd/kfd/topology/nodes/1/io_links/0/properties:flags 1

Also, i tried to compile pytorch using the new "-mprintf-kind=buffered" flag, but it didn't change anything.
Finally, i recently found out that pytorch 2 works just fine on gfx1010 if that's compiled by rocm 5.2, as suggested here https://github.com/pytorch/pytorch/issues/106728

What's your motivation to use newer ROCm? Expect better performance?

What's your motivation to use newer ROCm? Expect better performance?

Well, for example to be able to use the official pytorch builds instead of using old nighties or compliling from source.

Also, PyTorch deleted their rocm5.2 repo, so all that's available now is the broken 5.6.

@hongxiayang

Good to hear you make it work, though with the old version. Firstly, I am not sure whether your problem is related to PCIe atomics, or it is just related to gfx arch (1010 is not in the list of compiled targets of the recent wheels). I would hope the 5.7 wheels we build will work if the problem is related to atomics. If you don't have atomics issue, then we should discuss in a different issue.

This is not an atomics issue for gfx1010 users,
λ ~/ grep flags /sys/class/kfd/kfd/topology/nodes/*/io_links/0/properties                                                                                INSERT
flags 1

For 1010 users, my understanding is that there is no official target. We have had to use the HSA_OVERRIDE_GFX_VERSION hack to allow ROCm to function at all. Ever since the release of ROCm5.3, some change in memory access code for the gfx1030 arch has prevented us from using this hack, due to OOB errors.
https://github.com/pytorch/pytorch/issues/103973 caught my eye (and likely other users with similar consumer GPUs) because it's the first issue stating that functionality was lost beyond torch1.13+rocm5.2 that has had a thorough looking at.
In addition, the (greatly appreciated) work of @jeffdaily was the first step we've seen with regards to bumping up the usable version of PyTorch for us.
I understand that the work required to isolate and undo whatever memory access changes took place between 5.2-5.3 is probably more than what its worth, considering AMD's stance on maintaining compat for older GPUs, as well as possibly breaking the actually supported gfx1030 GPUs. Therefore we've been left to fend for ourselves a little.
That's how the issue got a little hijacked, apologies for the intrusion there.
I would say that this issue would be the appropriate place for any continued conversation on the matter. :+1:

ok, we will tackle this issue next @kmsedu @DGdev91

Have you tried to simulate gfx906, like:
export HSA_OVERRIDE_GFX_VERSION=9.0.6

@hongxiayang

Have you tried to simulate gfx906, like:
export HSA_OVERRIDE_GFX_VERSION=9.0.6

Results below:
(57venv) λ ~/ai/stable-diffusion-webui/ master* python --version                                                                                INSERT
Python 3.10.6

(57venv) λ ~/ai/stable-diffusion-webui/ master* pip list | grep rocm                                                                                INSERT
torch                     2.2.0.dev20231114+rocm5.7
torchvision               0.17.0+rocm5.7

(57venv) λ ~/ai/stable-diffusion-webui/ master* HSA_OVERRIDE_GFX_VERSION=9.0.6 python mnist_main.py --dry-run                                                                          INSERT
use_cuda=True arg no_cuda=False cuda available=True
[1]    141921 segmentation fault (core dumped)  HSA_OVERRIDE_GFX_VERSION=9.0.6 python mnist_main.py --dry-run

Stack trace from coredump here:
                Found module linux-vdso.so.1 with build-id: aa98f5cb7cb88a767d1a384eb7b00d363d9d711e
                Found module libfribidi.so with build-id: 6e075a666e1da8ffdb948d734e75d82b1b6dc0fb
                Found module librt.so.1 with build-id: 1e261495981090dca22c9006c3218baead278c7a
                Found module ld-linux-x86-64.so.2 with build-id: 9718d3757f00d2366056830aae09698dbd35e32c
                Found module libc.so.6 with build-id: a43bfc8428df6623cd498c9c0caeb91aec9be4f9
                Found module libm.so.6 with build-id: d2c7d1fdefc7a876b6017c090ccd55fb21e8d77f
                Found module libutil.so.1 with build-id: 24f02e478ddf82435d8c5e0d7eb96f8338f2670b
                Found module libdl.so.2 with build-id: 8ab13ce8a1e6a9b18a844da65688e882f3eb132d
                Found module libpthread.so.0 with build-id: 81f46d553e2f7c999e43c3eede73a822bc8d5d93
                Stack trace of thread 141921:
                #0  0x00007f4fb826614e n/a (/home/kms/ai/stable-diffusion-webui/57venv/lib/python3.10/site-packages/torch/lib/libamdhip64.so + 0x26614e)

Thanks for trying. Next thing we can try is to build pytorch on rocm from source. Since you don't have PCIe atomics issue, we will use official pytorch repository. Here is instructions:

start another terminal, start a new container of (rocm/pytorch:latest-base) with the parameters using the instruction above

sudo docker run -it --network=host --device=/dev/kfd --device=/dev/dri --group-add=video --ipc=host --cap-add=SYS_PTRACE --security-opt seccomp=unconfined --shm-size 8G -u root rocm/pytorch:latest-base

(2) clone the pytorch inside your docker container
git clone --recursive https://github.com/pytorch/pytorch.git
cd pytorch
python tools/amd_build/build_amd.py
PYTORCH_ROCM_ARCH=gfx1010 python setup.py develop
(3) run the test again inside pytorch folder.

I have compiled torch 2.2.0a0+git6849d75 and torchvision 0.17.0a0+4433680.
Below is the output:
root@mainPC:/home/pytorch# pip list | grep torch
torch                    2.2.0a0+git6849d75 /opt/conda/envs/py_3.9/lib/python3.9/site-packages
torchvision              0.17.0a0+4433680   /home/vision

root@mainPC:/home/pytorch# python examples/mnist/main.py --dry-run
Segmentation fault (core dumped)

If a stack trace could be of use, please let me know and I'll figure out how to setup coredumpctl in the docker container.

Any news on this? need more infos?

I tried it also with the new ROCm 6.0, it doesn't really seem to change much. works fine with an old nigtly build of pytorch 2.0 compiled on rocm5.2, but crashes on the last --pre pytorch
Memory access fault by GPU node-1 (Agent handle: 0x968d080) on address 0x7fa860641000. Reason: Page not present or supervisor privilege.
happens with both HSA_OVERRIDE_GFX_VERSION=10.3.0 and without. but it's probably needed since it doesn't work on the 5.2 build without it.

Memory access fault by GPU node-1 (Agent handle: 0x968d080) on address 0x7fa860641000. Reason: Page not present or supervisor privilege.
happens with both HSA_OVERRIDE_GFX_VERSION=10.3.0 and without.
I made this working with HSA_OVERRIDE_GFX_VERSION=9.4.0 (and I had to find this out purely by trial & error....).
It is not fully stable, but it worked with SD within at least two system boots...

Memory access fault by GPU node-1 (Agent handle: 0x968d080) on address 0x7fa860641000. Reason: Page not present or supervisor privilege.
happens with both HSA_OVERRIDE_GFX_VERSION=10.3.0 and without.

I made this work with HSA_OVERRIDE_GFX_VERSION=9.4.0 (and I had to find this out purely by trial & error....). It is not fully stable, but it worked with SD within at least two separate system boots...

I changed the gpu on my machine and cannot verify that. @kmsedu can you?
Aldo, are you sure you were actually running on the last pytorch version? In automatic1111's webui there's a workaround for making it use by default an older pytorch version compiled on ROCm 5.2 on older navi cards like the RX5700xt (i know that well because... I wrote that workaround).

Aldo, are you sure you were actually running on the last pytorch version? In automatic1111's webui there's a workaround for making it use by default an older pytorch version compiled on ROCm 5.2 on older navi cards like the RX5700xt (i know that well because... I wrote that workaround).

Hey there. No, I'm not running on the latest version of pytorch.
And yes, you are correct, I've run this on/witth automatic1111's webui with (your :pray: :heart:) workaround in place. The env HSA_OVERRIDE_GFX_VERSION=9.4.0 made the solution to automatically downgrade the version of pytorch to the version built with rocm 5.2.

Since gfx1010 is not in the support gfx target list (  https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html#supported-gpus), the latest versions may not work for your gpu.

Hey there. No, I'm not running on the latest version of pytorch. And yes, you are correct, I've run this on/witth automatic1111's webui with (your 🙏 ❤) workaround in place. The env HSA_OVERRIDE_GFX_VERSION=9.4.0 made the solution to automatically downgrade the version of pytorch to the version built with rocm 5.2.

Ok, then you have just the same problem. We know that anything compiled using Rocm 5.2 or older works just fine on that card.
If you try to fotce it to a newer version in webui_user.sh probably it's not going to work.
Also, usually HSA_OVERRIDE_GFX_VERSION=10.3.0 is used for the override.
Automatic1111's webui should force it automatically for older gpus, so maybe you were actually using that.

Since gfx1010 is not in the support gfx target list ( https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html#supported-gpus), the latest versions may not work for your gpu.

I know. But it's still wierd that a gpu wich worked perfectly fine with pytorch compiled for an older romc version + HSA_OVERRIDE_GFX_VERSION=10.3.0 (even if not officially  supoorted) suddently stops working on everything compiled using something newer.
I also tried to pick up an old docker image with rocm 5.2 but it doesn't seems able to compile it.
This is also true for other softwares wich rely on rocm, like llama-cpp with hipblas support

I know. But it's still wierd that a gpu wich worked perfectly fine with pytorch compiled for an older romc version + HSA_OVERRIDE_GFX_VERSION=10.3.0 (even if not officially supported) suddently stops working on everything compiled using something newer.

When you use HSA_OVERRIDE_GFX_VERSION=10.3.0, you are telling the ROCm runtime to pretend that your RDNA 1 GPU is an RDNA 2 GPU. The weird thing is that ever worked, not that it stopped working.

This is also true for other softwares wich rely on rocm, like llama-cpp with hipblas support

If you're on Debian 13 or Ubuntu 23.10 or later, use libhipblas-dev. Those have gfx1010 enabled.

If you're on Debian 13 or Ubuntu 23.10 or later, use libhipblas-dev. The OS-provided packages have gfx1010 enabled.

Isn't that just the same as installing the rocm stack (or at least part of it)? It depends on rocblas, wich depends on hip, wich depends on the HSA runtime, and so on.
Also, as i already wrote, the problem isn't the rocm version installed, but the one used to compile the software. And compiling them using the old version usually isn't straightforward/possibile.

Isn't that just the same as installing the rocm stack (or at least part of it)? It depends on rocblas, wich depends on hip, wich depends on the HSA runtime, and so on.

HIP works fine on gfx1010. It's mainly just that the math libraries in AMD's binary packages are (mostly) not built for that architecture.
When I packaged rocBLAS for Debian, I specified for it to be built for gfx1010. I also packaged the test suites for rocBLAS and hipBLAS, and ran them on both the RX 5700 XT, and Radeon W5700. All tests passed.
Of course, nobody has packaged MIOpen for Debian yet, so while the OS packages should be sufficient for llama-cpp, they are not sufficient yet for something like PyTorch.

Isn't that just the same as installing the rocm stack (or at least part of it)? It depends on rocblas, wich depends on hip, wich depends on the HSA runtime, and so on.

HIP works fine on gfx1010. It's mainly just that the math libraries in AMD's binary packages are (mostly) not built for that architecture.
When I packaged rocBLAS for Debian, I specified for it to be built for gfx1010. I also packaged the test suites for rocBLAS and hipBLAS, and ran them on both the RX 5700 XT, and Radeon W5700. All tests passed.
Of course, nobody has packaged MIOpen for Debian yet, so while the OS packages should be sufficient for llama-cpp, they are not sufficient yet for something like PyTorch.

Last time i tried i had a memory access error (just like the newer pytorch versions) when trying to load a model in lama.cpp with both hipblas and clblast offloading, while the second worked fine on Windows. I had the same problem in both ArchLinux and Ubuntu.
But it can easly be a totally different issue.

Since gfx1010 is not in the support gfx target list ( https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html#supported-gpus), the latest versions may not work for your gpu.

When you use HSA_OVERRIDE_GFX_VERSION=10.3.0, you are telling the ROCm runtime to pretend that your RDNA 1 GPU is an RDNA 2 GPU. The weird thing is that ever worked, not that it stopped working.

Anyway, i'm perfectly aware of that. You are right, that card wasn't never supposed to work on rocm in the first place and it works with some older pytorch builds just thanks to a workaround.
That's also true for every consumer-grade amd gpu other than the 7900xt and 7900xtx, wich many users are still using thanks to the same workaround.
But after this reply on november 17th

ok, we will tackle this issue next @kmsedu @DGdev91
I was expecting to see something on this matter anyway.

Last time i tried i had a memory access error [...] when trying to load a model in lama.cpp with both hipblas and clblast offloading, while the second worked fine on Windows. I had the same problem in both ArchLinux and Ubuntu.

To be clear, on Ubuntu were you using libhipblas-dev (which installs to /usr/lib/x86_64-linux-gnu) or were you using hipblas-dev (which installs to /opt/rocm/lib)? If you were using libhipblas-dev, I'm very interested in learning more. Could you provide some instructions on how to reproduce the problem?

That's also true for every consumer-grade amd gpu other than the 7900xt and 7900xtx, wich many users are still using thanks to the same workaround.

Using HSA_OVERRIDE_GFX_VERSION=10.3.0 on RDNA 2 GPUs is fundamentally different from using it on RDNA 1 GPUs. All RDNA 2 GPUs use the exact same instructions, but there's a bunch of differences between the instructions used on RDNA 1 and RDNA 2 GPUs. The only way to undo this 'regression' with HSA_OVERRIDE_GFX_VERSION would be to change LLVM so that the compiler only uses instructions available on RDNA 1, even when asked to compile for RDNA 2. That's not going to happen.
A better path to getting gfx1010 enabled in PyTorch would be to build the ROCm math and AI libraries for gfx1010 (or gfx10.1-generic). That is probably not going to happen in AMD's official packages, but there are other groups building and distributing ROCm packages. I can't speak for other distributions, but I expect to have it enabled later this year on Debian. With that said, my work with Debian is strictly volunteer work (on top of my full-time job), so don't expect it to happen quickly.

Ok, now it's more clear.
I can confirm i used hipblas-dev (as said on the the official docs)
I was also thinking that the hsa override flag was needed for rocblas too, because i couldn't use it on native 1010 since the libs for 1010 were missing in the official packages.
I also just found this PR wich has been merged just 5 days ago wich makes life a bit more simple for compiling the tensile libs for 1010
https://github.com/ROCm/Tensile/pull/1862

Now that ROCM 6.1 is out, I tried it with the latest pytorch nightly (which still is built with Rocm 6.0) and this is the error I get when trying to run ComfyUI:
`
:3:hip_platform.cpp         :211 :<PHONE_NUMBER>1 us: [pid:31113 tid:0x7fa5a37fe700] __hipPopCallConfiguration: Returned hipSuccess :
:3:hip_module.cpp           :668 :<PHONE_NUMBER>7 us: [pid:31113 tid:0x7fa5a37fe700]  hipLaunchKernel ( 0x7fa9706d5550, {57,1,1}, {256,1,1}, 0x7fa5a37fc9a0, 0, stream: )
:3:hip_module.cpp           :669 :<PHONE_NUMBER>2 us: [pid:31113 tid:0x7fa5a37fe700] hipLaunchKernel: Returned hipErrorInvalidDeviceFunction :
:3:hip_error.cpp            :35  :<PHONE_NUMBER>5 us: [pid:31113 tid:0x7fa5a37fe700]  hipGetLastError (  )
:3:hip_error.cpp            :35  :<PHONE_NUMBER>7 us: [pid:31113 tid:0x7fa5a37fe700]  hipGetLastError (  )
:3:hip_device_runtime.cpp   :652 :<PHONE_NUMBER>2 us: [pid:31113 tid:0x7fa5a37fe700]  hipSetDevice ( 0 )
:3:hip_device_runtime.cpp   :656 :<PHONE_NUMBER>4 us: [pid:31113 tid:0x7fa5a37fe700] hipSetDevice: Returned hipSuccess :
:3:hip_device_runtime.cpp   :652 :<PHONE_NUMBER>4 us: [pid:31113 tid:0x7fa5a37fe700]  hipSetDevice ( 0 )
:3:hip_device_runtime.cpp   :656 :<PHONE_NUMBER>7 us: [pid:31113 tid:0x7fa5a37fe700] hipSetDevice: Returned hipSuccess :
!!! Exception during processing !!!
Traceback (most recent call last):
File "/home/aaron/Projects/personal/ComfyUI/execution.py", line 151, in recursive_execute
output_data, output_ui = get_output_data(obj, input_data_all)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/execution.py", line 81, in get_output_data
return_values = map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/execution.py", line 74, in map_node_over_list
results.append(getattr(obj, func)(**slice_dict(input_data_all, i)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/nodes.py", line 1378, in sample
return common_ksampler(model, noise_seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise=denoise, disable_noise=disable_noise, start_step=start_at_step, last_step=end_at_step, force_full_denoise=force_full_denoise)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/nodes.py", line 1314, in common_ksampler
samples = comfy.sample.sample(model, noise, steps, cfg, sampler_name, scheduler, positive, negative, latent_image,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/comfy/sample.py", line 37, in sample
samples = sampler.sample(noise, positive, negative, cfg=cfg, latent_image=latent_image, start_step=start_step, last_step=last_step, force_full_denoise=force_full_denoise, denoise_mask=noise_mask, sigmas=sigmas, callback=callback, disable_pbar=disable_pbar, seed=seed)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/comfy/samplers.py", line 755, in sample
return sample(self.model, noise, positive, negative, cfg, self.device, sampler, sigmas, self.model_options, latent_image=latent_image, denoise_mask=denoise_mask, callback=callback, disable_pbar=disable_pbar, seed=seed)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/comfy/samplers.py", line 657, in sample
return cfg_guider.sample(noise, latent_image, sampler, sigmas, denoise_mask, callback, disable_pbar, seed)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/comfy/samplers.py", line 644, in sample
output = self.inner_sample(noise, latent_image, device, sampler, sigmas, denoise_mask, callback, disable_pbar, seed)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/aaron/Projects/personal/ComfyUI/comfy/samplers.py", line 616, in inner_sample
if latent_image is not None and torch.count_nonzero(latent_image) > 0: #Don't shift the empty latent image.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: HIP error: invalid device function
Compile with TORCH_USE_HIP_DSA to enable device-side assertions.
Prompt executed in 6.49 seconds
settingHSA_OVERRIDE_GFX_VERSIONto10.3.0` still doesn't work it just maxes out the GPU clock and graphics pipeline but doesn't actually do anything.

I tried it again with the pytorch wheels from https://repo.radeon.com/rocm/manylinux/rocm-rel-6.1/ which have been compiled against ROCM 6.1 and they exhibit the same issue. Will try to compile pytorch from source next. In the meantime, here is the full output of the ComfyUI command
pytorch_error.log
Using HSA_OVERRIDE_GFX_VERSION=10.3.0 still just maxes out the GPU clock and doesn't actually do anything, while setting it to 11..0.0 or to 9.4.0 causes a GPU reset and locks my laptop up until I hard reboot it

Pytorch wasn't building because of https://github.com/ROCm/aotriton/issues/18 so I hacked it out and made pytorch compile without aotriton. This actually works and I'm able to run ComfyUI!
Notes:

Because of my dirty hacks pytorch does not have flash or memory efficient attention, so --use-pytorch-cross-attention can lead to HIP out of memory errors, subquadratic attention seems to work better.
Forcing fp16 works and gives proper images
Forcing fp32 also works
You don't need the HSA_OVERRIDE_GFX_VERSION anymore, it works with python main.py
Performance is slower than pytorch built against ROCM 5.2 but seems to be much more stable (no random GPU resets despite both the CPU and GPU running near the thermal throttle limit - so far)

I'm trying again with aotriton patched with the fix @xinyazhang suggested to see if that helps with easier/more straightforward building and possibly with performance,

That's amazing, could you share the pytorch files you've built? I'm trying to build on Debian Unstable, which has the tensile libraries compatible with gfx1010 by default, but I'm unable to build correctly (probably my fault in the setup process of the pytorch packages).

That's amazing, could you share the pytorch files you've built? I'm trying to build on Debian Unstable, which is compatible with gfx1010 by default using the rocm libraries, but I'm unable to build correctly (I've probably messed something up in the setup process of the pytorch packages).

I'll try to build a wheel from my pytorch setup

@daniandtheweb here you go: https://drive.google.com/file/d/1Y2kQ3bnoihs892tHOpXHkvfMQJH_gYa9/view?usp=drive_link
I'm not entirely sure if it will work for you. See my updated caveats

OK can confirm that the _gpu and the sde samplers do not work with these workarounds. Perhaps there is more stuff I'm overlooking

@Zakhrov try taking a look at this: https://lists.debian.org/debian-ai/2024/02/msg00164.html

As you might be aware from this documentation (https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html#supported-gpus), gfx1010 was not among the supported gfx architectures, and therefore, the behavior is undefined.  You can close this issue.

As you might be aware from this documentation (https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html#supported-gpus), gfx1010 was not among the supported gfx architectures, and therefore, the behavior is undefined. You can close this issue.

I'm well aware of the supported gfx architectures. What we are following is the advice given here: https://github.com/ROCm/ROCm/issues/1735#issuecomment-1128314977

Update: building rocSPARSE and comgr from source with @GZGavinZhao's patch available here: https://github.com/GZGavinZhao/ROCm-CompilerSupport/commit/3419d519fca9b03ba82dde037cc4600348a9d71d got the SDE ksamplers to work in ComfyUI. Performance is still slower than with ROCM 5.2 (probably because of missing MiOpen and Composable Kernels)

Ok in all seriousness, this issue should be resolved if ROCm/Tensile#1897 is cherry-picked into a release. I'll open an issue there. @Zakhrov if you really want to test gfx1010 support, you can try on Solus (the distro that I'm a maintainer for) with Docker. Note that the docker image is experimental/community-maintained so this shouldn't be used for anything serious, just for testing purposes:
# I personally use podman because I don't need to deal with sudo permission issues,
# but if you're more comfortable with Docker, replace `podman` with `sudo docker`
podman run -it --device=/dev/kfd --device=/dev/dri --group-add=video --group-add=render --group-add=nobody --ipc=host --cap-add=SYS_PTRACE --security-opt seccomp=unconfined silkeh/solus:devel bash

Inside the container, run the following to install PyTorch with ROCm support:
sudo eopkg ur && sudo eopkg up --ignore-comar -y # similar to sudo apt-get update && sudo apt-get upgrade
sudo eopkg it --ignore-comar pytorch python-torchaudio python-torchvision python-torchtext rocm-info -y

Now, you can proceed to run ComfyUI as normal. We didn't test against ComfyUI but we did test against Fooocus, so the process shoudl be similar. I assume you would need to create a venv to run ComfyUI. The only change you would have to make is that when creating the venv (e.g. python3 -m venv <rest-of-your-arguments>, you should add the flag --system-site-packages. With Fooocus, it looks something like this:
# Before everything, check that ROCm is not completely broken
rocminfo
# Assume you're already inside the Fooocus directory
python3 -m venv venv --system-site-packages
source venv/bin/activate
# You may get warnings about dependencies failed to be uninstalled/updated, but in practice we haven't found this to be problematic
pip3 install -r requirements.txt
# Now run Fooocus!

If you're familiar with Nix, after NixOS/nixpkgs#298388 is merged, you should also be able to use gfx101* GPUs with Nix. With PyTorch in particular, this may be a bit difficult due to how Nix handles Python packages, but stuff that are just binary executables like llama-cpp should work seamlessly with Nix.
Regarding composable_kernel, gfx1010 is not supported. At Solus, we have a patch that enables some sort of support for it, so you may get a little performance boost, though nobody on the Solus team has a GPU to verify this claim :sweat_smile:

Ok in all seriousness, this issue should be resolved if ROCm/Tensile#1897 is cherry-picked into a release. I'll open an issue there. @Zakhrov if you really want to test gfx1010 support, you can try on Solus (the distro that I'm a maintainer for) with Docker.
I'm currently on openSUSE 15.5 (which is compatible with packages built for SLES 15 SP5) and I run rocm on bare metal for the most part. Your patch works fine for everything except torchsde workloads - that needs comgr and rocsparse as well.
Regarding composable_kernel, gfx1010 is not supported. At Solus, we have a patch that enables some sort of support for it, so you may get a little performance boost, though nobody on the Solus team has a GPU to verify this claim 😅
That's what I manually patched in to composable_kernel as well. It just finished building, now have to try building MIOpen. I'll report back once I manage to build that

I'm currently on openSUSE 15.5 (which is compatible with packages built for SLES 15 SP5) and I run rocm on bare metal for the most part. Your patch works fine for everything except torchsde workloads - that needs comgr and rocsparse as well.

I'm surprised that you need to rebuild rocSPARSE. comgr is needed because of https://lists.debian.org/debian-ai/2024/02/msg00178.html. In short, ROCm 6.0 changed the behavior such that device code unbundling is handled by comgr (which was not patched), but previously the unbundling is done by clr (which was patched). The fix is to simply switch back the behavior to avoid patching comgr. I'm not sure why rocSPARSE is affected by this.

That's what I manually patched in to composable_kernel as well. It just finished building, now have to try building MIOpen. I'll report back once I manage to build that

I assume that you know you can pass the CMake flag -DGPU_TARGETS=gfx1010 to only build for your own GPU. This can save a ton of time.

Wait @Zakhrov are you not on gfx1010? The comgr patch is only for allowing gfx1011, gfx1012 to run code compiled against gfx1010. If you're already on gfx1010, the comgr patch shouldn't be needed.

Wait @Zakhrov are you not on gfx1010? The comgr patch is only for allowing gfx1011, gfx1012 to run code compiled against gfx1010. If you're already on gfx1010, the comgr patch shouldn't be needed.

I have a Radeon RX 5600M which shows as gfx1010 in rocminfo. Maybe I built rocBLAS wrong the first time around

Note that all the system packages on Ubuntu 24.04 have gfx1010 enabled. However, to use PyTorch you still need MIOpen. Once miopen and pytorch-rocm are packaged for Debian, I will port them to gfx1010 and set up a PPA for Ubuntu 24.04. With that said, performance will probably be quite poor as rocBLAS depends heavily on tuned assembly kernels for optimal performance (and nobody has done tuning for RDNA 1).

@DGdev91 Has your issue been resolved? If so, please close ticket. Thanks!

@DGdev91 Has your issue been resolved? If so, please close ticket. Thanks!

I can't really test it anymore, as i changed the gpu some months ago (i now have a 7900XT, working fine)
But according to @GZGavinZhao, the fix will be included in 6.2 release, so i was waiting for someone testing that version as soon it's released, before closing

Does anyone have an ETA for ROCm 6.2?

That's what I manually patched in to composable_kernel as well. It just finished building, now have to try building MIOpen. I'll report back once I manage to build that

@Zakhrov So were you able to build it with gfx1010, i could not build it, do i need ck to be already built?

Start the build process again. This can take an insanely long time, thanks to aotriton building triton from source, and compiling a whole bunch of HSA command objects for the MI200 and MI300X. Disabling USE_FLASH_ATTENTION will still cause it to be built so might as well keep it enabled. Stopping and starting the build process will cause all of those HSA command objects / HIP kernels to recompile, so be prepared for pytorch to take over an hour to build

there is already a PR going for that part https://github.com/pytorch/pytorch/issues/125230#issuecomment-2211893054

That's what I manually patched in to composable_kernel as well. It just finished building, now have to try building MIOpen. I'll report back once I manage to build that

@Zakhrov So were you able to build it with gfx1010, i could not build it (MIOpen), do i need ck to be already built?

Start the build process again. This can take an insanely long time, thanks to aotriton building triton from source, and compiling a whole bunch of HSA command objects for the MI200 and MI300X. Disabling USE_FLASH_ATTENTION will still cause it to be built so might as well keep it enabled. Stopping and starting the build process will cause all of those HSA command objects / HIP kernels to recompile, so be prepared for pytorch to take over an hour to build

there is already a PR going for that part pytorch/pytorch#125230 (comment)

Ok I actually managed to build the whole stack for gfx1010, with latest pytorch and all develop rocm
So I thought I would make an update on that. Thanks a lot anyway.

@waheedi Amazing, would it be possible to upload the pytorch wheels somewhere?

@waheedi Amazing, would it be possible to upload the pytorch wheels somewhere?

@veyn3141 Amazing what man :), the wheel on its own is not going to help, as that would be bundled with some libraries that you actually won't have with a standard rocm installation so I dont think it would be of any help.
But also I hit a blocker for building the last 200 tasks of torch and right now I'm a bit blocked. #3445

I have two 5500 XTs (the 8GB model to be specific, not the 4GB one) that I regularly run machine learning applications on both cards. This bug meant I had to compile affected ROCm versions and PyTorch from source to target the gfx1012 architecture to restore functionality.
I wasted many long hours patching pieces of code to make the build process successful from start to finish. I was relieved to find the PyTorch test suites were working without the need to set the HSA_OVERRIDE_GFX_VERSION environment variable.
I look forward to an official upstream fix sooner or later. Hopefully, this will save users time by not having to rebuild everything from scratch when a future problem occurs. Better a late fix than no fix.

Does anyone have an ETA for ROCm 6.2?

It has been released just about now. Whether it fixes the issue remains to be seen.

Replaced ollama compiled with vulkan support with rocm 6.2 and the 0.3.3 release binary. A quick benchmark went from ~18.7 token/s to 28 😎
time=2024-08-03T10:36:50.514-07:00 level=INFO source=payload.go:44 msg="Dynamic LLM libraries [cpu cpu_avx cpu_avx2 cuda_v11 rocm_v60102]"
time=2024-08-03T10:36:50.514-07:00 level=INFO source=gpu.go:205 msg="looking for compatible GPUs"
time=2024-08-03T10:36:50.520-07:00 level=INFO source=amd_linux.go:345 msg="amdgpu is supported" gpu=0 gpu_type=gfx1010
time=2024-08-03T10:36:50.520-07:00 level=INFO source=types.go:105 msg="inference compute" id=0 library=rocm compute=gfx1010 driver=6.8 name=1002:731f total="8.0 GiB" available="5.4 GiB"

I don't have the hardware to test right now, but since ROCm/Tensile#1897 is included in the 6.2 release, rocBLAS should now work fine on RDNA1 (gfx101*) hardware. This means that running LLMs such as llama-cpp should now work properly. Other ML workflows such as stable diffusion that need libraries other than rocBLAS (e.g. CK and MIOpen) may or may not work.

The official pytorch wheels don't work. I suppose they need to be built against rocm 6.2. I am rebuilding pytorch locally against my new rocm 6.2 installation

Building the pytorch wheels via docker/podman worked:
https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.2.0/install/3rd-party/pytorch-install.html#using-the-pytorch-upstream-docker-file

git clone https://github.com/pytorch/pytorch.git && git submodule update --init --recursive
apply the patches https://github.com/pytorch/pytorch/pull/132555/commits/0a53e6396902c075f547b8187e6457f82d6dc682
cd .ci/docker
export PYTORCH_ROCM_ARCH=gfx1010
./build.sh pytorch-linux-ubuntu22.04-rocm6.2-py3.10 -t rocm/pytorch:build_from_dockerfile
docker/podman run -it --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \ --user root --device=/dev/kfd --device=/dev/dri \--group-add video --ipc=host --shm-size 8G \-v ~/pytorch:/pytorch rocm/pytorch:build_from_dockerfile
export PYTORCH_ROCM_ARCH=gfx1010
.ci/pytorch/build.sh

Some tests fail when running. I've installed ComfyUI in the container and run a basic example. All the basic samplers except SDE ones seem to work fine. You also don't need to force fp32 anymore (saves some vram)

Has anyone gotten pytorch to build against 6.2 yet?
I've gotten most of the way through the process but I'm stuck at this bizarre linker failure:
FAILED: bin/c10_hip_HIPAssertionsTest_from_2_processes
: && /usr/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=1 -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_FBGEMM -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor -Werror=range-loop-construct -Werror=bool-operation -Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-strict-overflow -Wno-strict-aliasing -Wno-stringop-overflow -Wsuggest-override -Wno-psabi -Wno-error=pedantic -Wno-error=old-style-cast -Wno-missing-braces -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow -O3 -DNDEBUG -DNDEBUG -rdynamic -Wl,-rpath-link,/usr/lib/x86_64-linux-gnu     -Wl,--no-as-needed  -o bin/c10_hip_HIPAssertionsTest_from_2_processes  -Wl,-rpath,/home/will/src/pytorch/build/lib:/opt/rocm/lib:  lib/libc10_hip.so  lib/libc10.so  lib/libgtest_main.a  /opt/rocm/lib/libamdhip64.so  lib/libgtest.a && /usr/bin/cmake -E __run_co_compile --lwyu="ldd;-u;-r" --source=bin/c10_hip_HIPAssertionsTest_from_2_processes && :
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_import_shareable_handle@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_create@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_unmap@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_set_access@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_map@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_get_access@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_reserve@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_free@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_release@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_export_shareable_handle@ROCR_1'

The problem seems to be that those functions are defined in /opt/rocm/lib/libhsa-runtime64.so but I absolutely cannot figure out where or how these build command lines are being generated such that it's not included as a link target?

I've tried the 6.2 wheels from https://repo.radeon.com/rocm/manylinux/
They don't work, getting the same error as with 6.1
Seem's like you need to build it yourself with gpu arch set to gfx1010. I might try building the manywheel (so everyone can use it) docker container with rocm6.2 and gfx1010.

Building the pytorch wheels via docker/podman worked: https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.2.0/install/3rd-party/pytorch-install.html#using-the-pytorch-upstream-docker-file
1. `git clone https://github.com/pytorch/pytorch.git && git submodule update --init --recursive`

2. apply the patches [pytorch/pytorch@0a53e63](https://github.com/pytorch/pytorch/commit/0a53e6396902c075f547b8187e6457f82d6dc682)

3. `cd .ci/docker`

4. `export PYTORCH_ROCM_ARCH=gfx1010`

5. `./build.sh pytorch-linux-ubuntu22.04-rocm6.2-py3.10 -t rocm/pytorch:build_from_dockerfile` (had to change a lot of package names in the install shell scripts, the ones prefixed with 6.2.0 worked)

6. `docker/podman run -it --cap-add=SYS_PTRACE --security-opt seccomp=unconfined  --user root --device=/dev/kfd --device=/dev/dri --group-add video --ipc=host --shm-size 8G -v ~/pytorch:/pytorch rocm/pytorch:build_from_dockerfile`

7. `export PYTORCH_ROCM_ARCH=gfx1010`

8. `.ci/pytorch/build.sh`

Some tests fail when running. I've installed ComfyUI in the container and run a basic example. All the basic samplers except SDE ones seem to work fine. You also don't need to force fp32 anymore (saves some vram)

I've done more testing with this wheel. While it works, it often runs out of memory and it takes a very long time to initialize. The ones build on 5.2 still work better in my case

I've set up the ROCm 6.2 Ubuntu 24.04 apt repository in Docker to verify. My handcrafted C++ tests for HIPCC returned incorrect outputs on some libraries when compiling for my 5500 XT. Here are my test results:
Working:
rocBLAS/hipBLAS
rocFFT/hipFFT
MIOpen
MIGraphX
Not Working:
rocRAND/hipRAND
rocSPARSE/hipSPARSE
rocSOLVER/hipSOLVER
This is fixed by building and targeting the problematic libraries for the gfx101x architecture. Unfortunately, this is the best workaround one can do. Be prepared to wait many hours to complete and have patches ready in advance. This is a problem for the impatient and less technically oriented.

I got pytorch 2.4.0 to compile successfully from source on rocm 6.2, and it works pretty well. A lot less hassle than previously. However there are reports that the official nightly wheels of pytorch still don't work. I'm downloading it now in a fresh venv to confirm. I have a sneaking suspicion that we'll just need to manually copy the Tensile files into the venv for it to work

Confirmed. The pytorch official wheels still don't work with GFX1010. Looks like we are stuck with building pytorch from source for now

Yeah, it does not work.
https://github.com/pytorch/pytorch/issues/132570#issuecomment-2313071756

Has anyone gotten pytorch to build against 6.2 yet? (I'm on Ubuntu 24.04).
I've gotten most of the way through the process but I'm stuck at this bizarre linker failure:
FAILED: bin/c10_hip_HIPAssertionsTest_from_2_processes
: && /usr/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=1 -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_FBGEMM -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor -Werror=range-loop-construct -Werror=bool-operation -Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-strict-overflow -Wno-strict-aliasing -Wno-stringop-overflow -Wsuggest-override -Wno-psabi -Wno-error=pedantic -Wno-error=old-style-cast -Wno-missing-braces -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow -O3 -DNDEBUG -DNDEBUG -rdynamic -Wl,-rpath-link,/usr/lib/x86_64-linux-gnu     -Wl,--no-as-needed  -o bin/c10_hip_HIPAssertionsTest_from_2_processes  -Wl,-rpath,/home/will/src/pytorch/build/lib:/opt/rocm/lib:  lib/libc10_hip.so  lib/libc10.so  lib/libgtest_main.a  /opt/rocm/lib/libamdhip64.so  lib/libgtest.a && /usr/bin/cmake -E __run_co_compile --lwyu="ldd;-u;-r" --source=bin/c10_hip_HIPAssertionsTest_from_2_processes && :
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_import_shareable_handle@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_create@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_unmap@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_set_access@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_map@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_get_access@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_reserve@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_free@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_release@ROCR_1'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_export_shareable_handle@ROCR_1'

The problem seems to be that those functions are defined in /opt/rocm/lib/libhsa-runtime64.so but I absolutely cannot figure out where or how these build command lines are being generated such that it's not included as a link target?
EDIT: By going through Pytorch and hacking the libhsa-runtime64.so path into all the tests and libs I was able to get it to build. But for my trouble I discovered that even if I just run the rocm-validation-suite on my XT 5700 I get a hard crash of the GPU (PyTorch also crashes). If anyone's got this hardware running, I'd be keen to know how - I'd really like to get to just having torch hanging around in my user python environment able to be used without all the drama.

Same problem:
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_import_shareable_handle@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_create@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_unmap@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_set_access@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_map@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_get_access@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_reserve@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_address_free@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_handle_release@ROCR_1'
/usr/bin/ld: /opt/rocm/lib/libamdhip64.so: undefined reference to `hsa_amd_vmem_export_shareable_handle@ROCR_1'

I checked libamdhip64.so with objdump:
root@drfxi:~# objdump -T /opt/rocm/lib/libamdhip64.so |grep hsa_amd_vmem
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_export_shareable_handle
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_import_shareable_handle
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_handle_release
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_unmap
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_get_access
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_handle_create
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_address_free
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_address_reserve
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_map
0000000000000000      DF *UND*<PHONE_NUMBER>000000 (ROCR_1)     hsa_amd_vmem_set_access

I was able to get the latest pytorch main code to build successfully. Also, no that aotriton is pre-built, the compilation time  is much faster.

Thanks to all of you who have contributed to the discussion here. As has been stated previously, RDNA1 is not, and has never been officially supported by ROCm.
We appreciate your effort in finding workarounds to create a semblance of support for older cards outside our support matrix - I admire your resolve and the contributions you've made to the ROCm community. However, as has been stated previously in this thread, this issue is beyond our capability to definitively close and support - the nature of unsupported hardware is that it will continue to slip behind the breakthroughs in the ML space - and we must draw the line somewhere.
I will be converting this issue in particular to a discussion, as it has evolved from a specific issue to be solved into a discussion on the state of ROCm on gfx101X.
You are welcome to file new specific issues when you encounter broken components, and we will try to address those issues to some extent, even if they fall outside our support matrix. Unfortunately, some of those issues will not be resolvable, whether due to hardware differences, lower-level driver support, or the magnitude of changes that would be required to "enable" new software to run on unsupported hardware (we do have to draw the line somewhere!), but we'll do our best to resolve what we can, and collaborate with the community to find fixes.


Add ATC

This PR adds complete ATC decoding and encoding to the library.
Also included are tests for the 3 different variations of ATC.
This refers to issue #17 .

Nice stuff as always. I left some comments for you. The more generic bc4block thing is like an extra wish, but it would be nice.

Nice stuff as always. I left some comments for you. The more generic bc4block thing is like an extra wish, but it would be nice.

I actually don't know where this conflict comes from now, maybe it has to do with PR #22 ?

I actually don't know where this conflict comes from now, maybe it has to do with PR #22 ?

I actually don't know where this conflict comes from now, maybe it has to do with PR #22 ?

I can check. I didn't merge 22 yet so it's not that. I did push some small stuff to master today.

I actually don't know where this conflict comes from now, maybe it has to do with PR #22 ?

I can check. I didn't merge 22 yet so it's not that. I did push some small stuff to master today.

I like the new Bc4ComponentBlock. It's pretty much what I imagined it could be.
Minor thing, some refactoring seemed to change every comment with "Encode" to "EncodeBlock" maybe it was intentional though.

I like the new Bc4ComponentBlock. It's pretty much what I imagined it could be.
Minor thing, some refactoring seemed to change every comment with "Encode" to "EncodeBlock" maybe it was intentional though.

I think I resolved the conflict. The diff was just very confused while nothing of signifigance was actually conflicting.
I used the web-editor so can you check if it still compiles and tests pass?

I think I resolved the conflict. The diff was just very confused while nothing of signifigance was actually conflicting.
I used the web-editor so can you check if it still compiles and tests pass?

Ok nvm it was just a minor issue with the new Bc5 tests. It's fixed now.

Ok nvm it was just a minor issue with the new Bc5 tests. It's fixed now.

I will check the BcEncoder against my local changes and make a backup before pulling your changes.

I will check the BcEncoder against my local changes and make a backup before pulling your changes.

Alright, the changes look good. If there is nothing else, this PR seems to be mergable.

Alright, the changes look good. If there is nothing else, this PR seems to be mergable.


Unable to install from scoop

I visit https://beavernotes.com/#/Packages and click Scoop than on step #2 I get error:

also just noticed, for some reason it's not on website, https://scoop.sh/#/apps?q=beaver+notes
maybe find a way to get this posted on there if you wanted

Thanks for the feedback! I've changed the hashes for both files and performed a health check on my Windows 11 installation, and everything seems to work fine now. I also plan to implement automatic health checks for the Scoop repo to ensure this won't happen again. About availability on scoop.sh, we are not in the official repos. However, if you disable the 'official repos only' filter, you should see us there. We decided to have our own repo instead of using the official one for the sake of efficiency as it allows us to solve issues like this quickly.


Improve readme

This PR contains some minor changes to the client API. Internal functions are now (private) static methods of the API class.
Also #toString and #fromString methods have been removed as export/import should be the preferred method for dealing with serialization.

ACK


Promises polyfill does not support chaining then and catch

VSCode Version: 1.28.0
OS Version: Debian GNU/Linux buster/sid , Linux 4.16.0-2-amd64 1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux

Steps to Reproduce:
There is a Promise polyfill (class PolyfillPromise) defined in vscode/src/vs/base/common/winjs.polyfill.promise.ts. The comments say A polyfill for the native promises, but the then and catch methods do not support chaining, eg.
PolyfillPromise.resolve(1).then(function(x){return x+1}).then(function(x){console.log("Result is " + x)})

will print Result is undefined (it should print Result is 2).
Chaining is a very common operation with Promises. IE11 does not have native promises, so it uses the polyfill. This results in the ESM build of https://github.com/Microsoft/monaco-editor not working in IE11, as webpack uses Promises for dynamic imports.

wow - that is pretty obvious thing for us to miss...

Verfied via code review


Implement Eloquent ORM and refactor DB access

Implement the Eloquent ORM for database management and refactor DB access in the API.
composer require illuminate/database

Implementation completed in Branch #85-implement-eloquent-orm. Documentation needs to be updated.

Completed in PR #130


Use domain instead of name in reserved domain example

name has been deprecated in favor of domain

Ah, I missed https://github.com/ngrok/ngrok-api-rs/pull/7 but the build didn't pass. I'll update this example as well to use a FQDN.


[tool_crash] ProcessException: Dizin adı geçersiz. Command: C:\src\flutter\bin\cache\dart-sdk\bin\pub.BAT, OS error code: 267

Command
flutter doctor

Steps to Reproduce

...
...
...

Logs
ProcessException: Dizin adı geçersiz.
Command: C:\src\flutter\bin\cache\dart-sdk\bin\pub.BAT, OS error code: 267
#0      _ProcessImpl._start (dart:io-patch/process_patch.dart:390:33)
#1      Process.start (dart:io-patch/process_patch.dart:36:20)
#2      LocalProcessManager.start (package:process/src/interface/local_process_manager.dart:44:22)
#3      ErrorHandlingProcessManager.start.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:664:24)
#4      _run (package:flutter_tools/src/base/error_handling_io.dart:544:20)
#5      ErrorHandlingProcessManager.start (package:flutter_tools/src/base/error_handling_io.dart:663:12)
#6      _DefaultProcessUtils.start (package:flutter_tools/src/base/process.dart:425:28)
#7      _DefaultProcessUtils.stream (package:flutter_tools/src/base/process.dart:444:35)
#8      _DefaultPub.batch (package:flutter_tools/src/dart/pub.dart:285:34)
<asynchronous suspension>
#9      _DefaultPub.get (package:flutter_tools/src/dart/pub.dart:225:7)
<asynchronous suspension>
#10     PubDependencies.update (package:flutter_tools/src/flutter_cache.dart:121:5)
<asynchronous suspension>
#11     Cache.updateAll (package:flutter_tools/src/cache.dart:546:9)
<asynchronous suspension>
#12     FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:1143:7)
<asynchronous suspension>
#13     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1043:27)
<asynchronous suspension>
#14     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#15     CommandRunner.runCommand (package:args/command_runner.dart:196:13)
<asynchronous suspension>
#16     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:284:9)

[✓] Flutter (Channel stable, 2.2.2, on Microsoft Windows [Version 10.0.19042.1052], locale tr-TR)
    • Flutter version 2.2.2 at C:\src\flutter
    • Framework revision d79295af24 (7 days ago), 2021-06-11 08:56:01 -0700
    • Engine revision 91c9fc8fe0
    • Dart version 2.13.3

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\47eyu\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Android Studio (version 4.1.0)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[✓] VS Code (version 1.56.0)
    • VS Code at C:\Users\47eyu\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (2 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 91.0.4472.106
    • Edge (web)   • edge   • web-javascript • Microsoft Edge 91.0.864.48

! Doctor found issues in 1 category.

Flutter Application Metadata
No pubspec in working directory.

Closing this as duplicate of https://github.com/flutter/flutter/issues/80418


Fix non rails worker starting on podified

The current_pods Concurrent::Hash doesn't have the full pod object so we have to move the logic for checking if a pod is running down into save_pod
WIP pending tests covering more of these methods specifically sync_starting_workers

@agrare Is this ready?  (I still see WIP comment in the OP, so I wasn't sure)

@jrafanie Please also review.

Yeah I added the specs mentioned in the description

@agrare When we discussed, we talked about maybe treating all workers like non-rails workers, and removing the logic from run_single_worker.  Is that a future thing and this is tactical, or did you go in a different direction?

When we discussed, we talked about maybe treating all workers like non-rails workers, and removing the logic from run_single_worker. Is that a future thing and this is tactical, or did you go in a different direction?

I found this issue while working on that, I have another PR that is built on this.

Hm the spec failures are green locally, wonder if something in another plugin broke master

That's very weird, I just restarted this without changing any commits and it is green now :shrug:

LGTM - would like another set of eyes - @jrafanie ?

LGTM, just a minor question above.


[FEATURE] Post Delete feature

Description
We can delete any post by id through firebase cloud firestore delete request
for example = { const res = await db.collection('posts').doc('0DJEyHXRk6b4yyym3NYC').delete(); }
Can we try to implement this in our web application?
Ps: Only post creator should be able to delete his post.
Screenshots
No response
Additional information
No response

@narayan954  Can you please assign this issue to me?

sure, go ahead @tanishk-23

I have implemented the post delete feature but i want some information regarding database schemas so that i can check whether a user can delete the post or not?

okay sure @tanishk-23 , I think I should give you a glimpse of the current firestore db

would this do?

@narayan954 I think there should be user id associated with the post so that we can check whether user can delete it or not

posts do have an id attribute, as they are mapped with ids (line 116 of app.jsx). You can access/delete any post directly by id from firebase firestore. I hope this helps.


Fix date picker opened undeline for native shdow

This change is

 (as also discussed live and on Skype)

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from the review on Reviewable.io


CRYPTO-27: Sync Javadoc of stream in stream package

https://issues.apache.org/jira/browse/CRYPTO-27  Sync Javadoc of stream in stream package

+1

Thank @dianfu for your review.


Why is this "my name is arjun" considered as PromptInjection?

input: {   "prompt": "my name is arjun",   "scanners_suppress": [         "BanCode",         "BanCompetitors",         "BanSubstrings",         "BanTopics",         "Code",         "Secrets",         "TokenLimit",         "Toxicity"     ] }
output:
{     "is_valid": false,     "scanners": {         "Anonymize": 1.0,         "PromptInjection": 1.0     },     "sanitized_prompt": "my name is [REDACTED_PERSON_3][REDACTED_PERSON_4][REDACTED_PERSON_5]" }
API endpoint: http://<IP_ADDRESS>:8000/analyze/prompt

Hey @shivably , I think the reason is that it redacts before sending it to the prompt injection model for scanning. My recommendation is to put Anonymize scanner at the end, so it scans the real prompt.
Also, there is /scan/prompt endpoint which doesn't redact but just analyzes


Submit related projects in NOTICE.

@michaelsembwever :
I add the NOTICE file, which includes the related projects in distribution. You can find many dependencies in our project is provided only, so I did't list them all, we just instrument them, not using them.
FYI @hanahmily you need to create the same NOTICE file in incubator-skywalking-ui repository too.
CC @apache/skywalking-committers

@michaelsembwever The season I didn't add license, is because the two examples don't include that, https://github.com/apache/cassandra/blob/trunk/NOTICE.txt and https://github.com/apache/tiles/blob/trunk/NOTICE.txt .
But anyway, I have added them already. :)

Coverage remained the same at 23.08% when pulling 585e59a12ecd8d5902dee01f673bcb156b30310b on wusheng/add-notice into 8a3c9a0bd170d64855d9112d0a866f8f7b079ac4 on master.

Coverage remained the same at 23.08% when pulling 585e59a12ecd8d5902dee01f673bcb156b30310b on wusheng/add-notice into 8a3c9a0bd170d64855d9112d0a866f8f7b079ac4 on master.

looks good! thanks @wu-sheng

Coverage remained the same at 23.077% when pulling 62ff02bfa0f38ebbed129f2e786b56407602d5d7 on wusheng/add-notice into 40df96089eb5ab27fc057dfd0006e0f9af677b8c on master.


chore(deps): update novnc to 1.5.0

During a regular update of an unrelated package, @novnc/novnc got updated to 1.5.0, this seems to be expected as even with ^1.5.0 1.*.* might be updated while with ~1.3.0 only 1.3.X can be updated (bug fixes).
It would be nice if there could be a new react-console release which made it more restricted to ~1.3.0 to unblock or merging this PR. I've tested it on cockpit-machines and a quick some test seems to work fine.
https://github.com/cockpit-project/cockpit-machines/pull/1692

So turns out this was an intentional change in https://github.com/novnc/noVNC/commit/b35cf6dd1253142267f68f052986d0560f7a495c

I am a bit clueless about the typescript error, the previous version but it never annotated any types.


Create tool to benchmark Bicep compilation

Create tool to benchmark Bicep compilation. I've only added a single benchmark for now, but the goal is to make this easy to extend in the future for new benchmarks (for example, individual benchmarks per linter rule, benchmarking some of the LSP internals).
This makes it easy to jump into perf analysis using https://www.speedscope.app/ - for example, in the below, we can see the NoUnusedVariablesRule linter rule alone taking >40% of the total time to generate diagnostics for a compilation:

Microsoft Reviewers: Open in CodeFlow

This is awesome - Is this basically the instructions? https://github.com/jlfwong/speedscope/wiki/Importing-from-.NET-Core

This is awesome - Is this basically the instructions? https://github.com/jlfwong/speedscope/wiki/Importing-from-.NET-Core

It's actually even easier than that - if you run the command listed here: https://github.com/Azure/bicep/tree/main/src/Bicep.Tools.Benchmark#compilation, it'll output a file in speedscope format - you then just need to go to https://www.speedscope.app/ and load it.


notify: assign timer to message

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
notify
Description
https://github.com/przepompownia/mini-ui-messages-example in the current form shows (normal n and search_count messages) that updating existing message it does not delay the moment of its disappearance.
The example still uses the callback returned by make_notify() - I modified it like in #1341 but it still uses vim.defer_fn() to remove the message. The timer returned is not assigned anywhere so we lose control over the extension of the life of such message.
Probably we need to

create msg.rm_timer with remove callback to the message,
on update call msg.rm_timer:again(),
msg.rm_timer:stop(); msg.rm_timer = nil on remove().

Thanks for the suggestion!
I don't think it is necessary to make notification API more complicated in this case. There are two notification "layers" at play here:

Notifications produced by the output of make_notify() are essentially added and then deleted after configurable delay. They are not meant to be updated: show immediately and hide after later. It should be not be more complicated (unless documented vim.notify interface changes).
Notifications managed by lower level add(), update(), remove(). Those are specifically designed to be a public interface for users to micromanage notifications without the need to deal with how they are displayed.

I believe going the second route is what should be preferable here. I.e. manually add, update, and remove notifications based on custom logic (including prolonging time until removal if update was made).
Closing as not planned.


use com.google.code.findbugs:annotations instead of com.google.code.findbugs:jsr305

As noted at https://github.com/facebook/facebook-oss-pom/blob/master/pom.xml#L331-L336, bad things happen when :annotations and :jsr305 are both incorporated into the same project.
How do you feel about switching to :annotations to make it less dependency-error-prone to incorporate com.github.rholder:guava-retrying into a project?

I understand that :annotations is a superset of :jsr305, but one could just as well make the argument in the opposite direction. Our projects only use :jsr305, so this change would not be beneficial for us.
Note that the dependency checker can be "helped" in two ways:

By excluding the unwanted upstream dependency. (This is the approach facebook-oss-pom takes.)
By reordering dependencies. (Thereby effectively reordering the classpath.)

Alternative suggestion: have guava-retrying declare the :jsr305 dependency as provided. We do this in our projects. This way dowstream dependencies can freely select between :annotations and :jsr305, or even omit both (source).

Looks like a wrong runtime dependency https://github.com/rholder/guava-retrying/blob/master/build.gradle#L85

(Closing as wontfix)


Updated to Swift 3.0 Snapshot 04-25

Small changes, but will require a minor version bump as they're not backwards compatible.

Looks good to me 👍

@LoganWright CI passed, merge if happy

@czechboy0 does Hummingbird need to update?

Not as far as I know, only warnings upstream.

No, Hummingbird is fine. I think there are warnings from C7, but we can fix the warnings in a patch probably?

Awesome, thanks @czechboy0.
We upped our dependencies with CryptoKitten, so that makes me think this will need a minor bump.

@tannernelson Does that mean I need to change something? I thought only a git tag will be affected.

Nope you're good. Looks like we'll tag this as 0.7.


Admin does not want users who are not allowed to use maintenance mode to login at all

One place to check for maint mode is initial connection for a client:
Meteor.onConnection(callback) http://docs.meteor.com/#/full/meteor_onconnection

Some possible solutions for the communication architecture:
https://github.com/raix/Meteor-EventDDP
https://atmospherejs.com/gfk/notifications