Inference SVS

Hello! Great job! I would like to know a few things. Interested in SVS (POPCS)

Can you tell me about inference? What files are used for inferencing? What's the recipe? How did you manage to repeat the melody (notes) if midi is not used?
Can I perform inference for English? What can I do about it? I understand that the accent will remain Chinese. Are you planning further work for other languages?

https://github.com/MoonInTheRiver/DiffSinger/blob/master/docs/README-SVS.md

when inference use phoneme，there is an error "can't convert np.ndarray of type numpy.str_ ........."

we have done exactly that and get this error when running the SVS inference:
Traceback (most recent call last):
File "inference/svs/ds_e2e.py", line 71, in
DiffSingerE2EInfer.example_run(c)
File "/media/wonder/6AF274CCF2749E4F/Wayne/DiffSinger/inference/svs/base_svs_infer.py", line 240, in example_run
infer_ins = cls(hparams)
File "/media/wonder/6AF274CCF2749E4F/Wayne/DiffSinger/inference/svs/base_svs_infer.py", line 35, in init
self.model = self.build_model()
File "inference/svs/ds_e2e.py", line 26, in build_model
load_ckpt(model, hparams['work_dir'], 'model')
File "/media/wonder/6AF274CCF2749E4F/Wayne/DiffSinger/utils/init.py", line 202, in load_ckpt
cur_model.load_state_dict(state_dict, strict=strict)
File "/home/wonder/anaconda3/envs/diffsinger_test/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1497, in load_state_dict
raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for GaussianDiffusion:
size mismatch for fs2.encoder_embed_tokens.weight: copying a param with shape torch.Size([72, 256]) from checkpoint, the shape in current model is torch.Size([64, 256]).
size mismatch for fs2.encoder.embed_tokens.weight: copying a param with shape torch.Size([72, 256]) from checkpoint, the shape in current model is torch.Size([64, 256]).
[72, 256] is from retraining with our own EN dataset.  We don't know where this current model is torch.Size([64, 256]) is coming from. any tips?

@michaellin99999  Hello, have you done that job yet?


TypeError: init() got an unexpected keyword argument 'locale'

Happens with latest (0.14.4) version:
In [1]: import arrow

In [2]: arrow.get("2010", "YYYY", locale="fr_FR")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-a09819f3b7b0> in <module>
----> 1 arrow.get("2010", "YYYY", locale="fr_FR")

lib/python3.6/site-packages/arrow/api.py in get(*args, **kwargs)
     19     """
     20
---> 21     return _factory.get(*args, **kwargs)
     22
     23

lib/python3.6/site-packages/arrow/factory.py in get(self, *args, **kwargs)
    261         # 3+ args -> datetime-like via constructor.
    262         else:
--> 263             return self.type(*args, **kwargs)
    264
    265     def utcnow(self):

TypeError: __init__() got an unexpected keyword argument 'locale'

In [3]: arrow.__version__
Out[3]: '0.14.4'

Used to work with previous version. This is not mentioned in the breaking changes, so I assume it's a bug?

Offending line:
locale = kwargs.get("locale", "en_us")

You probably want to pop instead.

Let me write a PR for that.

Done, let me know if this looks good to merge?

We have pushed 0.14.5 to fix this regression. Thanks!


[Target Info] Compute resource-directory relative to the SDK on non-Darwin targets

Since the new driver uses -print-target-info for the resource directory and the legacy C++ driver used the logic in getResourceDirPath(), mimic that logic now in the print-target-info job itself.

@swift-ci test

@swift-ci test macOS platform

Anything holding this up, @artemcm?
The new cross-compilation doc @compnerd wrote up in #73581 is wrong with the new swift-driver as long as this issue is not fixed, ie the Swift compiler won't even look in -sdk for the Swift SDK overlay, whereas it long has with the legacy Driver as I demonstrated in apple/swift-driver#1562.

@swift-ci test

@swift-ci test

@swift-ci Please Build Toolchain Windows Platform

@swift-ci test

This doesn't work for Android, where the toolchain contains Swift resources, and SDK has the Swift runtime and swiftrt.o. With this patch, swift is unable to find the Clang builtins headers

This doesn't work for Android, where the toolchain contains Swift resources, and SDK has the Swift runtime and swiftrt.o.

That doesn't make any sense: can you clarify how you are building, ie what paths have what? It sounds like you are using a highly non-standard layout.

We expect a file like swiftrt.o and all the SOs to be in the SDK.
However, the compiler and it's resource dir, with the clang builtin headers as located in the toolchain, just like the compiler binary itself:
    Directory: S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\lib\swift

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         4/26/2024  10:14 AM                clang
d-----          7/9/2024  10:22 AM                host
d-----         4/26/2024  10:14 AM                migrator
d-----         4/26/2024  10:41 AM                pm
d-----         4/26/2024  10:14 AM                swiftToCxx
d-----          7/9/2024  11:28 AM                windows
d-----          6/6/2024  10:15 AM                _InternalSwiftScan
d-----         4/26/2024  10:14 AM                _InternalSwiftStaticMirror

This layout is somewhat similar to Darwin, where the standard library is separated out and is in the SDK as opposed to the toolchain itself (except for things like pre-compiled modules).
This is also how the windows SDK is separated out from the toolchain as well.

We expect a file like swiftrt.o and all the SOs to be in the SDK.

OK, the problem is not that, as other SDKs also have those Swift runtime files. The problem is that you're placing the shared libraries in the arch-specific directory usr\lib\swift\android\aarch64\, which is not how Unix platforms like linux or Android do it in the Swift compiler.
Why are you so particular about that, when you only have a single arch in that directory? I understand if you had multiple arches, but you don't.
I'm all for organizing the Swift runtime libraries for multiple arches on Unix platforms like that, as I submitted several pulls to move the Unix toolchain to that last year, #63782, but that approach was rejected, even when I said it could be a temporary measure.
The second difference in your non-standard layout is that you don't place the clang builtin headers in the SDK, as I think even Darwin platforms do. I understand that @compnerd wants to separate those out and change the meaning of -resource-dir to only refer to those "compiler resource" files, but I don't think you should start by shifting to that new model for a single SDK like this, ie the Android SDK on Windows.
I think it would be easier if we moved all SDKs to this new cross-compilation model at the same time, or at least all non-Darwin SDKs.
Try something: apply this pull and remove your patch from swiftlang/swift-driver#1560. Then, move all the lib* files from Android.sdk\usr\lib\swift\android\aarch64\ into Android.sdk\usr\lib\swift\android\ and link or move Toolchains\0.0.0+Asserts\usr\lib\swift\clang\ into Android.sdk\usr\lib\swift\. With those two changes, this pull should get everything building for you again, depending on the other contents of Android.sdk\usr\lib\swift\.

@finagolfin we only have a single directory there because it takes time to build. The installer will have all the architectures under the same directory, just like Windows already does with i686, x86_64, and aarch64.

The installer will have all the architectures under the same directory, just like Windows already does with i686, x86_64, and aarch64.

OK, makes sense, but what is your plan here? When I suggested a similar organization last year, it was rejected. We shouldn't special-case only the Android SDK on Windows to work that way, but all other Unix platforms don't.

Also, it is not a single SDK that we are changing to the resource headers being organised this way.

I haven't used the Windows toolchain, but I find this hard to believe based on the common driver logic. For example, when you compile natively for Windows, what is the -resource-dir flag passed to the swift-frontend by swift-driver set to? I have detailed that extensively for linux in swiftlang/swift-driver#1562.

OK, makes sense, but what is your plan here? When I suggested a similar organization last year, it was rejected. We shouldn't special-case only the Android SDK on Windows to work that way, but all other Unix platforms don't.

It has to be a gradual roll out. As we start building more of the platform SDKs, we will start fixing that. Right now the build setup makes this complicated to do as a generic, single shot application. As work progresses towards cleaning up the builds, we should be able to do this more readily across all the platforms.

I haven't used the Windows toolchain, but I find this hard to believe based on the common driver logic. For example, when you compile natively for Windows, what is the -resource-dir flag passed to the swift-frontend by swift-driver set to?

> swiftc -v -c reduced.swift -o NUL
compnerd.org Swift version 6.0-dev (LLVM 03696ed5c30fe6e, Swift c4b9e328ff84c4e)
Target: x86_64-unknown-windows-msvc
C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe -frontend -c -primary-file C:\Users\abdulras\AppData\Local\Temp\reduced.swift -target x86_64-unknown-windows-msvc -disable-objc-interop -sdk C:\Users\abdulras\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk -color-diagnostics -empty-abi-descriptor -Xcc -working-directory -Xcc C:\Users\abdulras\AppData\Local\Temp -resource-dir C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\lib\swift -module-name NUL -plugin-path C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin -plugin-path C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\local\bin -o C:\Users\abdulras\AppData\Local\Temp\NUL

It is set to the expected path - the resource directory under the toolchain.

It has to be a gradual roll out. As we start building more of the platform SDKs, we will start fixing that. Right now the build setup makes this complicated to do as a generic, single shot application.

IMO, a gradual roll-out will be much more complicated, but I could be wrong.

It is set to the expected path - the resource directory under the toolchain.

Thanks, I will try running the Windows toolchain myself to see how it does things differently.
@etcwilde, it appears that Darwin, Unix, and Windows currently place all these SDK/resource files in different layouts. If we're going to put together cross-compilation SDK bundles that work on all platforms, we're going to have to come up with a way to regularize all this. Rolling it out gradually with a bunch of special-case logic like in swiftlang/swift-driver#1560, for Android in that case, seems like it's going to get messy to me.
You're working on cross-compilation support, what do you think? Pinging @MaxDesiatov too.

I think we can move forward with this, indeed expand it as I laid out above. While it may not fix whatever additional issues Alex and Saleem have with their non-standard Android SDK, it does partially fix the swift-driver issue I originally raised of swift-driver not looking in -sdk for Swift modules and should be expanded more to emphasize usage of -sdk in swift-frontend.
Let me know what you all think.

@compnerd, you want to chime on what I wrote last week? This pull fixes the issue that the swift-driver does not currently look in -sdk for Swift core modules, which your new cross-compilation doc says will eventually be the primary way to compile Swift files. I suggested that we go further and update where swift-frontend looks for those core modules too.

Ping @artemcm, been six months since you proposed this fix and nothing has happened for the last couple months. If you don't have time for this, would you like me to take over the fix for the linked swift-driver issue?


database: Implement an in-memory DB for testing

LGTM, definitely need to make sure we get the DB interface missing time on last seen fixed.


Update pillar documentation reference

Re: https://github.com/kubic-project/salt/commit/408ab7a408ca6b41717d2072acf2b18f46c4a7e7

Jenkins was stuck because he rightfully didn't trust @bear454, I just unblocked the job. However the change is harmless so I'll force the merge of it

I don't know how to take that, @flavio  ;-)


Add Date ISO8601 Decoding from the FormURLDecoder

As per @tanner0101 mentioned in slack (https://codevapor.slack.com/archives/C4QRYJ6DD/p1523052418000152) the FormURLDecoder doesn't support decoding an ISO8601 Date String to a Date object.

Moved to the correct repo 👍


Replace our URL polyfill with the one from core-js

Fixes #10490.
@Snuffleupagus I have verified that everything still works in Firefox and Node.js, but I don't have access to IE and Edge to test those too. Do you perhaps have time to check if the viewer still works in IE and Edge with these commits applied?

/botio-linux preview

/botio test

Do you perhaps have time to check if the viewer still works in IE and Edge with these commits applied?

Unfortunately it does not work in IE11, with errors being thrown inside of https://github.com/zloirock/core-js/blob/a2b5534edae71a72ae297b85902b80d7a8e4ce40/packages/core-js/internals/internal-state.js#L16-L23

I just found https://github.com/zloirock/core-js/issues/514, which seems very much relevant here. Basically you'll need to add node_modules, or perhaps just node_modules[\\\/]core-js, to the babel-loader exclude option at https://github.com/mozilla/pdf.js/blob/d7c7f1555182ac19eb6261c0e035289b281f0d8c/gulpfile.js#L188
Looking at https://github.com/babel/babel-loader it seems to suggest excluding the entire node_modules directory, but I'm not sure if there'd be any side-effects from doing that!?
Quickly testing this PR locally with exclude: /(node_modules[\\\/]core-js|src[\\\/]core[\\\/](glyphlist|unicode))/, seemed to work, but it'd probably be a good idea to diff the built files with/without that to ensure that nothing looks trivially broken.

Thank you for helping out with testing this! I'll make the changes soon and make sure to diff the results. I'll start with node_modules[\\\/]core-js since that looks like the safest option given that there is no real need to exclude the entire node_modules folder. I think you're right about leaving the feature detection to core-js as well; I didn't know that it had that.

I have made the requested changes. I also made a diff of the built files of the generic target and nothing seemed trivially broken to me, but I would like to ask to test this in IE again just make sure that everything works as intended since excluding core-js would only really impact browsers like IE anyway as most of the polyfills we have left are for IE.

/botio-linux preview

/botio test


ROS 2 Cartographer ROS port

This PR is a port of cartographer_ros to ROS 2.  As you can see from the diff, it is actually quite a substantial change to cartographer_ros to make this work for ROS 2.
This code has been used in a few different robotics projects, so we know that at least the major parts of it work.  There are some parts of it that could use a cleanup, as they workaround problems that may or may not still exist.
As-is, this PR doesn't apply to master.  That's because this port was originally done against the 1.0.0 tag of this repository.  Moving it forward would be possible, but would likely require quite a bit of work.
I'm opening this PR as a starting point for the discussion on how to move this code into the upstream.  Some steps that seem obvious to me:

Update this to apply against master.
Create a ros2 branch for this to target

There is also the open question on whether the cartographer project is willing to take over maintenance of this port and maintain/release it for ROS 2 distributions going forward.
Finally, I'll note that I don't have too much of time to devote to this.  I'm doing this on discretionary time, so while I'm glad to do some simple work here, I won't have the time to do any major refactoring (like updating it to master).
Comments, questions, thoughts all welcome!

Thank you @clalancette for the PR!
If I understood correctly, we wanted to leave the master branch at this repository on ROS1 and merge the ROS2 into dedicated branches for this, i.e. create a dashing branch here and just push it into that branch.

If I understood correctly, we wanted to leave the master branch at this repository on ROS1 and merge the ROS2 into dedicated branches for this, i.e. create a dashing branch here and just push it into that branch.

Yep, that sounds good to me.  If you could please create a dashing branch for me, I can retarget this PR to that branch.

If I understood correctly, we wanted to leave the master branch at this repository on ROS1 and merge the ROS2 into dedicated branches for this, i.e. create a dashing branch here and just push it into that branch.

Yep, that sounds good to me. If you could please create a dashing branch for me, I can retarget this PR to that branch.

I created the dashing branch

I created the dashing branch

Thanks, appreciated.  I've retargeted the PR to dashing now.


[Feature] How to show file limits to a custom html area with a selector

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
I'm using filepondjs on my MVC project. I set file size validation plugin. I want to show dynamically when user add a new file, file limits like : 4 added / 5 limit
M (added by user) / N ( limit)
How can I do that?
Describe the solution you'd like
It can be an area in plugin to show limit of files count and added files from user count. So user can notice he/she can only add files via limit. They can see visually.
Describe alternatives you've considered
I have no alternatives for this.

You can use various FilePond events to update a label outside of FilePond. This is a question best asked on Stack Overflow.

You can use various FilePond events to update a label outside of FilePond. This is a question best asked on Stack Overflow.

I did not find any documentation about this subject. My problem is, after I active file size validation plugin, I try to upload more than N (limit) file, but when i click file explorer browser to add files to filepond, filepond reacts nothing. No event no error log no message.

` applyFilterChain('ADD_ITEMS', items, { dispatch: root.dispatch }).then(function(
queue
) {
// these files don't fit so stop here
if (exceedsMaxFiles(root, queue)) return false;
 // go
 root.dispatch('ADD_ITEMS', {
     items: queue,
     index: getDragIndex(root.ref.list, children, position),
     interactionMethod: InteractionMethod.DROP,
 });

});`
in filepond.js I think this code returns true or false. I cannot see where it gets error

The main problem here,

pond.on('addfile', (error, file) => {
    const currentFiles = pond.getFiles().length;

    // Dosya sayısı kontrolü
    if (currentFiles > 5) {
        alert('Dikkat! En fazla 5 dosya yükleyebilirsiniz!');
        // Hatalı dosyayı kaldır
        pond.removeFile(file.id);
    }
});

pond.on('processfiles', (files) => {
    // Dosya sayısı kontrolü
    if (files.length > 5) {
        alert('Dikkat! En fazla 5 dosya yükleyebilirsiniz!');
        // Hatalı dosyaları temizle
        pond.removeFiles(files);
    } else {
        // Dosya limiti aşılmadığında normal işleme devam et
        console.log('Dosyalar başarıyla işlendi:', files);
    }
});

these methods not working when I allow "allowFileSizeValidation" true.

const pond = FilePond.create(inputElement, {
    allowFileSizeValidation: true, // this
    maxFileSize: 10485760,
    maxFiles: 5
});


Allow newer versions of passenger to be installed

Hi All, I now that you are focusing on 3.0 now.  But, there is a breaking change for Passenger after version 5.0.19. Passenger changed the location of its native nginx module code from ext/nginx to src/nginx_module.  This change fixes that so that the latest versions of Passenger will not break the 2.7.x branch.
Thanks,
Josh

See #387 , already reported & fixed. Would be great to get this fixed, this is now the third pull request on this bug (I posted one too, and then closed it).

Note the other pull request #387 uses Chef::VersionConstraint, seems slightly safer than this one, that uses a regex to check the version number.

I see that it that would be happy to use #387 instead.  I have not seen movement on that for a while though.  Any chance to get that merged soon?

Thanks for opening this PR. With the merge of the chef_nginx codebase back into the nginx cookbook I believe it’s no longer necessary. I’m going to close this out now, and I hope you can check out the massive changes that landed on master here https://github.com/chef-cookbooks/nginx/pull/435


Global ray didn't load in MAMP environment

Hey there
first of all: thanks a ton for providing Ray and this package which makes debugging easy breezy! 🙌🏻
Problem encountered
The ray command (and dd) would not load as expected in my environment causing a "Call to undefined function ray()" error.
Environment
macOS Monterey (pretty fresh install), MAMP Pro, PHP 8.0.8, Wordpress PHP website
I have MAMP configured to publish it's PHP version to the command line:

Source of problem
It seems like ray added itself to the wrong PHP ini file:
🤙 Do you wish to install Ray globally? (Y/n) > Y
Updating PHP ini: /Applications/MAMP/bin/php/php8.0.8/conf/php.ini...

If I check which php.ini is used on my command line:
➜  ~ php -i | grep "Configuration File"
Configuration File (php.ini) Path => /Applications/MAMP/bin/php/php8.0.8/conf
Loaded Configuration File => /Library/Application Support/appsolute/MAMP PRO/conf/php8.0.8.ini

Solution to problem
I've copied the followingline that Global ray added also to the "/Library/Application Support/appsolute/MAMP PRO/conf/php8.0.8.ini" file:
auto_prepend_file = /Users/aaron/.composer/vendor/spatie/global-ray/src/scripts/global-ray-loader.php
After that it works like a charm.
Please reply if I can provide any other information.
Aaron

Hi @aaronmeder! Thanks for the detailed issue. I think we can offer a choice with different PHP ini files that have been found on the system during installation. For example:
🤙 Do you wish to install Ray globally? (Y/n) > Y

Choose a PHP ini file to install to:

- /Applications/MAMP/bin/php/php8.0.8/conf.ini
- /Library/Application Support/appsolute/MAMP PRO/conf/php8.0.8.ini <-

Let me see what I can put together 👍

I think we can offer a choice with different PHP ini files that have been found on the system during installation.

Thanks sounds great to me!
Maybe even add an "Add to all" option? Since global-ray seems to be about making it run everywhere that would be a helpful step to make sure it does run everywhere ;-)

That's a great idea @aaronmeder! Didn't think of that -- I'll definitely add that in 👍


ObjectOutliner: try outline alloc_refs in multiple iterations to handle multi-dimensional arrays

This allows to completely statically allocate multi-dimensional global arrays, like
var x = [[1, 2], [3, 4], [5, 6]]

@swift-ci test


[Bug] Unexpected reuse of payload instances in payload codec for specific workflow failure scenarios.

What are you really trying to do?

I'm writing a payload codec that attaches metadata to headers. I am noticing that for some specific workflow failure scenarios around ApplicationFailureException with Details objects, that under certain circumstances, the instance of the payload object passed to the payload codec is re-used from a previous payload.
Describe the bug

I have a very simple workflow that only contains an activity.
My sample activity always throws an ApplicationFailureException with a single details payload. My workflow just propagates the same exception and fails.
I believe there should be four payloads here in this scenario:

The workflow input.
The activity input.
The activity output (in this case failure details).
The workflow output (in this case failure details).

I am noticing that (what seems to be the same instance of) the payload that is being passed to the payload codec to encode both the failure from the activity, and the failure from the workflow.
I've created a payload codec implementation in MetadataExaminingPayloadCodec.cs that adds a uuid to the X-My-Metadata header in the payload metadata during encoding only if a value does not already exist on the payload, and during decoding, reads the value of the X-My-Metadata header in the payload metadata.
Minimal Reproduction

https://github.com/robcao/temporal-sdk-dotnet-payload-repro/tree/main
The reproduction runs as a NUnit test case for simplicity, and can be run by using the dotnet test command.
The output of the codec is as below. When trying to encode the payload for the workflow failure details, the payload being passed to the payload codec already has a X-My-Metadata header, indicating some sort of re-use.
  Standard Output Messages:
 Successfully added metadata 229a20b0-9b33-4053-b4b8-f3471b9cdae9...
 Now reading metadata 229a20b0-9b33-4053-b4b8-f3471b9cdae9...
 Successfully added metadata d5566faf-ce58-4917-92e5-86250da83fc8...
 Now reading metadata d5566faf-ce58-4917-92e5-86250da83fc8...
 Successfully added metadata 9fb8cb67-e8ec-41c8-b9b9-71ad6c639b95...
 Now reading metadata 9fb8cb67-e8ec-41c8-b9b9-71ad6c639b95...
 WARN: tried to add metadata, but metadata already exists with a value of 9fb8cb67-e8ec-41c8-b9b9-71ad6c639b95...
 Now reading metadata 9fb8cb67-e8ec-41c8-b9b9-71ad6c639b95...

Environment/Versions

OS and processor: Windows 10 Enterprise 10.0.19045 x64
Temporal Version: Temporal 1.22.5, sdk-dotnet 1.0.0
Are you using Docker or Kubernetes or building Temporal from source? No

Additional context
So far, I've only noticed this happening for this specific scenario around failure details, but I'm not sure if it can happen under any other scenarios.
I looked at the encryption sample, and I see that this implementation is wrapping the original payload as the data of a new payload.
 Task.FromResult<IReadOnlyCollection<Payload>>(payloads.Select(p =>
        {
            return new Payload()
            {
                Metadata =
                {
                    ["encoding"] = EncodingByteString,
                    ["encryption-key-id"] = keyIDByteString,
                },
                // TODO(cretz): Not clear here how to prevent copy
                Data = ByteString.CopyFrom(Encrypt(p.ToByteArray())),
            };
        }).ToList());

However, it's unclear in the documentation if this is actually necessary (or why if so).
This behavior is kind of strange.
If I change the workflow code to the below, the same problem is happening.
		[WorkflowRun]
		public async Task<WorkflowOutput> RunAsync(WorkflowInput input)
		{
			try
			{
				await Temporalio.Workflows.Workflow.ExecuteActivityAsync(
					() => Activities.FailureActivityWithDetails(new ActivityInput()),
					new()
					{
						StartToCloseTimeout = TimeSpan.FromMinutes(5),
					}).ConfigureAwait(true);
			}

			catch (ApplicationFailureException)
			{
				throw new NonRetryableWithDetailsException(new FailureDetails());
			}

			return new WorkflowOutput();
		}

However, if I modify the above code to catch a generic Exception, instead of an ApplicationFailureException, the payload instance no longer appears to be re-used.
		[WorkflowRun]
		public async Task<WorkflowOutput> RunAsync(WorkflowInput input)
		{
			try
			{
				await Temporalio.Workflows.Workflow.ExecuteActivityAsync(
					() => Activities.FailureActivityWithDetails(new ActivityInput()),
					new()
					{
						StartToCloseTimeout = TimeSpan.FromMinutes(5),
					}).ConfigureAwait(true);
			}

			catch (Exception)
			{
				throw new NonRetryableWithDetailsException(new FailureDetails());
			}

			return new WorkflowOutput();
		}

Your payload codec should not mutate the payload being passed in or try to maintain a reference to it in any way. Rather, you should always create a new payload. I will make a note to make this very clear in the codec documentation.
See how https://github.com/temporalio/samples-dotnet/blob/main/src/Encryption/Codec/EncryptionCodec.cs works by creating a new payload

Got it, thank you.
To be clear, when you say "you should always create a new payload", you do not mean just a deep clone via something like payload.Clone(), but rather setting the original payload (allocated into a new byte array) as the data of an outer payload wrapper?
new Payload()
            {
                Data = ByteString.CopyFrom(payload.ToByteArray()),
            };

Literally just always creating a new instance of the payload object. How you "wrap" or "convert" the other one into the payload is up to you. A "clone" is probably fine, though I usually recommend against that because you usually do not want all of the previous payload's metadata as your own. Rather usually you want to serialize/wrap the entire other payload into the data of the new one, and do the inverse on decode. But technically all that matters is that no fields in the parameter are mutated or referenced beyond the life of the method.


Shap values do not sum to model output - expected value for interventional TreeExplainer (v 0.35) [xgboost]

Hi @slundberg ,
I hope you are well. I was playing with the TreeExplainer and thought of checking the local accuracy property, which did not hold. I know previous issues were related to a tight tolerance in the assert_additivity method of TreeExplainer, but now this seems to happen silently (I only noticed this because I thought of checking myself).
I used the Census income classification with XGBoost example in your library to create a reproducible example. You can copy paste the code below in the Explain predictions section to reproduce the error.
import pandas as pd
from scipy.special import logit

print("Shap version", shap.__version__)
print("")
# prepare data
R=200     # background size
n_exp=50  # number of instances to explain
X_explain = X_test[:n_exp]
print("Explanation set shape:", X_explain.shape)
background_dataset = pd.DataFrame(X_train.iloc[:R, :])
print("Background set shape:", background_dataset.shape)

# explain some examples
new_explainer = shap.TreeExplainer(model, data=background_dataset)
explanations = new_explainer.shap_values(X_explain)

print("")
# basic expected value checks
print("Expected value", new_explainer.expected_value)
print("base score", params['base_score'])
check_expected = logit(model.predict(xgboost.DMatrix(background_dataset))).mean()
# check the expected value is the average predictn
assert np.abs(check_expected) - np.abs(new_explainer.expected_value) < 1e-4

print("")
# check local accuracy
actual = explanations.sum(1)
expected = logit(model.predict(xgboost.DMatrix(X_test[:n_exp]))) - new_explainer.expected_value
absolute_error = np.abs(actual - expected)
i_max = np.argmax(absolute_error)
relative_error = np.abs(100*(actual[i_max] - expected[i_max])/expected[i_max])
print("Max Absolute error: {}".format(absolute_error[i_max]))
print("Relative error: {} %.".format(np.round(relative_error, 4)))
new_explainer.assert_additivity(explanations, model.predict(xgboost.DMatrix(X_explain), output_margin=True))

This gives the following output:

Given that we are explaining the model in the margin space, we expect the local accuracy to hold exactly. Do you think this is an xbgoost specific error? To me, the error looks a bit large to be just a consequence of rounding. Any insights into this are much appreciated.
I should mention that other issues such as #887 #941, #903, #1096 and  #1105 seem to relate to the same issue.
UPDATE
I thought of checking what happens if we run this check at instance level. So I split the above background dataset and checked local accuracy, for every instance, across a range of references.
The two plots below are as expected, since the model output can vary singificantly with the reference.

Below, the absolute error computed from the above expected and actual sums is ploted:

You can find the code required to reproduce the error and my analysis in notebooks/tree_explainer here.

Try upgrading shap and xgboost. While the issue you report is real (on much larger data sets), I could not reproduce it (the assertion failure, i.e. "SHAPError, Additivity check failed...") using your example, slightly modified for reproducibility (and then for performance by moving to the GPU):
executed in 4.14s, finished 10:46:35 2021-07-13

Shap version 0.37.0
Xgboost version 1.4.2

Explanation set shape: (5000, 12)
Background set shape: (500, 12)

Expected value -2.6445464855397547
base score 0.24105497542997542

Max Absolute error: 3.191269934177399e-05
Relative error: 0.0004 %.

And the code I used to try to reproduce the issue (here: in vain, but the issue is real):
import pandas as pd
from scipy.special import logit
import shap
import xgboost

# load dataset
X,y = shap.datasets.adult()
X_display,y_display = shap.datasets.adult(display=True)

# create a train/test split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=7)
d_train = xgboost.DMatrix(X_train, label=y_train)
d_test = xgboost.DMatrix(X_test, label=y_test)

# train an xgboost model
params = {
    "eta": 0.01,
    "objective": "binary:logistic",
    "subsample": 0.5,
    "base_score": np.mean(y_train),
    "eval_metric": "logloss",
    "random_state": 123,
    "seed": 123,
    "nthread": 16
}
model = xgboost.train(params, d_train, 5000, evals = [(d_test, "test")], verbose_eval=100, early_stopping_rounds=20)

print("Shap version", shap.__version__)
print("Xgboost version", xgboost.__version__)
print("")
# prepare data
R=500     # background size
n_exp=5000  # number of instances to explain
X_explain = X_test[:n_exp]
print("Explanation set shape:", X_explain.shape)
background_dataset = pd.DataFrame(X_train.iloc[:R, :])
print("Background set shape:", background_dataset.shape)

# explain some examples
# new_explainer = shap.TreeExplainer(model, data=background_dataset)
new_explainer = shap.GPUTreeExplainer(model, data=background_dataset)
explanations = new_explainer.shap_values(X_explain)

print("")
# basic expected value checks
print("Expected value", new_explainer.expected_value)
print("base score", params['base_score'])
check_expected = logit(model.predict(xgboost.DMatrix(background_dataset))).mean()
# check the expected value is the average predictn
assert np.abs(check_expected) - np.abs(new_explainer.expected_value) < 1e-4

print("")
# check local accuracy
actual = explanations.sum(1)
expected = logit(model.predict(xgboost.DMatrix(X_test[:n_exp]))) - new_explainer.expected_value
absolute_error = np.abs(actual - expected)
i_max = np.argmax(absolute_error)
relative_error = np.abs(100*(actual[i_max] - expected[i_max])/expected[i_max])
print("Max Absolute error: {}".format(absolute_error[i_max]))
print("Relative error: {} %.".format(np.round(relative_error, 4)))
new_explainer.assert_additivity(explanations, model.predict(xgboost.DMatrix(X_explain), output_margin=True))

``


Installation Fails in Apple Silicon MacBook

Issue
I am new to Haskell and I cannot install iHaskell in my M1 Max  MacBook Pro. I followed the instruction on GitHub page and run stack install --fast . However, the error occurred
Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the following errors:

       [S-7011]
       While building package magic-1.1 (scroll up to its section to see the error) using:
       /Users/kachunpang/.stack/setup-exe-cache/aarch64-osx/Cabal-simple_SvXsv1f__<IP_ADDRESS>_ghc-9.2.7 --verbose=1 --builddir=.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS> configure --with-ghc=/Users/kachunpang/.ghcup/ghc/9.2.7/bin/ghc-9.2.7 --with-ghc-pkg=/Users/kachunpang/.ghcup/ghc/9.2.7/bin/ghc-pkg-9.2.7 --user --package-db=clear --package-db=global --package-db=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/pkgdb --libdir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/lib --bindir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/bin --datadir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/share [--libexecdir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/libexec](url) --sysconfdir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/etc --docdir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/doc/magic-1.1 --htmldir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/doc/magic-1.1 --haddockdir=/Users/kachunpang/.stack/snapshots/aarch64-osx/9b521a4e74c71bec9bd150662082f4f6c4c132473afe928bc1600cc0d5146c0a/9.2.7/doc/magic-1.1 --dependency=base=base-<IP_ADDRESS> --exact-configuration --ghc-option=-fhide-source-paths
       Process exited with code: ExitFailure 1

and the installation fails.
Expectation
The installation can be achieved by following the instruction on the GitHub.

Thanks for this error report. Can you include more information about what the actual error is? This line
While building package magic-1.1 (scroll up to its section to see the error) using:

seems to indicate an issue with the magic package. If you want to work around this, you can comment out the following line in stack.yaml: https://github.com/IHaskell/IHaskell/blob/af37a012597de5defb06f287fb4d5c7b37a8157b/stack.yaml#L16 and try to rebuild.

@vaibhavsagar  Thanks for the information. After struggling for a few hours, I found that the solution was to add path variables in the stack install --fast. For Apple Silicon and HomeBrew users, the brew directory locates at  /opt/homebrew/ and for stack to see pkg-config or libmagic, we need to add additional flags into the stack install command. This instruction was clearly stated on the Github page --extra-include-dirs ${HOMEBREW_PREFIX}/include --extra-lib-dirs ${HOMEBREW_PREFIX}/lib but I did not change the variable name ${HOMEBREW_PREFIX}. After changing it back to /opt/homebrew``` to works fine.

Hi, I'm running into a similar issue running on an Apple silicon macbook, with brew installed at /opt/homebrew.
I've ran:
stack install --fast --extra-include-dirs /opt/homebrew/include --extra-lib-dirs /opt/homebrew/lib

and got the following error:
Progress 9/43

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the following errors:

       [S-7011]
       While building package zeromq4-haskell-0.8.0 (scroll up to its section to see the
       error) using:
       /Users/atopos/.stack/setup-exe-cache/aarch64-osx/Cabal-simple_SvXsv1f__<IP_ADDRESS>_ghc-9.2.7 --verbose=1 --builddir=.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS> configure --with-ghc=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc --with-ghc-pkg=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc-pkg-9.2.7 --user --package-db=clear --package-db=global --package-db=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/pkgdb --libdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/lib --bindir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/bin --datadir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/share --libexecdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/libexec --sysconfdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/etc --docdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/zeromq4-haskell-0.8.0 --htmldir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/zeromq4-haskell-0.8.0 --haddockdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/zeromq4-haskell-0.8.0 --dependency=async=async-2.2.4-KzhLbRYpCCLJ5d8bnXQLq3 --dependency=base=base-<IP_ADDRESS> --dependency=bytestring=bytestring-<IP_ADDRESS> --dependency=containers=containers-<IP_ADDRESS> --dependency=exceptions=exceptions-0.10.4 --dependency=monad-control=monad-control-<IP_ADDRESS>-IfG0yl5JjlF5rUQ5Dk3FIi --dependency=semigroups=semigroups-0.20-Ataa94eSftS9PXhef7F53I --dependency=transformers=transformers-<IP_ADDRESS> --dependency=transformers-base=transformers-base-0.4.6-GkOrjcRVqoPGiyQnv0GZK0 --extra-include-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/include --extra-lib-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/lib --exact-configuration --ghc-option=-fhide-source-paths
       Process exited with code: ExitFailure 1

       [S-7011]
       While building package glib-<IP_ADDRESS> (scroll up to its section to see the error)
       using:
       /private/var/folders/m0/g9brxl8x7v11dl52g5l_m6c80000gn/T/stack-92d60fcb248edceb/glib-<IP_ADDRESS>/.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS>/setup/setup --verbose=1 --builddir=.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS> configure --with-ghc=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc --with-ghc-pkg=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc-pkg-9.2.7 --user --package-db=clear --package-db=global --package-db=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/pkgdb --libdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/lib --bindir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/bin --datadir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/share --libexecdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/libexec --sysconfdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/etc --docdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/glib-<IP_ADDRESS> --htmldir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/glib-<IP_ADDRESS> --haddockdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/glib-<IP_ADDRESS> --dependency=Cabal=Cabal-<IP_ADDRESS> --dependency=base=base-<IP_ADDRESS> --dependency=bytestring=bytestring-<IP_ADDRESS> --dependency=containers=containers-<IP_ADDRESS> --dependency=gtk2hs-buildtools=gtk2hs-buildtools-<IP_ADDRESS>-KSQ2LZPZjIS6m0yKzEHPDL --dependency=text=text-<IP_ADDRESS> --dependency=utf8-string=utf8-string-1.0.2-KOPUXETbFeRLoWT9IcwQzV -fclosure_signals --extra-include-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/include --extra-lib-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/lib --exact-configuration --ghc-option=-fhide-source-paths
       Process exited with code: ExitFailure 1

       [S-7011]
       While building package cairo-<IP_ADDRESS> (scroll up to its section to see the error)
       using:
       /private/var/folders/m0/g9brxl8x7v11dl52g5l_m6c80000gn/T/stack-92d60fcb248edceb/cairo-<IP_ADDRESS>/.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS>/setup/setup --verbose=1 --builddir=.stack-work/dist/aarch64-osx/Cabal-<IP_ADDRESS> configure --with-ghc=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc --with-ghc-pkg=/Users/atopos/.ghcup/ghc/9.2.7/bin/ghc-pkg-9.2.7 --user --package-db=clear --package-db=global --package-db=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/pkgdb --libdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/lib --bindir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/bin --datadir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/share --libexecdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/libexec --sysconfdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/etc --docdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/cairo-<IP_ADDRESS> --htmldir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/cairo-<IP_ADDRESS> --haddockdir=/Users/atopos/.stack/snapshots/aarch64-osx/276d6fe4dcd43880c05d29684f703559eec833b700fc7d322b2f7b6a131bf249/9.2.7/doc/cairo-<IP_ADDRESS> --dependency=Cabal=Cabal-<IP_ADDRESS> --dependency=array=array-<IP_ADDRESS> --dependency=base=base-<IP_ADDRESS> --dependency=bytestring=bytestring-<IP_ADDRESS> --dependency=gtk2hs-buildtools=gtk2hs-buildtools-<IP_ADDRESS>-KSQ2LZPZjIS6m0yKzEHPDL --dependency=mtl=mtl-2.2.2 --dependency=text=text-<IP_ADDRESS> --dependency=utf8-string=utf8-string-1.0.2-KOPUXETbFeRLoWT9IcwQzV -fcairo_pdf -fcairo_ps -fcairo_svg --extra-include-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/include --extra-lib-dirs=/Users/atopos/Software/IHaskell/$/opt/homebrew/lib --exact-configuration --ghc-option=-fhide-source-paths
       Process exited with code: ExitFailure 1

This seems to be an issue with your dependencies. Can you include the output that actually shows the build error?

@renzocom  Could you try stack install --fast --extra-include-dirs /opt/homebrew/include --extra-lib-dirs /opt/homebrew/lib ? I guess that correct command does not include $ symbol.


Installation instructions are circular

https://github.com/ROCm-Developer-Tools/HIP  , points to:
https://github.com/ROCm-Developer-Tools/HIP/blob/master/INSTALL.md
, but it actually doesn't tell what to install (i.e. what are names of debian/ubuntu packages), and instead points to:
http://gpuopen.com/getting-started-with-boltzmann-components-platforms-installation/
, which is an article that doesn't actual tell how to install it. (and is over 2 years old) and points to:
https://rocm.github.io/ROCmInstall.html
, but it doesn't really correctly specify how to install HIP.
There is a link to HIP there, which points to:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/tree/roc-1.9.x
Yet another repository?
It redirects eventually to:
https://github.com/ROCm-Developer-Tools/HIP/tree/roc-1.9.x
Madness.
The only thing about installation in the ROCmInstall.html, is rocm-dkms . Which (INCORRECTLY) depends on rocm-dev, which depends on hip_hcc (kind of correctly).
This should be pretty much reverse. I should just install hip-hcc, and it would pull needed dependencies (and suggest rocm-dkms), as it should be.

And document it here, in the project installation, not 4 links forward.
(It is really frustrating, to see such great software be so hard to use because fragmented and duplicated documentation and messed up packaging).

Hi @baryluk
Thank you for the report. You're absolutely right that our documentation could use improvement. This is pretty high on our todo list, and your reports are good input for focusing our efforts on the serious problems.
A lot of the documentation you're going through (e.g. the INSTALL.md for HIP that points to the gpuopen article) is somewhat old. At the time, we avoided just saying apt install hip_hcc because we needed users to install a great deal more software (including a fully custom monolithic Linux kernel). Things have improved since then (IMO) so we should probably revisit our various installations directions to clean them up in light of this. Now, if your kernel is new enough for your GPU, you should be able to just install user-level stuff using the command above to get a working HIP installation. If you are using an older kernel (or your kernel is not new enough to support your GPU -- or if you want some of the features offered by our driver) you may also need to install rock-dkms.
That being said, I believe that our packages do include a correct set of intra-ROCm dependencies to get HIP working on ROCm. (Setting aside your other reports on missing system-level dependencies that we hadn't sensitized due to testing on Ubuntu, where they were installed by default).
You mentioned that if we want a package that pulls dependencies, we should create a meta-package. Both rocm-dkms and rocm-dev are such the meta-packages. The former is meant to install both the kernel- and user-mode ROCm software, while the latter is meant to install just the user-mode ROCm software. The latter exists because, as mentioned above, you may not want or need to install the ROCK kernel driver on your OS but you still want the user-level "ROCm".
# rocm-dkms is a meta-package that installs the both the ROCK
# kernel driver (rock-dkms) and ROCm user-level components
# (the rocm-dev meta-package)
# rocm-dev is a meta-package that installs the user-level ROCm
# components (though not libraries. Many of those can be installed
# with the rocm-libs meta-package)
rocm-dkms
 |-- rock-dkms
 |-- rocm-dev
      |--hsa-rocr-dev
      |--hsa-ext-rocr-dev
      |--rocm-device-libs
      |--rocm-utils
      |--hcc
      |--hip_base
      |--hip_doc
      |--hip_hcc
      |--hip_samples
      |--rocm-smi
      |--hsakmt-roct
      |--hsakmt-roct-dev
      |--hsa-amd-aqlprofile
      |--comgr
      |--rocr_debug_agent

That said, if you don't want to directly install HIP for ROCm, you're right that hip_hcc is the package to do so. Following its dependencies, this should get the appropriate user-level software in place. It will not install rock-dkms as that is not a strict dependence of any of the user-level software.
hip_hcc                       # The version of HIP which compiles HIP code for ROCm
 |--hip_base
 |--hcc                       # It uses HCC to do this compilation
      |--hsa-rocr-dev         # The ROCr runtime
          |--hsakmt-roct-dev  # Headers for the Thunk kernel interface
              |--hsakmt-roct  # Thunk kernel interface
      |--hsa-ext-rocr-dev     # Closed source libraries for the ROCr runtime
      |--rocm-utils           # Meta-package for ROCM user-land "utilities"
          |--romcminfo        # Needed by HCC for rocm_agent_enumerator
          |--rocm-clang-ocl   # Not strictly needed by HCC

As such, this should install HIP, HCC, ROCr, the Thunk, and rocminfo. I believe this is a minimum but functional set of software to run HIP so long as you have a properly working kernel driver (whether upstream, or with a separately installed rock-dkms). I'll admit that HCC should probably depend directly on rocminfo instead of rocm-utils. I've been discussing such a patch internally already, in fact. :)

I see. I was confused what the rocm-dkms even is.  This now make sense, and makes the existing install guides much more sense too me too, it is just the fact that it was named rocm-dkms very unfortunate. I was certain that rocm-dkms is a dkms module stuff for kernel, and rock-dkms some yet another kernel driver for something that is also required.
the meta package could have been just 'rocmorrocm-platform, and the dkms package should be simply rocm-dkms` (hopefully not even needed soon. I didn't use it on my 4.18 kernel, but afaik there are few features still in progress of upstreaming).
BTW. I figured out how to install pieces by pieces what I need, and it works, and managed to install and test hcc and hip, by inspecting all the files, installing one by one, and figuring what are proper dependencies.
I am reporting, because I want ROCm to be a successful project, and not make other people be lost, especially if they are less technically versed than me.
I reported various issues with inter package dependencies to their respective repos. Almost none of packages has fully correct dependencies. Again, these are bugs to fix, not to fix my particular problem (because I can easily work it around and figure it out). I do not want to deal with these problems over and over again, on my dozens of computers or friends computers, etc.

Hi @baryluk
I expect that the rock-dkms package will stick around. While we do want to get all of our needed modifications into upstream kernels, having a separate ROCm driver has some benefits:

It allows us to support distros and releases that use kernels from before our code was upstreamed.
It allows for new hardware support for older kernels. For instance, if you buy a brand new GPU next year, the kernel you are using right now may or may not include support for that new GPU. Rather than forcing new users onto bleeding edge kernels, having an optional module like rock-dkms allows users of older releases (or stability-focused distros) to use the new GPUs
It allows us to include updated firmware that may include fixes done after a distro did their firmware snapshot.
We can bring up new features faster in this driver, because we can release before they've gone through the full upstream vetting process.

I want to thank you for reporting all the stuff you have. I hope that my answers have not sounded dismissive. We do appreciate feedback like this -- this is exactly the kind of feedback we hope to get as part of opening up all our software.
A lot of my answers have been explaining things because these GitHub issues come up pretty highly on internet searches when people run into problems similar to yours. Hopefully they'll also find my answers useful. :) That said, your concerns have been heard and we are working to get "documentation updates" into our developers' busy schedules.
Your help pointing out dependency issues are also appreciated. I'll admit that we sometimes fall into the trap of "this list of dependencies work on my system, ship it". :)  Our packages should work on all of our officially supported distributions (Ubuntu 18.04, Ubuntu 16.04, CentOS/RHEL 7.4 and 7.5). You're right that a good list of dependencies would ease the burden of getting ROCm running on "unsupported" distros.

Your packages mostly work, if you install the rocm-dkms thingy, because it basically pulls EVERYTHING into your system (plus hopefully libtinfo5 which might be already installed on some desktops). But if you ask to install only hip, or opencl runtime, it is very will install, but it will not work.
I understand different priorities during development.
Yeah, supporting newer hardware on older kernel / long term support machines, justifies keeping rock-dkms (amdkfd-dkms or something, would sounds probably better tho).
Now, I see my main complain was about the rocm-dkms structuring (and name), not rock-dkms (which obviously, might become optional or even discouraged for many people, and should not be a hard package dependency on any other component - and it appears it isn't, which is good - modulo the udev rules, which probably should be shipped in separate package that is a dependency of rocm-dkms, not bundled into rock-dkms. Just my guess.).
Anyway, this issue should probably stay more on HIP topic, most notably the README for the HIP installation.


"Computing installation plan" Crash

Hi, I just re-installed Windows. I installed and used vcpkg very well before the re-install but I have the crash now. I installed VS 2019 16.10.2 with only english pack, latest CMake and Git. Every package I tried crash in the "Computing installation plan" stage.
Environment

OS: Windows x64
Compiler: bootstrap-vcpkg.bat just downloaded the vcpkg.exe instead of building it. VS2019 16.10.2 English Pack.

Expected behavior
I want to use libraries with vcpkg. I used vcpkg successfully before, so I guess I'm not doing something wrong.
Failure logs
vcpkg install glad --debug
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' unset
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] BuiltinRegistry initialized with: ""
[DEBUG] Using vcpkg-root: C:\dev\vcpkg
[DEBUG] Using installed-root: C:\dev\vcpkg\installed
[DEBUG] BuiltinRegistry initialized with: ""
[DEBUG] Using buildtrees-root: C:\dev\vcpkg\buildtrees
[DEBUG] Using downloads-root: C:\dev\vcpkg\downloads
[DEBUG] Using packages-root: C:\dev\vcpkg\packages
[DEBUG] Using scripts-root: C:\dev\vcpkg\scripts
[DEBUG] Using ports-root: C:\dev\vcpkg\ports
[DEBUG] Using versions-root: C:\dev\vcpkg\versions
[DEBUG] Default binary cache path is: C:\Users\furka\AppData\Local\vcpkg\archives
Computing installation plan...
[DEBUG] Found path: C:\Program Files\CMake\bin\cmake.exe
[DEBUG] CreateProcessW("C:\Program Files\CMake\bin\cmake.exe" --version)
[DEBUG] cmd_execute_and_stream_data() returned 0 after    28880 us
[DEBUG] CreateProcessW("C:\Program Files\CMake\bin\cmake.exe" -DVCPKG_ROOT_DIR=C:/dev/vcpkg -DPACKAGES_DIR=C:/dev/vcpkg/packages -DBUILDTREES_DIR=C:/dev/vcpkg/buildtrees -D_VCPKG_INSTALLED_DIR=C:/dev/vcpkg/installed -DDOWNLOADS=C:/dev/vcpkg/downloads -DVCPKG_MANIFEST_INSTALL=OFF -P "C:\dev\vcpkg\buildtrees\0.vcpkg_tags.cmake")
[DEBUG] cmd_execute_and_stream_data() returned 0 after    23770 us

-END
Additional context
I tried to install vcpkg to other disk I use for game storage but it failed there the same too.

Can you run command "C:\Program Files\CMake\bin\cmake.exe" -DVCPKG_ROOT_DIR=C:/dev/vcpkg -DPACKAGES_DIR=C:/dev/vcpkg/packages -DBUILDTREES_DIR=C:/dev/vcpkg/buildtrees -D_VCPKG_INSTALLED_DIR=C:/dev/vcpkg/installed -DDOWNLOADS=C:/dev/vcpkg/downloads -DVCPKG_MANIFEST_INSTALL=OFF -P "C:\dev\vcpkg\buildtrees\0.vcpkg_tags.cmake" manually them provide the output?

Thanks for your interest, here is the output:
d8187afd-ea4a-4fc3-9aa4-a6782e1ed9af
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_TARGET_ARCHITECTURE=x86
VCPKG_CMAKE_SYSTEM_NAME=
VCPKG_CMAKE_SYSTEM_VERSION=
VCPKG_PLATFORM_TOOLSET=
VCPKG_VISUAL_STUDIO_PATH=
VCPKG_CHAINLOAD_TOOLCHAIN_FILE=
VCPKG_BUILD_TYPE=
VCPKG_LIBRARY_LINKAGE=dynamic
VCPKG_CRT_LINKAGE=dynamic
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_PUBLIC_ABI_OVERRIDE=
VCPKG_ENV_PASSTHROUGH=
VCPKG_ENV_PASSTHROUGH_UNTRACKED=
VCPKG_LOAD_VCVARS_ENV=
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
8c504940-be29-4cba-9f8f-6cd83e9d87b7
d8187afd-ea4a-4fc3-9aa4-a6782e1ed9af
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_TARGET_ARCHITECTURE=x86
VCPKG_CMAKE_SYSTEM_NAME=
VCPKG_CMAKE_SYSTEM_VERSION=
VCPKG_PLATFORM_TOOLSET=
VCPKG_VISUAL_STUDIO_PATH=
VCPKG_CHAINLOAD_TOOLCHAIN_FILE=
VCPKG_BUILD_TYPE=
VCPKG_LIBRARY_LINKAGE=dynamic
VCPKG_CRT_LINKAGE=dynamic
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_PUBLIC_ABI_OVERRIDE=
VCPKG_ENV_PASSTHROUGH=
VCPKG_ENV_PASSTHROUGH_UNTRACKED=
VCPKG_LOAD_VCVARS_ENV=
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
8c504940-be29-4cba-9f8f-6cd83e9d87b7
d8187afd-ea4a-4fc3-9aa4-a6782e1ed9af
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_TARGET_ARCHITECTURE=x64
VCPKG_CMAKE_SYSTEM_NAME=
VCPKG_CMAKE_SYSTEM_VERSION=
VCPKG_PLATFORM_TOOLSET=
VCPKG_VISUAL_STUDIO_PATH=
VCPKG_CHAINLOAD_TOOLCHAIN_FILE=
VCPKG_BUILD_TYPE=
VCPKG_LIBRARY_LINKAGE=dynamic
VCPKG_CRT_LINKAGE=dynamic
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_PUBLIC_ABI_OVERRIDE=
VCPKG_ENV_PASSTHROUGH=
VCPKG_ENV_PASSTHROUGH_UNTRACKED=
VCPKG_LOAD_VCVARS_ENV=
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
8c504940-be29-4cba-9f8f-6cd83e9d87b7
d8187afd-ea4a-4fc3-9aa4-a6782e1ed9af
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_TARGET_ARCHITECTURE=x64
VCPKG_CMAKE_SYSTEM_NAME=
VCPKG_CMAKE_SYSTEM_VERSION=
VCPKG_PLATFORM_TOOLSET=
VCPKG_VISUAL_STUDIO_PATH=
VCPKG_CHAINLOAD_TOOLCHAIN_FILE=
VCPKG_BUILD_TYPE=
VCPKG_LIBRARY_LINKAGE=dynamic
VCPKG_CRT_LINKAGE=dynamic
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_PUBLIC_ABI_OVERRIDE=
VCPKG_ENV_PASSTHROUGH=
VCPKG_ENV_PASSTHROUGH_UNTRACKED=
VCPKG_LOAD_VCVARS_ENV=
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
8c504940-be29-4cba-9f8f-6cd83e9d87b7
d8187afd-ea4a-4fc3-9aa4-a6782e1ed9af
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_TARGET_ARCHITECTURE=x86
VCPKG_CMAKE_SYSTEM_NAME=
VCPKG_CMAKE_SYSTEM_VERSION=
VCPKG_PLATFORM_TOOLSET=
VCPKG_VISUAL_STUDIO_PATH=
VCPKG_CHAINLOAD_TOOLCHAIN_FILE=
VCPKG_BUILD_TYPE=
VCPKG_LIBRARY_LINKAGE=dynamic
VCPKG_CRT_LINKAGE=dynamic
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
c35112b6-d1ba-415b-aa5d-81de856ef8eb
VCPKG_PUBLIC_ABI_OVERRIDE=
VCPKG_ENV_PASSTHROUGH=
VCPKG_ENV_PASSTHROUGH_UNTRACKED=
VCPKG_LOAD_VCVARS_ENV=
e1e74b5c-18cb-4474-a6bd-5c1c8bc81f3f
8c504940-be29-4cba-9f8f-6cd83e9d87b7

@ras0219-msft
Could you please help take a look?

@furkanxdgs4 @Sadkawt, I still can't repro this issue with vs2019 16.10.2, it maybe relate to anti-virus software?

I don't use any anti-virus software, just default Windows Defender. I turned it off but issue continues. Tried the vcpkg.exe mentioned in the Github Issue previously mentioned, didn't work.

Which  version of cmake are you using? I had the same issue with "vcpkg install" while using the release candidate cmake 3.21.0-rc1, but it seems to work correctly with the latest release 3.20.5 (https://github.com/Kitware/CMake/releases/download/v3.20.5/cmake-3.20.5-windows-x86_64.zip).

How in the world... Thanks a lot @alexgiesting, it worked now! I pay attention such things generally but somehow missed that.


SkyBoxShader won't work with SM4?

Hello, I LOVE this repo as I'm getting back into monogame! I tried copying your skybox into my OpenGL based monogame project, and the MGCB UI can't seem to build the SkyBoxShader. It tells me that it must be SM 3.0 or lower.

I've never messed with shaders before, so I naively tried to set it to version 3 and got this and the MGCB UI tells me that TEXCORD0 isn't valid vs_3_0 output semantics:

What modifications should I make to this shader to have it work for OpenGL monogame projects?

@bsambrone, I have a few skybox's in this repo, I just made an alteration to the one in the Terrain sample so it will use OpenGL 2.0
I added this to the top of the shader:-
#if OPENGL #define SV_POSITION POSITION #define VS_SHADERMODEL vs_2_0 #define PS_SHADERMODEL ps_2_0 #else #define VS_SHADERMODEL vs_4_0_level_9_1 #define PS_SHADERMODEL ps_4_0_level_9_1 #endif
Then changed the compile in the techniqu like this:-
technique Sky
{
pass P0
{
FILLMODE = SOLID;
VertexShader = compile VS_SHADERMODEL Transform();
PixelShader = compile PS_SHADERMODEL BasicShader();
}
}
Hope this helps :D


Revert "[SPARK-44801][SQL][UI] Capture analyzing failed queries in Listener and UI"

What changes were proposed in this pull request?
In the PR, I propose to revert the commit: https://github.com/apache/spark/commit/1f92995249b3c1a3ae9fdf7c7d3db28a2cb91b98
Why are the changes needed?
To fix the test suite StringFunctionsSuite.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
By running the affected test suite:
$ build/sbt "test:testOnly *.StringFunctionsSuite"

Was this patch authored or co-authored using generative AI tooling?
No.

I verified this locally. Merged to master to recover master branch.


[Data] Specifications and Scope for all optical imaging data (simulations, ground-base, space-base)

Specifications and Scope for all optical imaging data (simulations, ground-base, space-base)
The goal of this one-day hack is to discuss all types of optical data we could pull into the AstroPile.
Goals and deliverable
This is an initial discussion that will connect with #14 #13 #7

Today we had a lot of discussions on 1) data sources 2) data format for images 3) which spectra datasets to use.


Add options to hide args and env vars

To allow for use of weave-scope in an unauthenticated environment,
add options to the probe to hide comand line arguments and
environment variables, which might contain secret data.
Fixes #2222

Thanks a lot for this! I will try to review it before of the day (Judging from a preliminary, quick look it seems to be good. You even included tests!).

LGTM (modulo minor comment)

This has been reverted on master because it fails the lint check.

I merged it again at #2311 after fixing the linting problems ( linting didn't run in this PR due to #2192 )

Thanks. I'll remember to run those manually next time, sorry about that


Remove unused ttl field from cache.Cache.

The cache itself isn't responsible for snapshot invalidation anymore,
but this field has been left behind.

🎉 Thanks!
I guess this was a red herring when Ben and I we're debugging the CPU spikes of catalog pods. I thought this may have had something to do with it.

@joelanford Still possible, I moved the hardcoded TTL out of the cache just this week, but there is a still an at-most five minute TTL on snapshots of catalog content from registry pods (https://github.com/operator-framework/operator-lifecycle-manager/pull/2651).

/lgtm


not working on Atom 1.27.1 x64 on Windows 10

This doesn't seem to be working on Atom 1.27.1 x64 on Windows 10. I bring up a foo.md file, and it's showing that the Markdown language is selected. There is no syntax highlighting, however. I've already tried uninstalling and re-installing language-markdown.

What syntax theme are you using?

Both my UI Theme and Syntax Theme are set to "Atom Light".

Yeah, it has poor support. See the README. There are some themes there with proper support. Give them a try, and if it still doesn't do anything then, please post a screenshot.

But I don't want to use other themes.
Why should my theme change what the syntax looks like? If _foo_ makes something italics, why shouldn't it be italics in all themes? If ##foo is bold because it's a header, why shouldn't it be bold in all themes?
I'm afraid a syntax highlighter that forces me to use a certain theme isn't really useful. Is there a syntax highlighter for Atom that doesn't essentially break Atom? (I consider forcing me to use another theme "breaking Atom", because if Atom shipped without the light theme I would consider it broken for me, and this is the same thing.) It's a shame Atom doesn't support such a common format.

I switched to the "One Light" theme, and syntax highlighting shows up!
So this is a theme issue. But I still don't realize why the theme should disable syntax highlighting altogether.
I'll try the "One Light" theme for a while and see if it will work for me. Thanks for the reply

Why should my theme change what the syntax looks like? If foo makes something italics, why shouldn't it be italics in all themes? If ##foo is bold because it's a header, why shouldn't it be bold in all themes?

Because that's not how themes work. Text in between underscores is emphasized and headings need to visually stand out from paragraphs. Yet, that doesn't mean that they have to be italicized or bold. This is not Word.
The theme doesn't disable the syntax highlighting, it just doesn't recognize the semantic elements that the grammar parses. Themes don't highlight every little bit of code either. Differs per theme. Markdown is a bit of an outcast, because it shares very little with your average programming language.
However, you can easily extend your theme. See this and this. It might seem daunting, but it gets easier quite fast. You could even write a little script that switches syntax themes just for Markdown documents.
If this goes over your head, language-markdown probably isn't for you. The default language-gfm should work fine for you.

The default language-gfm should work fine for you.

I actually installed language-markdown to try to get any Markdown syntax highlighting. Are you saying that if I would merely have switched to "One Light" instead of "Atom Light", I would have got Markdown syntax built-in anyway?

Oh no, the default markdown packages don't have much support for Markdown. This package just opens up possibilities, though themes need some adapting to make use of them.


docs: er diagram

closes #37

rendered version for those that are curious:
https://github.com/KonomiAI/Chronicle/blob/8738ea106254705b1323719d1f63c7147a620a04/docs/design/database.md

Mdbook Render:


feat: Support oneOf with one value (box/box-codegen#530)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

8 of 17 (47.06%)  changed or added relevant lines in 2 files are covered.
49 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 41.926%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/schemas/integrationMapping.generated.ts
2
3
66.67%

src/schemas/integrationMappingPartnerItemSlackUnion.generated.ts
6
14
42.86%

Files with Coverage Reduction
New Missed Lines
%

src/managers/chunkedUploads.generated.ts
49
50.32%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
12633

Relevant Lines:
23473

💛  - Coveralls


Handle null pointer in onStart method in CourseLectureListActivity

@nasthagiri @rohan-dhamal-clarice - I have added null check for adapter and enrollment in onStart of CourseLectureListActivity.
There was a crash mentioned in Crashlytics for the same, but the issue was not reproducible. I have added a null check to handle the issue.
Please review
Jira Issue -  https://openedx.atlassian.net/browse/MOB-1367

@rohan-dhamal-clarice - I have updated the code and have reinitialized the adapter if it is null.
Please review.

Looks good.

:+1:


fix: Use correct image in tests package.json

Description
Changes proposed in this pull request:

use correct image in tests
Related issue(s)

Definition of done

[x] The PR's title starts with one of the following prefixes:

feat: A new feature
fix: A bug fix
docs: Documentation only changes
refactor: A code change that neither fixes a bug nor adds a feature
test: Adding tests
chore: Maintainance changes to the build process or auxiliary tools, libraries, workflows, etc.

[ ] Related issues are linked. To link internal trackers, use the issue IDs like backlog#4567
[x] Explain clearly why you created the PR and what changes it introduces
[x] All necessary steps are delivered, for example, tests, documentation, merging

/override tide


iOS - I can't zoom out view after click on input inside webview.

I have a react-native app that render a webchat (Microsoft webchat). It was working fine until the last apple iOS update. I've changed the WebView component and now I'm using react-native-webview but issues persists. When I click on input the view zoom in to insert the text but the zoom persist after sent the content. Also after the keyboard hide a blank space is show.
(Please check screenshot)
OSX
node: v8.11.3
react: 16.6.0-alpha.8af6728
react-native: 0.57.3
react-native-webview: 2.5.0

Thanks!

Same problem any body please help on that

https://stackoverflow.com/questions/26295277/wkwebview-equivalent-for-uiwebviews-scalespagetofit would that help ?

@krishan1kamal Where did you use this code? I couldn't found any workaround yet 😭

Hey @osvald0 you can update to 0.57.4 and it's removed

I've updated to 0.57.5 and the issue persist 😔

I found the solution to solve this error. I edited the source code in RNCUIWebView.m to change the scroll view insets setting from UIScrollViewContentInsetAdjustmentNever to UIScrollViewContentInsetAdjustmentAutomatic.
If you use WKWebView, you have to change the same. I don't ensure that this will not raise any another errors, but it works for me.

Hi, @hwth , thank for your comment but the workaround didn't work for me :(

Have you tried playing with tags like https://github.com/react-native-community/react-native-webview/issues/447#issuecomment-477201365?

same issue :(

Facing same issue

I'm also having this issue. My webview loads a url that contains a text input. When a user clicks on the text input, the view zooms in. When the user leaves the text input, the page is still zoomed in, which causes the webview to scroll horizontally. Please let me know if there is a fix for this.

Based on @fekajin response, this worked for me:
render() {
const iosZoomFix = "const meta = document.createElement('meta'); " +
"meta.setAttribute('content', 'width=device-width, initial-scale=1, maximum-scale=1, user-scalable=1'); " +
"meta.setAttribute('name', 'viewport'); " +
"document.getElementsByTagName('head')[0].appendChild(meta); " +
"true; ";
return (
<WebView
style={styles.webview}
ref={this.refName}
startInLoadingState={true} // this can cause problems in Android. Leaving here for now.
source={{ uri: this.currentUrl }}
javaScriptEnabledAndroid={true}
automaticallyAdjustContentInsets={true}
renderError={this.renderError}
onNavigationStateChange={this.navigationStateChange}
injectedJavaScript={injectedJS}
key={this.state.key}
/>
);
}

automaticallyAdjustContentInsets={true}

not work for me :(

@awatt-cox
I had an issue with an iframe within a WebView not detecting the smaller screen size, on iOS only (this was for an embedded dashboards through Domo). The meta tag used here fixed this for me.
Thanks!

    const iosZoomFix = "const meta = document.createElement('meta'); " +
        "meta.setAttribute('content', 'width=device-width, initial-scale=1, maximum-scale=1, user-scalable=1'); " +
        "meta.setAttribute('name', 'viewport'); " +
        "document.getElementsByTagName('head')[0].appendChild(meta); " +
        "true; ";

did not work for me. when I dismiss the keyboard, the zoom pans the right side of my input fields partially clipped out of view instead of restoring original state.


Add product features for pausing/resuming ansible/foreman providers

These are necessary for adding the pause/resume ability for foreman and ansible tower providers.
@miq-bot add_label hammer/no, providers/foreman, providers/ansible_tower
@miq-bot add_reviewer @slemrmartin
Parent issue: https://github.com/ManageIQ/manageiq/issues/17489

Do these features need to be added to some pre-defined roles? Or are these added throught their parent features?
In case you do not know what I am speaking about take a look at /manageiq/db/fixtures/miq_user_roles.yml read https://github.com/ManageIQ/guides/blob/master/ui/rbac_features.md and check the Role editor in the UI.

As far as I see, this is missing globally even for the previously added suspend features on infra/cloud providers. So if these should be in the roles file, I'd feel a little more comfortable creating a separate PR for them. @slemrmartin can you please assess this and create the PR if necessary?

Ok, guys, separate PR then, pls.
This is a recurring topic (I keep telling people not to forget about roles over and over).
Please, read the doc and suggest improvements if it's unclear or incomplete.


Add support to create productStore settings for store permissions screen

What is the motivation for adding/enhancing this feature?

What are the acceptance criteria?

[ ] ...

Can you complete this feature request by yourself?

[x] YES
[ ] NO

Additional information

Closing as completed


Abysmal performance for hash algorithms in dart:crypto

Originally opened as dart-lang/sdk#4611
This issue was originally filed by<EMAIL_ADDRESS>
Test code:
new File('recordroyale.ogg').readAsBytes().then((buf) {
  var md5 = new MD5();
  md5.update(buf);
  print(md5.digest());
});
where 'recordroyale.ogg' is about six megabytes. This takes 22 seconds on my machine. Shelling out to md5sum(1) takes under 0.02 seconds. I understand that Dart won't ever be as fast as C, but with this disparity, the hash algorithms should be implemented in C[++] rather than Dart.
I had a vague suspicion that this was slow due to unnecessary allocations, but the allocations are mostly small and consumed quickly. Refactoring to eliminate unnecessary allocations resulted in no change.
My use case involved checksumming a byte array that existed only in memory at the relevant location; it is far less convenient to write data to a temporary file, shell out to md5sum(1), then delete that file.

It is still very slow in Dart.
https://pub.dev/packages/hashlib#benchmarks
MD5 | 168.39 MB/s
XXH128 | 119.32 MB/s

For comparison on Rust
MD5 104857600 bytes * 1 iterations: 179 ms, Speed: 557.3 MiB/s
SHA1 104857600 bytes * 1 iterations: 108 ms, Speed: 922.0 MiB/s
SHA256 104857600 bytes * 1 iterations: 290 ms, Speed: 344.0 MiB/s
xxHash64 104857600 bytes * 1 iterations: 3 ms, Speed: 29021.6 MiB/s
xxHash128 104857600 bytes * 1 iterations: 3 ms, Speed: 29704.1 MiB/s
MurmurHash3 104857600 bytes * 1 iterations: 27 ms, Speed: 3653.0 MiB/s
MD5 5242880 bytes * 10 iterations: 86 ms, Speed: 575.7 MiB/s
SHA1 5242880 bytes * 10 iterations: 52 ms, Speed: 947.0 MiB/s
SHA256 5242880 bytes * 10 iterations: 145 ms, Speed: 344.5 MiB/s
xxHash64 5242880 bytes * 10 iterations: 1 ms, Speed: 32948.0 MiB/s
xxHash128 5242880 bytes * 10 iterations: 1 ms, Speed: 32645.1 MiB/s
MurmurHash3 5242880 bytes * 10 iterations: 13 ms, Speed: 3734.6 MiB/s
MD5 1024 bytes * 5000 iterations: 9 ms, Speed: 530.7 MiB/s
SHA1 1024 bytes * 5000 iterations: 5 ms, Speed: 852.7 MiB/s
SHA256 1024 bytes * 5000 iterations: 15 ms, Speed: 315.6 MiB/s
xxHash64 1024 bytes * 5000 iterations: 0 ms, Speed: 30717.6 MiB/s
xxHash128 1024 bytes * 5000 iterations: 0 ms, Speed: 29533.2 MiB/s
MurmurHash3 1024 bytes * 5000 iterations: 1 ms, Speed: 3319.9 MiB/s
MD5 10240 bytes * 500 iterations: 8 ms, Speed: 565.2 MiB/s
SHA1 10240 bytes * 500 iterations: 5 ms, Speed: 944.3 MiB/s
SHA256 10240 bytes * 500 iterations: 14 ms, Speed: 336.6 MiB/s
xxHash64 10240 bytes * 500 iterations: 0 ms, Speed: 33178.9 MiB/s
xxHash128 10240 bytes * 500 iterations: 0 ms, Speed: 32247.5 MiB/s
MurmurHash3 10240 bytes * 500 iterations: 1 ms, Speed: 3714.1 MiB/s
MD5 10 bytes * 100000 iterations: 11 ms, Speed: 85.6 MiB/s
SHA1 10 bytes * 100000 iterations: 7 ms, Speed: 127.7 MiB/s
SHA256 10 bytes * 100000 iterations: 18 ms, Speed: 52.2 MiB/s
xxHash64 10 bytes * 100000 iterations: 0 ms, Speed: 4630.4 MiB/s
xxHash128 10 bytes * 100000 iterations: 0 ms, Speed: 2886.6 MiB/s
MurmurHash3 10 bytes * 100000 iterations: 1 ms, Speed: 730.6 MiB/s

It looks that theoretically it could be 29704.1 / 168.39 = 176 times faster!
One tiny problem... It cannot be on Dart.

Rust benchmark
use md5;
use sha1::{Sha1, Digest as Sha1Digest};
use sha2::{Sha256, Digest as Sha2Digest};
use xxhash_rust::xxh3::{xxh3_64, xxh3_128};
use murmur3::murmur3_x64_128;
use rand::Rng;
use std::time::{Duration, Instant};
use hex::encode as hex_encode;
use std::io::Cursor;

fn main() {
    // Buffer sizes and iterations
    let data_sizes = [
        (100 * 1024 * 1024, 1),   // 100 MiB * 1
        (5 * 1024 * 1024, 10),    // 5 MiB * 10
        (1 * 1024, 5000),         // 1 KiB * 5000
        (1 * 10240, 500),         // 10 KiB * 500
        (10, 100000),             // 10 bytes * 100000
    ];

    for (data_size, iterations) in &data_sizes {
        let mut rng = rand::thread_rng();
        let byte_list: Vec<u8> = (0..*data_size).map(|_| rng.gen()).collect();

        // Benchmark MD5
        let md5_duration = benchmark_md5(&byte_list, *iterations);
        print_benchmark_results("MD5", *data_size, *iterations, md5_duration);

        // Benchmark SHA1
        let sha1_duration = benchmark_sha1(&byte_list, *iterations);
        print_benchmark_results("SHA1", *data_size, *iterations, sha1_duration);

        // Benchmark SHA256
        let sha256_duration = benchmark_sha256(&byte_list, *iterations);
        print_benchmark_results("SHA256", *data_size, *iterations, sha256_duration);

        // Benchmark xxHash 64-bit
        let xxhash64_duration = benchmark_xxhash64(&byte_list, *iterations);
        print_benchmark_results("xxHash64", *data_size, *iterations, xxhash64_duration);

        // Benchmark xxHash 128-bit
        let xxhash128_duration = benchmark_xxhash128(&byte_list, *iterations);
        print_benchmark_results("xxHash128", *data_size, *iterations, xxhash128_duration);

        // Benchmark MurmurHash3
        let murmur_duration = benchmark_murmur3(&byte_list, *iterations);
        print_benchmark_results("MurmurHash3", *data_size, *iterations, murmur_duration);
    }
}

fn print_benchmark_results(hash_name: &str, data_size: usize, iterations: usize, duration: Duration) {
    let total_size = data_size * iterations;
    let speed = total_size as f64 / (duration.as_secs_f64() * 1024.0 * 1024.0);
    println!(
        "{} {} bytes * {} iterations: {} ms, Speed: {:.1} MiB/s",
        hash_name,
        data_size,
        iterations,
        duration.as_millis(),
        speed
    );
}

fn benchmark_md5(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let _result = md5::compute(bytes);
    }
    start.elapsed()
}

fn benchmark_sha1(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let mut hasher = Sha1::new();
        hasher.update(bytes);
        let _result = hasher.finalize();
    }
    start.elapsed()
}

fn benchmark_sha256(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let mut hasher = Sha256::new();
        hasher.update(bytes);
        let _result = hasher.finalize();
    }
    start.elapsed()
}

fn benchmark_xxhash64(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let _result = xxh3_64(bytes);
    }
    start.elapsed()
}

fn benchmark_xxhash128(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let _result = xxh3_128(bytes);
    }
    start.elapsed()
}

fn benchmark_murmur3(bytes: &[u8], iterations: usize) -> Duration {
    let start = Instant::now();
    for _ in 0..iterations {
        let _result = murmur3_x64_128(&mut Cursor::new(bytes), 0).unwrap();
    }
    start.elapsed()
}


Check continuity of fast-track, esp. multi-session datasets and w/cohort normalization

#219 and #223 will likely break some parts of the anatomical fast track. Let's make sure it works before cutting 0.7.

Hello,
Fast-track seems to break with my dataset on smriprep 0.7 / fmriprep 20.2.0, notably due to bids' build_path not considering potential session/runs within the name.
I developed a dirty-hack which rely on BIDSLayout instead and works for me.
commit: https://github.com/nuKs/smriprep/commit/bd72f83975436cbc0a230570d77e3876a355c121
branch: https://github.com/nuKs/smriprep/commits/nuKs/fix-fast-track
I did not PR as I am not sure it's the best way to fix this, and if this works on other use cases.
Notably, I didn't change anything related to Freesurfer files as I didn't have preprocessed sample files.
It's tested on a single subject/session dataset, I still need to try it out on multi session dataset as well.
Logging the missing files is convenient in any case.

The patch also fixes two anat within sessions. The use case appears to be different as for single session anat, no template has to be created, while 2 sessions are averaged. In both case, "run-" is kept.
 I could be missing something as well.

My patch seems to work, though not up to date with the fmriprep trunk (no config python file anymore etc).
I did not compare my patch output with traditional fmriprep non-fast track output so i am not 100% sure everything is fine.
I can integrate it with the latest version if you think it's OK.

Hi @nuKs - thanks for your patience, we are seriously limited in time lately - What would you need from us to push this forward? Just check out your branch and test on our settings?
Do you have examples that make the fast-track fail?

Hi, no worries, thanks for sharing your work!
What my patch does is to rely on pybids layout instead of bids build_path in order to retrieve the fast_track derivatives files.
Pybids layout does adapt to any bids-valid naming scheme, while build_path does not adapt to unexpected filename parts from retrieved derivatives file names, but rather directly assume the names).
So far, examples that make fast-track fail includes:

subjects with a single T1 (as the path is different since no template is made)
subjects with T1 containing run-x segments within the name.
In my case, IBC is failing for some subjects, modified/reduced day2day datasets too.
IBC openneuro: https://openneuro.org/datasets/ds002685/versions/1.3.1
day2day upon request: https://bmcneurosci.biomedcentral.com/articles/10.1186/s12868-017-0383-y

I made the assumption that fmriprep must have some additional step that picks up the right derivative within the list, and I didn't check this step's code so I am not 100% sure I patched the right way considering the derivative list returned by the patched function is now less restrictive than it used to. Everything should be fine though, but if you have worked on these bits, a simple quick look at my patch code may allow you to see if there is any red flag regarding what I did.
I'll cleanup/update everything on the latest version so you can test and merge (if you wish).

Jumping in that old convo: I noticed that the fast-track would fail if you process a single anat in a multi-session dataset (and results is output in a session folder) and then try to use that output as anat fast-track for fMRIPrep. Because collect_derivatives does not look into sessions (even if the pattern would allow it), it will not find the preprocessed data and fMRIPrep. I think going with pybids would indeed provide more flexible search options.

Had made that PR if you want to check in, a bit old though.


json_to_abap - added logic for type time

never used regex before, but tried to make it as similar as possible to the already existing date logic.

thank you for reviewing!

@larshp abaplint UTs are failing, looks like different initial time behavior. Any quick suggestion? (exclude is an option too)

empty value will trigger the exception right? that is then ignored and initial values given?

fixed, running

Thanks Lars !

Using the occasion, v1.1.10


fix clusters/ endpoint query

By this PR I broke the clusters endpoint. Fixing it
Secure Coding Practices Checklist GitHub Link

https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

[x] Input Validation
[x] Output Encoding
[x] Authentication and Password Management
[x] Session Management
[x] Access Control
[x] Cryptographic Practices
[x] Error Handling and Logging
[x] Data Protection
[x] Communication Security
[x] System Configuration
[x] Database Security
[x] File Management
[x] Memory Management
[x] General Coding Practices

Codecov Report

Merging #68 (fb0fb81) into master (25f80a8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #68   +/-   ##
=======================================
  Coverage   40.47%   40.47%
=======================================
  Files          13       13
  Lines         635      635
=======================================
  Hits          257      257
  Misses        359      359
  Partials       19       19

Flag
Coverage Δ

unittests
40.47% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

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


snowflake-connector-python 2.7.3

Bug tracker: https://github.com/snowflakedb/snowflake-connector-python/issues
License: https://github.com/snowflakedb/snowflake-connector-python/blob/main/LICENSE.txt
Upstream pyproject.toml: https://github.com/snowflakedb/snowflake-connector-python/blob/v2.7.3/pyproject.toml
Upstream setup.cfg: https://github.com/snowflakedb/snowflake-connector-python/blob/v2.7.3/setup.cfg
Upstream setup.py: https://github.com/snowflakedb/snowflake-connector-python/blob/v2.7.3/setup.py

An error om osx-64:
pip._internal.exceptions.InstallationSubprocessError: Command errored out with exit status -11: $PREFIX/bin/python $PREFIX/lib/python3.8/site-packages/pip/_vendor/pep517/in_process/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpddj20_ux Check the logs for full command output.

Opened a new PR for v2.7.4 https://github.com/AnacondaRecipes/snowflake-connector-python-feedstock/pull/3


Change repository status (remove fork dependency)

The repository is currently seen as a fork of the conformal master. This disables searching of the repo on the github website. It also makes it so that when you make a pull request it defaults to diffing the conformal repo and the gotk3 repo. This takes a super long time to load on slow computers.

i believe, when i delete the fork dependency, we lost all infos for issues, pullrequest and more.

Ah, that is very unfortunate.

i found regrettably only this way:

made sure my local copy was up to date.
created a new project in github.
git remote rm origin
pushed the code to the new project (per the new project instructions)
deleted the old project/fork within github
renamed the new project over the old project.
updated the origin remote to point to the original url

I will not do so.

This help page says:

To detach the fork and turn it into a standalone repository on GitHub, contact GitHub support.

So maybe it's possible to drop dependency without losing any data.

is done! i hope this was in yours sense.


control rod slider buttons and server spam reduction.

Hi, I wasn't sure where to leave comments :)
A suggestion: +/-  1% and 10% buttons  to the fuel rod % slider. With a sight delay built in so it doesn't submit a request to recalculate each time an adjustment is made. it's annoying to try to adjust / optimize by moving such a small bar 1% at a time.
Idea: Optimization button for RF/tick by adjusting fuel rod %.
Also a similar delay on recalculating when adding blocks to the reactor, maybe a 2 second delay from last block placed ? If I am building it, I am adding a lot of blocks and don't need to update for each block.
Idea:  a button to turn recalculating on/off while building would be easier than coding a delay.

Great ideas.

Added a toggle for auto-updates. Might have to refresh to see it.

Also added:

buttons to add/subtract 1%, 5%, and 10% from the control rod insertion slider.
an "optimize" button for control rod insertion that chooses the optimal value.

I think adding a delay between auto-update requests is obviated by the auto-update toggle. I'll close this for now, but feel free to re-open.

Excellent work Sir! It feels so much smoother to do the edits with auto-update off!


nginx-proxy don't work well with opennebula 6.02 - VNC does not open

Hi,
i installed opennebula-mini with bash script on debian10;
I would also like to activate the https functionality through proxy-nginx;
I have a wildcard ssl certificate for my domain, and it works perfectly on other nginx-proxies.
The functionality of opennebula would appear to be respected except the error message below "fireedge public endpoint is not working" and the vnc panel not opening.
/etc/one/sunstone-server.conf
:vnc_proxy_port: 29876
:vnc_proxy_support_wss: only
:vnc_proxy_cert: /etc/ssl/private/example.com.crt
:vnc_proxy_key: /etc/ssl/private/example.com.key
:vnc_proxy_ipv6: false
:vnc_request_password: false
:allow_vnc_federation: no
/etc/nginx/sites-enabled/default
server {
listen                        8443 ssl;
server_name             test.example.com;
location / {
proxy_pass      http://<IP_ADDRESS>:9869;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        host    $host;
proxy_set_header        X-Forwarded-Server      $host;
proxy_read_timeout 600s;
proxy_connect_timeout 600s;
}
location /websockify {
proxy_pass http://<IP_ADDRESS>:29876;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
add_header Access-Control-Allow-Origin *;
}
}
error_page 497 https://$host$request_uri;
ssl_certificate /etc/ssl/private/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
keepalive_requests 150;
I am attaching screenshots
can you help me ?
Thank you

You can check documentation about how to configure FireEdge with Apache/Nginx here.
Also you can check specific FireEdge configuration here.
Closing this as it seems a configuration error, please reopen it if needed.


Fix specs when log depth is false

In some internal code outside this repo, we turn off the logarithmic depth buffer. But when the specs are run in such an environment, some specs fail due to models clipped by the near plane.
The fix is usually to move the camera back just a little bit so the spec works whether the depth buffer is on or off.
@ggetz could you review?

Thanks for the pull request @ptrgags!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

All looks good. Thanks for brining this in @ptrgags!


build: Fix dynamic import of metadata modules on Windows (again)

I already did this in #34, but it was reverted when we switched from ESM to CJS in #147.
Now that a2e7fc7 reintroduced ESM with tsx, we need this patch again.
See the problem discussion at https://github.com/ROpdebee/mb-userscripts/pull/779#issuecomment-2242718714 and https://github.com/kellnerd/userscript-bundler/issues/4.

A quick check under Linux confirmed that the build process is still working as well.


Support abi3 wheels

Hey there! I am working on a Maturin wheel built for abi3 and wasm32-emscripten-unknown, something which appears to work in Pyodide. I'm coming at this as a Rust developer, not really too knowledgable about Python, so most of what I know about abi3 is from the PyO3 documentation: https://pyo3.rs/v0.14.5/features.html#abi3
My understanding is that abi3 wheels are forwards compatible, meaning an abi3-py39 wheel will work with Python 3.9, 3.10, 3.11, 3.12, and so on. Empirically I can say our abi3-py39 wheel works just fine in Pyodide v0.26.2 (with some recent bugfixes I have recently done to perspective's build).
This PR adds support for abi3 wheels so that they can be added to pyodide-lock.json files. Will add a test to test_wheel.py
abi3 is also known as the stable ABI https://docs.python.org/3/c-api/stable.html#stable-abi

This doesn't appear to actually produce a pyodide-lock patched with the package though… investigating.

Certainly! Amended the commit to update the CHANGELOG


Allow greater versions ranges in composer deps

Coverage remained the same at 99.605% when pulling 8e7bafe0776a246324c1729f10496736e4206e95 on mrjgreen-less-strict-semver into d484fce270af42a86f980afe53cbcbc1cbac6685 on v3.


flutter create warning regarding Java compatibility needs a bit of cleanup for consistency

I ran flutter create and got:
$ flutter create skiazoom
Creating project skiazoom...
Resolving dependencies in `skiazoom`...
Downloading packages...
Got dependencies in `skiazoom`.
Wrote 129 files.

All done!
You can find general documentation for Flutter at: https://docs.flutter.dev/
Detailed API documentation is available at: https://api.flutter.dev/
If you prefer video documentation, consider: https://www.youtube.com/c/flutterdev

In order to run your application, type:

  $ cd skiazoom
  $ flutter run

Your application code is in skiazoom/lib/main.dart.

The configured version of Java detected may conflict with the Android Gradle Plugin (AGP) version in your new Flutter app.

[RECOMMENDED] If so, to keep the default AGP version 8.1.0, make
sure to download a compatible Java version
(Java 17 <= compatible Java version < Java 21).
You may configure this compatible Java version by running:
`flutter config --jdk-dir=<JDK_DIRECTORY>`
Note that this is a global configuration for Flutter.

Alternatively, to continue using your configured Java version, update the AGP
version specified in the following files to a compatible AGP
version (minimum compatible AGP version: 7.0) as necessary:
    -  /home/ianh/dev/skiazoom/android/build.gradle

See
https://developer.android.com/build/releases/gradle-plugin for details on
compatible Java/AGP versions.

Some things we could improve:

The wrapping is inconsistent throughout. Lines within paragraphs should all be roughly the same length, and paragraphs should have a blank line between them. ("See" on its own line,

We don't generally do [RECOMMENDED], that's not normal English grammar. Just use a normal English sentence like "The recommended action is..." or whatever.

We use inconsistent style regarding how to execute commands. The top part uses indented paragraphs with $ cd bla whereas the recommended section uses backticks on an unindented line in a paragraph.

"Note that" is redundant text and our style guide says to just not have it.

There's one paragraph that ends with an indented line with hyphens as a bullet and two spaces. This is unusual for our output in the tool as well.

Also, interestingly, flutter doctor isn't reporting this as an issue.

Hi @andrewkolos @darshankawar linked a PR above which should fix this issue. Please let me know if you have any feedback/suggestion. :)