IOS library not found for -lDoubleConversion

"react": "16.8.6",
react-native: 0.60.4,
"react-native-webview": "^5.12.1"

Steps To Reproduce

I have created a new project and it has only one package that is react-native-webview
When I build in the IOS emulator then I got some with the Xcode.
I got to link the webview also even it's not working I have tried many time still got the same issue

Yes. I mentioned what I got just error with IOS but Android is working fine. Why I don't know.
My Xcode 10.2.
Just let me what Can I do?

So i was having this issue too. If you are updating from 0.59, ensure that you have deleted your Pods and reinstalled.
cd ios
rm -rf Pods
pod install

I had tried literally everything suggested by the awesome community.
The solution for me was to create an empty Swift file through Xcode and let Xcode create a Bridging-header.h file. The key was to not delete the Swift file after Xcode creating the bridging header file.

Same issue here, react-native run-ios works fine, when I try on simulator or device => Library not found for -lDoubleConversion =/

the problem was open and build project in wrong place...
=> open ios/{Project}.xcodeproj instead => open ios/{Project}.xcworkspace

I did the same thing but still, I am getting the same error. I have tried with 0.59 again then it was working fine.
If I create new a project run on Xcode I was getting the same iBundile error.

Can you try this please? https://github.com/facebook/react-native/issues/25820#issuecomment-515742426

Have the same problem, tried https://github.com/facebook/react-native/issues/25820#issuecomment-515742426 but still nothing.

I also encountered this problem.

This is a problem that I have been trying to work out all day too.

I had this problem and manage to solve it somehow, but ran into a different problem and forgot how I solve this one in the first place. So please apologize if this doesn't work for you. To give a bit of context, I was coming from version 0.59 and was trying to upgrade to 0.60.4
I'll leave first what I think it's the main cause of the problem followed by other steps that hopefully will help you.
What I think the problem is
When upgrading, I had a lot of leftovers from previous RN versions, regarding linked binaries. But because RN 0.60 handles everything with pods, now my linked binaries look link this instead:

** Steps I took to overcome this problem **
Again, this is if my memory is correct. And please branch out before you try this so that you don't screw your existing setup.

Check the differences from versions.
I've used https://react-native-community.github.io/rn-diff-purge/ to check and implement any changes between versions

Cleaned the linked libraries

Ran

echo 'remove cache'
rm -rf $TMPDIR/react-*
rm -rf $TMPDIR/metro-*
watchman watch-del-all
npm cache verify

# echo 'removing derived data'
rm -rf ~/Library/Developer/Xcode/DerivedData

echo 'removing pods and node modules'
cd ios
pod deintegrate
pod cache clean --all
cd ../

rm -rf ios/Pods
rm -rf ios/Podfile.lock
rm -rf ios/build
rm -rf node_modules
rm -rf package-lock.json

echo 'cocoapods install'
gem install cocoapods

echo 'brew'
brew update && brew upgrade

echo 'installing node modules'
npm i

# mostly for any legacy stuff
echo 'react-native link'
react-native link

echo 'installing pods'
cd ios
pod update
pod install

Hope it helps.

Thanks @pmadruga but frustratingly that didn't work. For reference, it's only when archiving that the issue occurs for me.

The issue in more detail is that if I look in MYBUILD/BuildProductsPath/Release-iphoneos/ the files in there are like libReact.a, libdouble-conversion.a etc. But the build failure is looking for the
target support paths (I assume) like MYBUILD/BuildProductsPath/Release-iphoneos/DoubleConversion, MYBUILD/BuildProductsPath/Release-iphoneos/Folly

the problem was open and build project in wrong place...
=> open ios/{Project}.xcodeproj instead => open ios/{Project}.xcworkspace

use this command to open the workspace
cd ios && xed .

Just to point out that my issue was not related to forgetting to open the workspace. Before upgrading I was already using cocoapods. I now have a fully working version so will diff the configs to see what I can uncover.

still not found when pod install
RN: 0.60.0

I got the same issue.
react-native run-ios and react-native run-android  works fine,
but got error in Xcode => library not found for -lDoubleConversion
Any solution here?

the problem was open and build project in wrong place...
=> open ios/{Project}.xcodeproj instead => open ios/{Project}.xcworkspace

It works.
Step 1: quit Xcode completely
Step 2: open ios/{Project}.xcworkspace (PS: not ios/{Project}.xcodeproj)
Cheers!

the problem was open and build project in wrong place...
=> open ios/{Project}.xcodeproj instead => open ios/{Project}.xcworkspace

It works.
Step 1: quit Xcode completely
Step 2: open ios/{Project}.xcworkspace (PS: not ios/{Project}.xcodeproj)
Cheers!

Can you do a release build? Mine fails as soon as I use a release scheme. 😞 Debug works fine for me too...

@geekazoid-at
Yes, it works for me at debug/release/archive mode.

@paruckerr , that worked for me, but then I ran Archive and that succeeded, but no Organizer opened for me to export to generate .ipa.

I do get this bug of -lDoubleConversion library not found.
react-native-cli: 2.0.1
react-native: 0.60.5
When I do a clean react-native init, then try to build it I do get this error.

@Ebeldev Make sure the project file you open is xxx. xcworkspace (not xxx. xcodeproj)

@diamont1001  If I build it with xcworkspace: I get this error : error: Build input file cannot be found: '/Users/etiennebelanger/Documents/apps/react-native-apps/InfosLaurentides/node_modules/react-native/ReactCommon/yoga/yoga/YGMarker.cpp'

@diamont1001 I was able to build a new project using npx react-native init and then build it with Xcode.
Using npx instead of npm does it make a difference?

So when archiving, the error is due to not finding the folders (which appear to be the target support folders) e.g.
MYBUILD/BuildProductsPath/Release-iphoneos/DoubleConversion
MYBUILD/BuildProductsPath/Release-iphoneos/Folly etc
And when I go to look in the MYBUILD/BuildProductsPath/Release-iphoneos directory there are only files such as:
libReact.a,
libdouble-conversion.a etc.
--
Update - the fastest fix? to simply rebuild from scratch. Worked first time.

@jimhill do you mean the fastest way was to start a new react native project and pull all the files into a fresh install? I've been stuck on this issue for days now and I'm running out of ideas.

@realripley00 yep. I just ran a fresh install and migrated everything. It actually didn’t take very long in the end. I’d spent days too trying to fix it.

on 0.60 experience the same errors with Library not found / directory not found,
I can't launch my app because of this
Release build works but Building Archive is failing

on 0.60 I'm experiencing the same errors with Library not found / directory not found,
I can't launch my app because of this
Release build works but Building Archive is failing

@craftmusic I wound up following @jimhill 's advice and starting a fresh new react native app and then moving everything over. I made sure to use all the newest versions of every package. It's kind of tedious, but it's worth it if you consider that our team had spent probably twenty hours collectively over a few days trying to figure out this bug. Starting a new project and pulling in all the files took maybe 3 or 4 hours total. I wish we'd have decided to that sooner.

I created a fresh react native app 0.61.2 and moved my code over but i'm still receiving the same errors of Library not found / directories not found.
Xcode Debug builds and react-native run-ios work fine but building release still doesn't work. I've spent a ridiculous amount of hours on this.

@realripley00 @jimhill @ldco2016 @Ebeldev @diamont1001 @geekazoid-at
Honestly Facebook should provide some kind of human support, I know it’s “open source” but they still create the platform and manage it. Anyways, I started a petition about this just now, because it’s a much larger issue. Our app launch has been delayed by months due to issues with React Native. I wish we would have built everything in Native but we no longer have the funds Or the time to rebuild. Very frustrating.
Here’s the petition if you would please sign and pass it along: http://chng.it/dJJmXtJ6bz

I also can't make it past this issue, I keep getting Directory not found errors and i've tried everything / clearing node_modules + pods and caches + xcode derived data, build folders etc
Have tried everything now including starting multiple fresh apps for different react native versions 0.59, 0.60, 0.61 and cannot build Xcode release/archive
Development debug builds work fine.
`
Users/ivancaceres/Library/Developer/Xcode/DerivedData/{project name}/Build/Products/Release-iphonesimulator/DoubleConversion'

Did anyone find a solution yet? Regenerating the work space with cocoa pods obviously doesn't work. This is an blocking issue for releasing apps.

https://stackoverflow.com/questions/50562596/library-not-found-for-ldoubleconversion/55776414#55776414

https://stackoverflow.com/questions/50562596/library-not-found-for-ldoubleconversion/55776414#55776414

Does not work in my case

@nathantaal make sure you're Xcode build settings look alright:

Link Binary With Libraries:
should have your libPods-projectName.a
Target Dependencies should have React listed

And finally make sure your Library search paths look right, you should be able to see the DoubleConversion library name in the paths:

https://stackoverflow.com/questions/50562596/library-not-found-for-ldoubleconversion/55776414#55776414

Does not work in my case

Did anyone find a solution yet? Regenerating the work space with cocoa pods obviously doesn't work. This is an blocking issue for releasing apps.

This is a really frustrating bug, and I don't think the React team is interested in fixing on past versions of react. The only way that I've consistently been able to resolve it is to start a complete new project using the latest version of RN and as new packages as you can otherwise and then import all the files from the old project. It's a bit hacky, but after spending the better part of a week trying to resolve it, the four or five hours that it took to rebuild the project using the old files was worth it. It seems to me once this issue comes up on a project, it's "burned." Your only option is to restart it.

Experiencing this issue too when initialising adding Cocoapods to an old React Native project, 0.59.10.

@jimhill sounds like you had a good experience migrating everything.

Hi All,
I'm also facing the same issue. Even if I create a new RN project from scratch, it cannot be archived. Development build works fine. Any proper solution ?

This worked for me
rm -rf node_modules
cd ios
pod deintegrate
pod install
pod update

@nathantaal make sure your Xcode build settings look alright:

Link Binary With Libraries:
should have your libPods-projectName.a
Target Dependencies should have React listed

And finally make sure your Library search paths look right, you should be able to see the DoubleConversion library name in the paths:

You might be on to something here, but I wonder how to add React as a dependency since the .xworkspace file is removed since react-native 0.60?
+

For everyone the solution is different. For me, none of all worked. Because of React 0.60, React shouldn't be a Target dependency. The only thing I had to do was opening the xcodeworkspace and setting the recommended settings to my pods. Now I can archive apps like I always could.

Had this exact error when archiving. Degrading the ios target platform in the Podfile from 11.0 to 9.0 solved it for us. Had raised this previous when including a third-party library which did not support version 9.0. Remember to run 'pod deintegrate' and remove Podfile.lock before 'pod install' after changing this parameter. Took a long time to figure this out.

I also have this issue with react native 0.61, but only when building from command line..
Opening the xcodeworkspace and building or archiving the app works good, but calling xcodebuild form the terminal result in the same error

I'm getting the same as @emmanuele-villa. I get an error <projectName>Tests.m:11:9: fatal error: 'React/RCTLog.h' file not found, and other times I get this library not found error. I tried adding React to the product -> manage schemes -> project area, but react is not listed.

I'm getting this:
ld: library not found for -lFolly

The problem is that some of the pods are not built and have no files in DerivedData.
What is different in these pods compared to the others?
Folly
React-Core
React-cxxreact
React-jsi
React-jsiexecutor
I created a new RN app and it does not have this build error.

The newly created RN project includes the libraries/frameworks differently. For example the JavaScriptCore framework. It only has it under the Frameworks folder not in Link Binary With Libraries. This is really confusing, as I have used to adding libraries to the Build phases and they are automatically added to the frameworks. How does RN create the initial project to end up to this kind of project structure and how is it possible that this even works when the JavaScriptCore is not in the linked libraries?

Fixed the issue by commenting out use_modular_headers! and adding use_frameworks! This is because my project contains Swift files.
I also removed HEADER_SEARCH_PATHS and LIBRARY_SEARCH_PATHS lines from the Xcode project file.

I spent the last five days stuck on this, trying out everything suggested on the internet. This is what finally worked for me. (Before proceeding, make sure
pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec' is included in your podfiles
1. Delete Podfile.lock
2. cd ios
3. pod deintegrate
4. pod install
5. cd ..
6. rm -rf node_modules && yarn
7. Add use_frameworks! to your Podfile

Run react-native-run-ios or Build with Xcode by opening the xcworkspace file in your ios directory. Hope this helps someone!

same, none of solutions worked for me

I had the same problem. When I used the react-native run-ios command everything worked fine, but if I passed the --configuration Release I received the same error message. After a few hours I realised that the platform version in the Podfile was 11.0 but in the Xcode Project was 9.0.
After I corrected the version mismatch  everything work fine.

My solution was also sync target ios version in Podfile platform :ios, '11.0' and in Xcode General > Deployment Info > Target > iOS > 11.0 after close Xcode and run in cli cd ios && pod deintegrate && rm Podfile.lock && pod install

I  get this bug of -lDoubleConversion library not found.
please help! @react-native-bot
react-native :- 0.62.2
react:- 16.11.0

By changing platform :ios, '11.0' to '10.0' is worked for me

I was facing the same issue while running the project.
What I was doing is I was running Project.xcodeproj, :P
When i chose workspace , this was  working fine for me .

I was facing the same issue while running the project.
What I was doing is I was running Project.xcodeproj, :P
When i chose workspace , this was  working fine for me .

I had the same problem. When I used the react-native run-ios command everything worked fine, but if I passed the --configuration Release I received the same error message. After a few hours I realised that the platform version in the Podfile was 11.0 but in the Xcode Project was 9.0.
After I corrected the version mismatch everything work fine.

Saved a lot of time for me. Thank you 👍

Have the same problem, tried #25820 (comment) but still nothing.
Also working fine with 0.59.

Have got the solution?


Feature: Adding metadata in response

Pull Request Template
Description:

Closes #1322

Checklist:

[x] I have formatted my code using  goimport  and  golangci-lint.
[x] All new code is covered by unit tests.
[x] This PR does not decrease the overall code coverage.
[x] I have reviewed the code comments and documentation for clarity.

Thank you for your contribution!

Please also update the documentation and add tests.

Adding tests to control make sure how errors are reported would be appreciated


feat: add functional center crop on mask

Related to #5782

Code
import torch
import torchvision
from torchvision.prototype import features
from torchvision.prototype.transforms.functional import center_crop_bounding_box, center_crop_image_tensor, center_crop_segmentation_mask

size = (64, 76)
# xyxy format
in_boxes = [
    [10, 15, 25, 35],
    [50, 5, 70, 22],
    [45, 46, 56, 62],
    [size[1] // 2 - 3, size[0] // 2 - 3, size[1] // 2 + 3, size[0] // 2 + 3]
]
labels = [1, 2, 3, 4]

im1 = 255 * np.ones(size + (3, ), dtype=np.uint8)
mask = np.zeros(size, dtype=np.int64)
for in_box, label in zip(in_boxes, labels):
    im1[in_box[1]:in_box[3], in_box[0]:in_box[2], :] = (127, 127, 127)
    mask[in_box[1]:in_box[3], in_box[0]:in_box[2]] = label

t_im1 = torch.tensor(im1).permute(2, 0, 1).view(1, 3, *size)

in_boxes = features.BoundingBox(
    in_boxes, format=features.BoundingBoxFormat.XYXY, image_size=size
)
in_mask = features.SegmentationMask(torch.tensor(mask)).view(1, *size)

output_size = (45, 50)

out_boxes = center_crop_bounding_box(
    in_boxes,
    in_boxes.format,
    output_size=output_size,
    image_size=in_boxes.image_size
)
print(out_boxes)

out_mask = center_crop_segmentation_mask(
    in_mask,
    output_size
)

t_im2 = center_crop_image_tensor(t_im1, output_size)

import cv2
import matplotlib.pyplot as plt

plt.figure(figsize=(14, 10))

plt.subplot(2,3,1)
plt.title("Input image + bboxes")
r1 = t_im1[0, ...].permute(1, 2, 0).contiguous().cpu().numpy()
for in_box in in_boxes:
    r1 = cv2.rectangle(r1, (in_box[0].item(), in_box[1].item()), (in_box[2].item(), in_box[3].item()), (255, 127, 0))
plt.imshow(r1)

plt.subplot(2,3,2)
plt.title("Input segm mask")
plt.imshow(in_mask[0, :, :].cpu().numpy())

plt.subplot(2,3,3)
plt.title("Input image + bboxes + segm mask")
plt.imshow(r1, alpha=0.5)
plt.imshow(in_mask[0, :, :].cpu().numpy(), alpha=0.75)

plt.subplot(2,3,4)
plt.title("Output image + bboxes")
r2 = t_im2[0, ...].permute(1, 2, 0).contiguous().cpu().numpy()
for out_box in out_boxes:
    out_box = np.round(out_box.cpu().numpy()).astype("int32")
    r2 = cv2.rectangle(r2, (out_box[0], out_box[1]), (out_box[2], out_box[3]), (255, 127, 0), 0)
plt.imshow(r2)

plt.subplot(2,3,5)
plt.title("Output segm mask")
plt.imshow(out_mask[0, :, :].cpu().numpy())

plt.subplot(2,3,6)
plt.title("Output image + bboxes + segm mask")
plt.imshow(r2, alpha=0.5)
plt.imshow(out_mask[0, :, :].cpu().numpy(), alpha=0.75)

@pmeier, @vfdev-5 thoughts about testing the correctness of the function by mocking the function that really does the work? It's a proposal related to what we were saying in #5866.
IMO, there is no logic in center_crop_segmentation_mask, I'm just calling the center_crop_image_tensor function. If the latter is properly tested, the current test should be enough.
@vfdev-5, for the visualization side, the function center_crop_bounding_box is still missing. Is it ok to update the description  as soon as it's implemented?

IMO, there is no logic in center_crop_segmentation_mask, I'm just calling the center_crop_image_tensor function. If the latter is properly tested, the current test should be enough.

@federicopozzi33 I agree, I have a similar reflection about that while working on center_crop_bounding_box. Currently, I opted to write compute_expected_bbox function and check for results... There could be however few corner cases.

@vfdev-5, for the visualization side, the function center_crop_bounding_box is still missing. Is it ok to update the description as soon as it's implemented?

You can make visualization for segm mask and then add bbox when available ?

@federicopozzi33 I agree, I have a similar reflection about that while working on center_crop_bounding_box. Currently, I opted to write compute_expected_bbox function and check for results... There could be however few corner cases.

I added a test with random input too, but IMO it's not needed here: I don't see any corner cases.

We have to think about how to test composed ops in general. 1) Ensure that we call base ops in a right way or 2) check if the output is what we expect (expected result could be either hard-coded, computed using base ops or recomputed in a different way) or 3) something else ?

We can do both 1) and 2). I'd achieve the former by patching the base ops, and the latter with fixed input.
Then, 3) specific test cases can be added for corner cases.

You can make visualization for segm mask and then add bbox when available ?

I've updated the description.

@federicopozzi33 CI failures are real : https://github.com/pytorch/vision/runs/6376638110?check_suite_focus=true#step:9:127
please check

@federicopozzi33 thanks for the update. Code and test looks good to me (I left a minor suggestion). Once you fixed the problem with CI (probably due to resolving conflicts) we can merge it.
@pmeier any thoughts from your side about testing, particularly mocking part ?

What was the reason to go for the complex mocking here?

It is the first time we opt to use mock. I agree that in case of mask it is one-liner and it does not bring any useful checks but it can serve as an example for other composite ops, IMO.
Anyway, as you are reworking tests there will be other pass on tests, so no strong opinion from my side about removing or keeping this test.

@federicopozzi33 I agree with the general sentiment, but I would go a different route. If center_crop_image_tensor is already tested and thus implements a _prepare_expected function for all cases, can't we simply re-use it here?

mply re-use it here?

If the only thing that my function does is to call another tested function, IMO, mocking is the way. It's the same that calling the inner function, but without really doing it. Just two different ways to approach the same problem. You choose :)
So, should I add replace my naive prepare_expected to cover many more test cases?

If the only thing that my function does is to call another tested function, IMO, mocking is the way.

That is a dangerous conclusion. Mocking something always means that we switch from black box testing to white box testing. Meaning, we now need to know the internals of the function we want to test. That isn't a bad thing in general, but brings other problems with it. For example, if the internals change but the interface stays the same, the test might break although it shouldn't.
Imagine we rename center_crop_image_tensor to center_crop_image. The test for the segmentation mask would now fail since the mock target needs to change. Admittedly, the fix wouldn't be hard, but it is still a breakage that does not need to happen.
In this situation here, IMO it would be best to just use the expected result computation for images and segmentation and stick to black box testing.

If the only thing that my function does is to call another tested function, IMO, mocking is the way.

That is a dangerous conclusion. Mocking something always means that we switch from black box testing to white box testing. Meaning, we now need to know the internals of the function we want to test. That isn't a bad thing in general, but brings other problems with it. For example, if the internals change but the interface stays the same, the test might break although it shouldn't.
Imagine we rename center_crop_image_tensor to center_crop_image. The test for the segmentation mask would now fail since the mock target needs to change. Admittedly, the fix wouldn't be hard, but it is still a breakage that does not need to happen.
In this situation here, IMO it would be best to just use the expected result computation for images and segmentation and stick to black box testing.

I agree with you. I'd just like to clarify one point: IMO, mocking a public function is very different from mocking a private one, especially in cases like ours, considering that modifying public functions means doing a "major change".
Anyway, I added some extra test cases (output size bigger than image and odd output dimensions) and I'm computing the expected with the center_crop_image_tensor, so please take a look.

considering that modifying public functions means doing a "major change".

That is true in general, but not so much during the prototype phase.

Sorry, I'm pretty busy these days, I'll fix the PR in the next few days (probably during the weekend).


Unity compatibility adjustments

Hello, this PR is aimed at several different areas to make the features available in Arch.Extended more compatible with Unity and easier for developers to build and use.
I've based this PR on https://github.com/genaray/Arch.Extended/pull/67 so I'd hold off on merging it if there are any concerns/issues with that one.
Publish Profiles
I've created publish profiles for all the non-tests/sample projects with the correct settings such that a developer has a straightforward path to publish these projects and use them in Unity without compiler error issues. The steps are to:

Publish each project using the provided profile. This will result in all assemblies being published to two folders underneath UnityPublish.

UnityPublish

Plugins => Contains assemblies that may need to be directly referenced.
SourceGenerators => Contains source generator assemblies only. These require a few special steps after being imported into Unity to use properly.

Import the contents of UnityPublish into a folder in Unity. This will cause compiler errors temporarily due to the source generators.
Select all assemblies underneath SourceGenerators and make sure the following settings are configured.

Go to Select platforms for plugin and disable Any Platform.
Go to Include Platforms and disable Editor and Standalone.
Go to Asset Labels and open the Asset Labels sub-menu (this is present in the lower-right corner of the inspector).
Assign a custom RoslynAnalyzers label to all of them.

This should result in all compiler errors going away and all features of Arch.Extended can be used in Unity.

If useful these instructions could be added to the Wiki.
AOT.SourceGenerator
Unity's C# level and capabilities do not currently include [ModuleInitializer] and so this source generator did not work in Unity as a result as well as causing compiler errors. I've modified this to conditionally use the Unity equivalent [RuntimeInitializeOnLoadMethod] instead when this source generator is used in Unity projects.
I also added a small QOL debug change to sort the component types by name; this makes it easier to visually inspect the generated code in the case of any issues.
Systems
This is a helpful feature that almost seems like it could be a default for Arch, but has one issue that currently makes that impossible to use in Unity with MonoBehavior and ScriptableObject types.
Update() is a special method in Unity for anything derived from MonoBehavior or ScriptableObject, even if it includes parameters. Attempting to use overloads of Update() on these types will result in Unity crashing, which prevents developers from being able to implement ISystem<T> on these types.
This PR changes these methods to instead use Execute in place of Update which fixes this issue and updates the sample project as a result. This enabled me as a developer to make a few Unity-centric base classes for systems so that I could create ScriptableObject, MonoBehavior, and even third-party MonoBehavior derived systems and does not result in Unity Editor crashes.
ScriptableObject Examples of Systems

MonoBehavior Examples of Systems

@genaray The only issue with this change from Update to Execute is that it would be a breaking API change and perhaps not necessarily one we'd want to force on everybody for the sake of just Unity developers. I could also instead rework this to conditionally use Execute over Update if something like a Unity constant were added to both System projects, but then this would result in the locally included sample project to fail to compile when a Unity developer locally made those changes. Any thoughts on how you would like to accept changes like these that aim for compatibility with specific engines?

Thanks that looks great! :)
Just one small question, is the .idea folder required? Normally it is not recommended to include IDE specific directorys.

This is great PR, but as a developer using Arch in Unity, there are a few things I don't agree with.
First, the RuntimeInitializeOnLoad attribute used in the AOT Source Generator works by default with RuntimeInitializeLoadType.AfterSceneLoad. Perhaps this should be done earlier (e.g. RuntimeInitializeLoadType.SubsystemRegistration)?
Also, in my opinion ISystem should not be implemented by MonoBehaviour or ScriptableObject, the implementation of System should be delegated to pure C# classes. I also don't think it is appropriate to make such a destructive change as to change the name of the method because of it.

Also, although this is a rare case, it may be better to use UnityEditor.InitializeOnLoadMethodAttribute in consideration of running it on the editor. (This can be implemented with #if UNITY_EDITOR.)

This is great PR, but as a developer using Arch in Unity, there are a few things I don't agree with.
First, the RuntimeInitializeOnLoad attribute used in the AOT Source Generator works by default with RuntimeInitializeLoadType.AfterSceneLoad. Perhaps this should be done earlier (e.g. RuntimeInitializeLoadType.SubsystemRegistration)?

This is a good point, this should probably not be using AfterSceneLoad. I'm not sure if SubsystemRegistration would be better though than AfterAssembliesLoaded; if there were any components attempting to be registered from external assemblies I'm not sure those types would be resolved. Do you have any strong information that pushes towards using one over the other?
I've pushed up a fix commit that adds a constructor param for AfterAssembliesLoaded.

Also, although this is a rare case, it may be better to use UnityEditor.InitializeOnLoadMethodAttribute in consideration of running it on the editor. (This can be implemented with #if UNITY_EDITOR.)

I'm not sure what your intent would be on making this method call editor only. Since the AOT protection is for types that il2cpp player builds that might strip out unless explicitly referenced, making this editor-only would not result in that outcome. Is there any additional context you can give for why this would need to be editor-only?

Also, in my opinion ISystem should not be implemented by MonoBehaviour or ScriptableObject, the implementation of System should be delegated to pure C# classes.

That's your opinion, but just because thats how you choose to work doesn't necessarily mean it should prevent or make it impossible for other developers to use Arch differently. There are a few good reasons why systems are easier to work with in a Unity way as ScriptableObjects or MonoBehaviors (usually for me SO's are the way to go, but there are times where MBs are impossible to avoid or very difficult).
Serialization
Sometimes it is desirable to provide a developer or designer in Unity the ability to edit fields on a system directly, at edit-time or runtime. By making it possible to build systems as SO's or MB's it's easy to do that.

It also comes with the added advantage that they are very modular when composing and ordering them into a World and this can be done from the Unity editor by anyone (even a designer) rather than only by a programmer in code. I can now build prototype scenes that only use a subset of the overall systems for testing a particular feature where the production scene would reference the ones only needed for the live game.

It's possible to do the serialization part as POCO systems where those systems are serialized directly inline on a Unity SO or MB, but then the grouping/ordering is all done from code only (less ideal).
Third-Party Plugins and/or Implementation Constraints
While I would rather not ever write my systems as MonoBehaviors due to unneeded extra baggage, sometimes it is unavoidable due to third-party plugins or other potential implementation constraints (a system needs access to APIs that are only available to MonoBehaviors).
For example, to create systems using the Shapes library that I use for part of the in-game UX/UI it was best if my systems inherited from their ImmediateModeShapeDrawer type which embeds well in their library and is derived ultimately from MonoBehaviors. Working around this constraint with a POCO class would have been much more complex and onerous.

I also don't think it is appropriate to make such a breaking change as to change the name of the method because of it.

That was also my thought as well (if you read the bottom of the PR, I had been looking for reasonable alternatives to a breaking API change). See the below comment I'd listed there, curious to hear if there are any alternatives that would enable both solutions outside of conditional compilation.

@genaray The only issue with this change from Update to Execute is that it would be a breaking API change and perhaps not necessarily one we'd want to force on everybody for the sake of just Unity developers. I could also instead rework this to conditionally use Execute over Update if something like a Unity constant were added to both System projects, but then this would result in the locally included sample project to fail to compile when a Unity developer locally made those changes. Any thoughts on how you would like to accept changes like these that aim for compatibility with specific engines?

Additionally, there are better solutions such as NugetForUnity regarding how to distribute the dll. (This allows automatic dependency resolution and automatically adds RoslynAnalyzer tag to SourceGenerator.)

I'm not sure what your point here is; providing an easy path for any developer to be able to publish the runtime assemblies locally for easy inclusion in a project doesn't prevent someone else from using something like NugetForUnity. For a developer like myself that is often modifying or augmenting the source for a project (perhaps even for client projects where the changes might not be PR'ed back to the repo), building the assemblies locally is the only solution to enabling that workflow. Using NugetForUnity or even Unity's package manager would not be viable options in that scenario.
I've seen several times on the Discord where users have asked how to build and use Arch or Arch.Extended projects in Unity and these publish profiles would enable them to easily do that (for the latter at least).

I'm not sure what your intent would be on making this method call editor only. Since the AOT protection is for types that il2cpp player builds that might strip out unless explicitly referenced, making this editor-only would not result in that outcome. Is there any additional context you can give for why this would need to be editor-only?

You're right. I was concerned that it would be registered twice in the ComponentRegistry, but by reading the implementation I realized that it was checked.

It's possible to do the serialization part as POCO systems where those systems are serialized directly inline on a Unity SO or MB, but then the grouping/ordering is all done from code only (less ideal).

In ECS, system should not maintain state in the first place. The state should be linked to the entity as a component, and the fact that system serialization is necessary is itself a code smell.
Regarding execution, instead of implementing ISystem with MonoBehaviour, it would be ideal to schedule a pure C# class System on PlayerLoop like Unity ECS.
Also, all system usage should be visible from the code. Although solutions using SO are easy, they become more complex to manage as development progresses. (I have seen projects that failed in the final stage of development as a result of designing with SO as the main focus.)

While I would rather not ever write my systems as MonoBehaviors due to unneeded extra baggage, sometimes it is unavoidable due to third-party plugins or other potential implementation constraints (a system needs access to APIs that are only available to MonoBehaviors).

I don't have Shapes, so I can only guess from information such as documents, but ImmediateModeShapeDrawer is just a wrapper for OnPreRender, and it seems impossible to trigger it at any timing. Is it necessary to forcefully implement ISystem under these constraints? It should be enough to call World.Query() whenever needed.

I'm not sure what your point here is; providing an easy path for any developer to be able to publish the runtime assemblies locally for easy inclusion in a project doesn't prevent someone else from using something like NugetForUnity. For a developer like myself that is often modifying or augmenting the source for a project (perhaps even for client projects where the changes might not be PR'ed back to the repo), building the assemblies locally is the only solution to enabling that workflow. Using NugetForUnity or even Unity's package manager would not be viable options in that scenario.

There was insufficient explanation on this point. What I'm trying to say here is that it's probably more beneficial for most users to use NugetForUnity. Of course, there are times when this PR solution is necessary. However, when describing the installation method on the wiki, it is better to include both.

It's possible to do the serialization part as POCO systems where those systems are serialized directly inline on a Unity SO or MB, but then the grouping/ordering is all done from code only (less ideal).

In ECS, system should not maintain state in the first place. The state should be linked to the entity as a component, and the fact that system serialization is necessary is itself a code smell.

It seems like you're conflating Unity editor serialization (being able to edit fields of an object in the editor) as runtime game state or something like save data serialization (wholly different concepts). In the example screenshot I provided below of one of my selection systems, making it an SO (or even in the example where it's inline as a POCO class) makes it possible for me to provide it what is essentially global game data or even external systems that do not need to live as an ECS-oriented entity or component.

Regarding execution, instead of implementing ISystem with MonoBehaviour, it would be ideal to schedule a pure C# class System on PlayerLoop like Unity ECS.
Also, all system usage should be visible from the code. Although solutions using SO are easy, they become more complex to manage as development progresses. (I have seen projects that failed in the final stage of development as a result of designing with SO as the main focus.)

With all due respect, this seems more like a personal preference or team style than a Unity-wide best practice or requirement for shipping games. We've shipped and maintain several different games/apps with heavy SO usage for context. There are many resources out there about Scriptable Architecture. While I don't agree with your sentiment that everything needs to be in code, this PR isn't trying to prevent you from doing that. It's making it more possible for developers who use a different architectural approach to be able to use Arch more easily.

While I would rather not ever write my systems as MonoBehaviors due to unneeded extra baggage, sometimes it is unavoidable due to third-party plugins or other potential implementation constraints (a system needs access to APIs that are only available to MonoBehaviors).

I don't have Shapes, so I can only guess from information such as documents, but ImmediateModeShapeDrawer is just a wrapper for OnPreRender, and it seems impossible to trigger it at any timing. Is it necessary to forcefully implement ISystem under these constraints? It should be enough to call World.Query() whenever needed.

You're kind of missing the point. If a system has requirements or constraints that make it attractive to be implemented as a  MonoBehavior, this PR is aiming to make that possible whereas attempting to do that now results in the editor crashing. I'd like to try to make changes to make this more easily possible for a Unity developer short of needing to maintain a local fork with these or similar changes and am soliciting for preference/options from @genaray and others interested on how best to do that.

I'm not sure what your point here is; providing an easy path for any developer to be able to publish the runtime assemblies locally for easy inclusion in a project doesn't prevent someone else from using something like NugetForUnity. For a developer like myself that is often modifying or augmenting the source for a project (perhaps even for client projects where the changes might not be PR'ed back to the repo), building the assemblies locally is the only solution to enabling that workflow. Using NugetForUnity or even Unity's package manager would not be viable options in that scenario.

There was insufficient explanation on this point. What I'm trying to say here is that it's probably more beneficial for most users to use NugetForUnity. Of course, there are times when this PR solution is necessary. However, when describing the installation method on the wiki, it is better to include both.

That's what I'm proposing; an easier way for a developer using Rider (pretty common on macOS for Unity development) to be able to publish these assemblies locally with the right settings for them to work in Unity that can live alongside other methods, like Nuget or even a Unity Package Manager distro (I don't think there is one for Arch at the moment).
@AnnulusGames I definitely appreciate your interest and feedback (I've starred a few of your repos!), but wish that it was more open-minded and less reductive towards there being only one way to make games. I'm definitely cognizant that some developers might really dislike ScriptableObjects, but this PR isn't attempting to force you to use them ;)

It seems like you're conflating Unity editor serialization (being able to edit fields of an object in the editor) as runtime game state or something like save data serialization (wholly different concepts). In the example screenshot I provided below of one of my selection systems, making it an SO (or even in the example where it's inline as a POCO class) makes it possible for me to provide it what is essentially global game data or even external systems that do not need to live as an ECS-oriented entity or component.

Ideally, in the context of ECS, all of these should be accessed via components. For example, in Unity ECS, you construct a BlobAsset in the authoring component and pass the BlobAssetReference to the component.
However, I am skeptical that the benefits of this restriction are worth the effort, and it would be easier to use SerializeField directly. (Although this is sufficient for practical purposes, please note that strictly speaking, this is against the philosophy of ECS.)

With all due respect, this seems more like a personal preference or team style than a Unity-wide best practice or requirement for shipping games. We've shipped and maintain several different games/apps with heavy SO usage for context. There are many resources out there about Scriptable Architecture. While I don't agree with your sentiment that everything needs to be in code, this PR isn't trying to prevent you from doing that. It's making it more possible for developers who use a different architectural approach to be able to use Arch more easily.

The concept of ScriptableArchitecture is now considered a bat practice by many developers. (The argument here is a bit extreme, but I generally agree with it.)
As an alternative, my advice based on experience is to use Rx for messaging and a DI container for dependency resolution. However, if it can be maintained, it may be sufficient.
In any case, as you say, it may be in the developer's interest to be able to take multiple approaches. If you want to change the method name, I recommend OnUpdate rather than Execute. (This also matches Unity ECS System.)

Ideally, in the context of ECS, all of these should be accessed via components. For example, in Unity ECS, you construct a BlobAsset in the authoring component and pass the BlobAssetReference to the component.

You kind of have to do it this way with Unity's first-party ECS framework; there aren't other ways provided. Their framework is perhaps not the best to use as an example seeing how it's now considered production-ready, but doesn't have support for animation and other essential features without using third-party paid or open-source plugins.
Just to take this sound example further though, in the event I did want to have specific selection sounds per object I likely would use some kind of flyweight-like pattern where an index or enum value on a component would be used by a system to retrieve the appropriate AudioClip from an external factory. Right now at this early stage of development that's not important.

However, I am skeptical that the benefits of this restriction are worth the effort, and it would be easier to use SerializeField directly. (Although this is sufficient for practical purposes, please note that strictly speaking, this is against the philosophy of ECS.)

You're exactly right here though in that sometimes it's not beneficial for practical reasons to deconstruct every piece of data into components. It's better to not lock yourself into needing to implement everything into an ECS.
Where people get tripped up on ECS as a design pattern is thinking that using it means everything now has to be implemented in that paradigm, even features that don't benefit from it. This is kind of silly when you think about it; it limits the ability to integrate any sort of external functionality outside of the ECS in the game if it can't be boiled down to entities, components, or systems (should localization be implemented as an ECS system for example or is it better served as a non-ECS API?).
ECS is best-used as it benefits a project to be integrated into it and nothing more. It's really great for the simulation and core-game logic portion of my game,  but there are other gameplay systems which maybe only have a tiny representation (like Cinemachine for camera movement/behavior).

**(For those reading this, I would like to add one thing: Serialization of the editor and serialization of save data are, in concept, exactly the same. The only difference is whether it is done by the user or by Unity in the editor. )

They use similar technologies, but thats about it. Making fields on a Unity object serializable enables developers to edit them in the Editor for development purposes. This isn't seen outside by the editor by users much in the way that private fields aren't seen outside of the class by consumers of an object's API.

The concept of ScriptableArchitecture is now considered a bad practice by many developers. (The argument here is a bit extreme, but I generally agree with it.)
As an alternative, my advice based on experience is to use Rx for messaging and a DI container for dependency resolution. However, if it can be maintained, it may be sufficient.

Again, this seems like a very black and white, binary hot-take on a technology when we live in a world of gray. I feel like I've said my piece on different development practices and this PR isn't forcing an approach on others as much as it is giving reasonable options.
I definitely agree with shades of the arguments that developer states (we use a lot of plain C# events alongside scriptable events for example), but I know other people who feel like a lot of DI containers and RX libraries are also unnecessarily complex. It's a great big melting pot of opinions out there!

In any case, as you say, it may be in the developer's interest to be able to take multiple approaches. If you want to change the method name, I recommend OnUpdate rather than Execute. (This also matches Unity ECS System.)

Alternate method names like OnUpdate is a reasonable solution to achieving the same outcome as Execute though it also is a breaking API change. If we were to follow this tract I'd be changing the system/group method names like so:

BeforeUpdate => OnBeforeUpdate
Update => OnUpdate
AfterUpdate => OnAfterUpdate

@genaray is this a reasonable change to you?

What a discussion, it took me a long time to read through all this but I admire your dedication ^^ The only thing that logically worries me are the breaking changes... because arch is now used by many people and that could make some things incompatible. Especially the source generators have to be adapted.
Does Unity really crash if you add more update methods with a different signature? I can hardly imagine it, but I have never tested it. Would it be an alternative to replace the method names with flags? That would only be a breaking change for Unity users who use the source.

What a discussion, it took me a long time to read through all this but I admire your dedication ^^ The only thing that logically worries me are the breaking changes... because arch is now used by many people and that could make some things incompatible. Especially the source generators have to be adapted.

I wouldn't be afraid of breaking changes so much as making sure whatever the new method name is makes sense and doesn't change again for a similar reason. It took me about half an hour to go through and make this example change originally for both System projects, will not take long to adapt to a different name.

Does Unity really crash if you add more update methods with a different signature? I can hardly imagine it, but I have never tested it. Would it be an alternative to replace the method names with flags? That would only be a breaking change for Unity users who use the source.

There are pros and cons. Like @AnnulusGames mentioned it does make for an inconsistency between method names which can be confusing to document in API versus a one-time method name change that applies to everyone. It would also mean the Arch.Extended.Sample wouldn't compile when a user had set the flag to build the system projects for Unity, aka the solution would fail to build while that flag was set (all projects other than the sample would succeed in building).

How sure are we about that crash stuff? Im pretty sure that a monobehaviour can have a e.g. Update(MyCustomClass) method besides the default update method.

How sure are we about that crash stuff? Im pretty sure that a monobehaviour can have a e.g. Update(MyCustomClass) method besides the default update method.

This is an example MB with an overload of Update.
 using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ExampleBadMonoBehaviour : MonoBehaviour
{
	public void Update(float timeDelta)
	{

	}
}

Rider itself will warn that the method overload is wrong for Unity.

On Unity 2022.3.16f1 Unity will show script compiling errors.

Script error (ExampleBadMonoBehaviour): Update() can not take parameters.

In the test project I just ran this in it didn't cause a crash, but in the one I was using Arch in changing these to a non-Unity protected method for the Arch systems I was creating did.
Either way, this just points to it not being an ideal method name choice with Unity in mind.


Example not working:

Warning: Failed propType: Invalid prop trigger supplied to Popover, expected a single ReactElement. Check the render method of ...
import Popover from '@terebentina/react-popover';
import<EMAIL_ADDRESS>export default class NetworkStatPage extends React.Component {
render() {
	return (
		<div>
			If you want to see a nice popover
			<Popover position="bottom" className="awesome" trigger="click me">
				here I am in all my glory!
			</Popover>
		</div>
	);
}

}

This is strange...which version of React?

fixed, sorry for that.


kubelet missing "/var/lib/cni" access

Since 1.5.0, the kubelet looks at files in /var/lib/cni.
See https://github.com/kubernetes/kubernetes/commit/37bc34c567665f5c2a8e8478830acd1d0b3bba37#diff-4df925f5ace9ef618b2650b1d3f740c1R76
Right now, noisy logs are occasionally printed and it's possible for ips to be leaked.

cc @chancez

This repo isn't maintained any longer, closing.


Show Kubernetes events in UI

kubectl get events --all-namespaces --watch can often be used to quickly indicate something that is wrong with the cluster, it could be useful if we can show the events stream in the UI.

It would also be nice to see the events per namespace, for example Quota errors are not directly attached to a Deployment/Pod and not visible in Rancher UI:
kubectl.exe -n appll-test get events
LAST SEEN   FIRST SEEN   COUNT     NAME                                                    KIND         SUBOBJECT   TYPE      REASON         SOURCE                  MESSAGE
51m         51m          1         app-service-558d78f8f.159681c0a4f38125   ReplicaSet               Warning   FailedCreate   replicaset-controller   Error creating: pods "app-service-558d78f8f-8dsql" is forbidden: exceeded quota: test-quota, requested: requests.memory=2Gi, used: requests.memory=2Gi, limited: requests.memory=3Gi

Version: master-head (v2.3) (9/13/19)
Now there is an "Events" pane when viewing the cluster dashboard. This lists kubectl events. They are also listed by namespaces and you can sort like most tables in the UI.
I didn't spot any issues while testing, except I think it would be ideal if we could limit how many events per page i.e. if it honored our max count per page like in the user settings:

This is because the list can be rather long. I created a separate issue to request this here: https://github.com/rancher/rancher/issues/22858
Example screenshot of this new area on the cluster dashboard (note, text is shown smaller than usual as I zoomed out in my browser):

As events come in, this will update in the UI. The update happens about every 10 seconds.

Hi @davidnuzik I am not able to see Rancher Events on the UI. Can you please suggest to me how to enable those events?


Failing to creation migration because of FK constraint on entity not in DbSets

Describe what is not working as expected.
I'm attempting to create and apply migrations of my code to my database. Unfortunately, I keep getting the error described below. Oddly, it's referring to an entity that I do use within a context, but not within the context for which I'm creating this migration. I've thoroughly checked all the entities I'm specifying across my DbSets in this context and there's no mention of X or Y in any of them, yet I keep getting these constraint errors.
Further, if I just add an ignore (e.g. modelBuilder.Entity<X().Ignore(a => a.Y)), it resolves the constraint error, but gives me another instead which is just another property on X or a whole other class altogether which is also not included anywhere in this context.
I wouldn't expect to see any constraint errors regarding classes and properties that aren't specified in the DbSets or in the properties thereof.
**Error:**
Introducing FOREIGN KEY constraint 'FK_X_Y_Z' on table 'X' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or  ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.

**Stack trace:**
 (0x80131904): Introducing FOREIGN KEY constraint 'FK_X_Y_Z' on table 'X' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint or index. See previous errors.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite, String methodName)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.Execute(IRelationalConnection connection, DbCommandMethod executeMethod, IReadOnlyDictionary`2 parameterValues)
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary`2 parameterValues)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.ExecuteNonQuery(IEnumerable`1 migrationCommands, IRelationalConnection connection)
   at Microsoft.EntityFrameworkCore.Storage.RelationalDatabaseCreator.EnsureCreated()
   at xyz`1 options) in L:\...\X.cs:line 32
   at TenantContextFactory.CreateDbContext(String[] args) in L:\...\TenantContextFactory.cs:line 22
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(Func`1 factory)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(String contextType)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
ClientConnectionId:266887b5-3d26-4587-8e45-4b1ec6e39ec9
Error Number:1785,State:0,Class:16

Steps to reproduce
Unable to provide a solution demonstrating this issue at this time, but here's a brief idea of what I'm seeing:
public class A {
  [Key]
  int Id {get;set;}
}

public class B {
  [Key]
  int Id {get;set;}
}

public class C {
  [Key]
  int Id {get;set;}
  List<D> Things {get;set;}
}

[Owned]
public class D {
  [Key]
  int Id {get;set;}
  int CId {get;set;}
}

//Within my context.cs

//...
public DbSet<A> A {get;set;}
public DbSet<B> B {get;set;}

Following this example I'm then seeing an error along the lines of the following:
Introducing FOREIGN KEY constraint 'FK_C_D_CId' on table 'C' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or  ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.

Of course this doesn't make any sense because I'm not actually using C or D anywhere in this context.
Further technical details
EF Core version: 2.2.4
Microsoft.EntityFrameworkCore.Design: 2.2.4
Database Provider: 2.2.4
Operating system: Windows 10 Pro 64-bit
IDE: Visual Studio 2019 Pro

@WhitWaldo Are you 100% certain that the entity types you're not expecting in the model are not referenced (through either collection or reference navigation properties) from entity types that are in the model? This is the only thing I can think of that would cause this, so I suspect if that's not the case then we're going to need more information to reproduce what you are seeing.

@ajcvickers You're right - there was a reference to the other properties 6 entities deep on one of the items. Thanks!


concurrent-ruby deprecated feature

I just noticed that this project uses concurrent-ruby. I am the creator and lead maintainer of that project. I see in your gemspec that we've deprecated a feature you depend on. I'm sorry that we've caused you problems but I'd love to help you find a solution. I'm even willing to add new features if need be. Is there anything I can do to help?

:+1:

Concurrent::ReadWriteLock was released in 0.9.0 and the original author made performance optimizations in 0.9.1. If we can solve your deprecation issue you should be able to replace lib/volt/utils/read_write_lock.rb with our version.

AFAICT the deprecated feature was our (buggy and inefficient) timeout method. It was used in the dispatch_in_thread method of lib/volt/tasks/dispatcher.rb. That has been replaced with the timeout method from Ruby's standard library. If that's the case then you should be able to safely upgrade. Rails currently uses 1.0.0.pre3. We will release 1.0 prior to RubyConf (myself and another team member are both speaking).
We may be able to replace that instance of timeout with a c-r Future. The timeout method in Ruby's standard library spawns a new thread, making it very inefficient. If we perform the block on line 117 in a Future the we can put a timeout on the action and the job will post to our global thread pool, which should be more efficient and more stable.
I'll try to create a PR this afternoon for you to look at.
I also notice that you use thread local variables. In c-r 0.9.1 we released our own implementation of Concurrent::ThreadLocalVar. It was written by the same developer who created Concurrent::ReadWriteLock. It is more efficient than the standard library implementation. It's worth considering in the future.

@jdantonio thanks for the help.  A PR would be great, let me know if I can help.  Yea, timeout is the feature that I was using, and I had the same thoughts about standard timeout spawning new threads.  Basically we need a worker pool with a timeout.  Thanks for all of the great work on concurrent-ruby.
Also, I'll check out ThreadLocalVar,

@ryanstout I think we can make that work. Possibly simplify the code in the process. All of our high-level abstractions post to global thread pools, and most offer methods with timeout. More importantly, most of our high-level abstractions also allow the specific thread pool for execution to be configured via dependency injection. So instead of posting directly to @worker_pool in the dispatch method we could do something like this:
task = Concurrent::Future.execute(executor: @worker_pool)
task.wait(@worker_timeout)

I know that the specific implementation will be more complicated than that, but this is the basic idea. There are other options, too. We also have actors and agents. I'll work on it and submit another PR once I get something working.

@jdantonio thanks again, I owe you one.  Let me know if I can help.  Having timeouts without spinning up a new thread would be great.

PRs #311, #312, and #313 submitted.


Publish VS Code extension

We should actually publish the extension now that Smithy is GA. This extension still doesn't do much, but it would be easier to get syntax highlighting.

+1 What's needed to do this? How can I help?

This extension can now be installed from the Marketplace: https://marketplace.visualstudio.com/items?itemName=Smithy.smithy-vscode-extension


Add IsScalar / IsVector (rank) checks to input min/max tensors for Fa…

…keQuantWithMinMaxVarsPerChannelGradientOp and FakeQuantWithMinMaxVarsGradientOp.
PiperOrigin-RevId: 462542629

Also, this one has a conflict to resolve.


Menuitem

The module is working fine for me in the beta, but one thing is important:
Now the user see a menuitem but can't enter it. It should be only displayed for admin in the menu.

The menu itme should only be visible for the administrator users. Today it is visible for everybody, but if a "normal" user click's on it he/she get an error message.

It's build for our internal translation site which can be used by "non-administrative" users.


Refactor image

This is the first step towards error handling. Which lead me into a bit of a refactoring trip field trip.
Anyways, this enables us to easily integrate the functionality that @marc-barry wants to introduce with https://github.com/Shopify/kubeaudit/pull/20 but in a nicer way. I will update the PR once this one is merged.
This removes some splitting code with wasn't nice and os.Exit(1) from a function where it's way too late to do an os.Exit for a cmd line param check.

[x] fix the commit message before merge to master
[ ] squash commits

For more context on the above comment https://goreportcard.com/report/github.com/Shopify/kubeaudit

I just squashed the commits.


Fix edge cases in link check

Add processing for HTML link IDs in format ## Title for ID.
Replacer now replaces ?.
Replacer doesn't replace _ anymore as that's a valid char for a tile.

Checked locally by validating this repo/commit: nanoframework/nanoframework.github.io
Fixing issues wrongly reported in this build: https://dev.azure.com/nanoframework/nanoframework docs/_build/results?buildId=38903&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=72c3483f-759b-5fe1-97d0-7523409e045c
D:\a\1\s\content\architecture\simplifications-and-trade-offs.md 33:123
In doc link was not found 'string-format-examples.md#d-decimal'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\architecture\simplifications-and-trade-offs.md 34:127
In doc link was not found 'string-format-examples.md#f-fixed-point'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\architecture\simplifications-and-trade-offs.md 35:123
In doc link was not found 'string-format-examples.md#g-general'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\architecture\simplifications-and-trade-offs.md 36:122
In doc link was not found 'string-format-examples.md#n-number'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\architecture\simplifications-and-trade-offs.md 37:127
In doc link was not found 'string-format-examples.md#x-hexadecimal'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\building\cmake-presets.md 13:21
In doc link was not found '../faq/automatic-firmware-updates.md#how-to-prevent-a-board-from-updating-if-working-on-a-custom-firmware'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\building\cmake-presets.md 14:36
In doc link was not found 'build-instructions.md#build_version-matching'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\building\cmake-presets.md 112:61
In doc link was not found '../architecture/wire-protocol.md#crc32-validatons'. Make sure you have all lowercase, remove '*' and replace spaces by '-'.
D:\a\1\s\content\contributing\contributing-workflow.md 91:22

Any source document that breaks to 1: be able to test, 2: understand if that's already formed correctly :-)

As for docfx support for HTML links: https://dotnet.github.io/docfx/tutorial/links_and_cross_references.html#links-in-inline-html

So for the record, this pattern seems to be the issue that your PR is fixing:

For example in this file: https://github.com/nanoframework/nanoframework.github.io/blob/pages-source/content/architecture/simplifications-and-trade-offs.md

Dropping PR.


tailscale: 1.40.1 -> 1.42.0

Description of changes
https://github.com/tailscale/tailscale/releases/tag/v1.42.0
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 234161 run on x86_64-linux 1

2 packages built:

tailscale
trayscale


The file "" does not exist

Version information

Laravel: v5.7
Voyager: v1.1
PHP: 7.3
Database: MariaDB
Storage: AWS S3

Description

I'm trying to upload an image but I have:
{success: false, message: "The file "" does not exist", path: ""}
Steps To Reproduce
Steps to reproduce the behavior:

Go to 'Media manager'
Click on 'Upload'
Select an image

Screenshots

There's already an issue similar to yours, please share your information there: https://github.com/the-control-group/voyager/issues/1711


What long values are sent with EveryUpdate and EveryFixedUpdate

I couldn't find this in the documentation anywhere, and digging through the code didn't give me any answers, either.  Thanks for any insight.

It is count per subscription.
first = 0, second = 1, third = 2, ...
You can check it.
Observable.EveryUpdate().Subscribe(x => Debug.Log("A:" + x));

Observable.Timer(TimeSpan.FromSeconds(3)).Subscribe(__ =>
{
    Observable.EveryUpdate().Subscribe(x => Debug.Log("B:" + x));
});


Proguard Error with LoganSquare 1.3.3

Warning: com.bluelinelabs.logansquare.JsonMapperLoaderImpl: can't find referenced method 'com.bluelinelabs.logansquare.JsonMapper getMapper(java.lang.Class)' in library class com.bluelinelabs.logansquare.LoganSquare
Warning: there were 1 unresolved references to library class members.
         You probably need to update the library versions.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':common:proguardLibraryRelease'.
> java.io.IOException: Please correct the above warnings first.

Do you have the following 3 lines in your proguard config file?
-keep class com.bluelinelabs.logansquare.** { *; }
-keep @com.bluelinelabs.logansquare.annotation.JsonObject class *
-keep class **$$JsonObjectMapper { *; }

The first line should make sure nothing in JsonMapperLoaderImpl gets obfuscated away.

@EricKuck I've put those lines into the proguard rules but no luck. After adding
-dontwarn com.bluelinelabs.**

make everything works again.


NEXT-8427 - EAN rename to GTIN

1. What does this change do, exactly?
2. Describe each step to reproduce the issue or behaviour.
3. Checklist

[ ] I have written tests and verified that they fail without my change
[ ] I have squashed any insignificant commits
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[ ] I have read the contribution requirements and fulfil them.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.jens.brunken seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

new commit with the changes

we are currently discussing if renaming the snippet keys is a break :see_no_evil:
we will let you know

Is there any reason this PR doesn't fix all occurrences?

we are currently discussing if renaming the snippet keys is a break 🙈
we will let you know

Idea: adding NEW key with gtin in name and mark old one deprecated in changelog?

As not all snippets of ean are changed, I will close this PR. Feel free to create an additional new one at shopware/platform


Change the execution order of the plugins so that UserDataPlugin is executed last

As the userdata scripts can interfere with other cloudbaseinit plugins, it is preferable to have all the other plugins executed before the start of the UserDataPlugin.
One other reason is that the userdata plugins can contain logic that is based on the other plugins.
Furthermore, the logic in the userdata cannot be foreseen. For example, if the userdata code contains logic for a domain controller installation, the SetUserPasswordPlugin and ConfigWinRMListenerPlugin will fail. The user password expiration cannot be set, as .the "Admin" user is not a local user anymore, it is a domain one(possible quickfix: https://github.com/ionutbalutoiu/cloudbase-init/commit/2275d9eb5d6c83b5775e369c41c6c3385483b876).

Since the project is moved to StackForge, we are going to mark the issue as closed here.


Request: Suggested migration from seanmcbreen.spell

Hi,
I'm the author of: https://marketplace.visualstudio.com/items?itemName=seanmcbreen.Spell and a member of the VS Code team.
The backing service for the extension has been failing for some time now and I've reached the point where I really have to remove it.  As part of this I was thinking of pointing user to your extension.
I'm imagining sending out an update that suggests via an info message to uninstall and use your one - and then later on an update removing all functionality - eventually resulting in unpublishing the extension.
Are you ok with that?  I imagine it could give you an influx of users (as well as some new issues).
To be completely transparent we are looking to include additional support for spell checking in the core VS Code product at some point but for now I think your extension is the best one out there.
Sean

Hi Sean,
I feel honored.  I think your extension has been an inspiration for many people.
This extension is a fun side project.  I moved to VS Code from IntelliJ.  VS Code is 1000x better with Typescript.  The thing I missed the most was a spell checker.  I tried your extension first, but then realized it was for plain text and markdown.  So, I used yours as an example on how to write my own.  Thank you for that.
I would welcome the influx of users.  I think the basis is now in place.  Most of the improvement have to do with ease of configuration and adding new languages.
BTW: I used to work for Microsoft.  I was there from 1995 through 2003 when I left to travel the world.

Ok, that's great news - I may look at starting this process tomorrow.
That said I'm actually on Holiday next week so may run out of time.
I really like many of the cool innovations in your extension so I think people will enjoy using it.
I'll close this issue - and update it once I publish the next update.
Thank you for supporting VS Code!
Sean

Sorry for the slow reply here - we are currently working on this for the core product.  As a result I've held off any change to my extension.
If we do add to the core I think that is my preferred migration path for users.
A good discussion of this is happening over here:
https://github.com/Microsoft/vscode/issues/20266
This happened faster that I was thinking it would.  So I'm sorry if I messed you around at all.
I'm very impressed with the work you have done and I bet there will be several area yuo cover we will not e.g. the summary view you have.
Sean

Got it.  Thank you for keeping me updated.

Hi Jason,
A spellchecker is still some way for for VS Code (we are right now focused on driving down some bug and other debt) so I pulled the trigger on updating my extension to point to your one.
Let me know if you have any issues/concerns.  I updated the README with a few details.
Sean


Create share page

That's the first thing needed before we can go live with this new website.

Very simple one has been created, could be prettified though.


Determine what is the standard of excellent training

In the process of AI training, I found that the value of "learning_rate" is declining continuously, and I don’t understand what is the standard of good judgment for training.

These are some valid outputs:
learning rate: 6.5909583485014e-05
{
loss: 0.00014185911949735
MSE: 0.00027230762299661
PSNR: 35.889340583873
}

The training process minimizes loss.
PSNR is a common image quality metric. The larger it is, the better.
https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio

I found that a lot of details were lost during the training of noise reduction level 3. I used many similar noise-free original images as training materials, but after a long period of training, the learning rate has been as low as 1.9746390125668e-06, and the details are still not improved. For the same picture, compared with the noise reduction level 3 of the cnet model, the noise reduction level 3 of the cnet retains more details. Will repeated training improve the level of detail?

There is a trade-off between denoising and preserving details.
A smaller value for -nr_rate(default 0.65) preserves more detail.
However, I have specified -nr_rate 1 for training noise3 because noise3 doesn't need to preserve the details I think.
The other reason that comes to mind is that I mix the following dot pattern in the training data, about 2% of the total. It helps to train to preserve the details.

This dot pattern can be generated by the following command.
mkdir -p ./dots
th image_generators/dots/gen.lua -n 128 -o ./dots


Track recent breaking changes in exceptions.net*.json files

This repo contains untracked breaking changes. To find and address them

Revert 387e2d8
Run .\build.cmd /t:Pack in projects 387e2d8 touched or .\build.cmd /t:Package in the repo root
Update exceptions.net45.json and exceptions.netcore.json to track the changes
If not already announced, suggest filing issues at https://github.com/aspnet/Announcements

Moving to preview2.


Replace usage of get() to lazy for sharepreferences

Task/Issue URL: https://app.asana.com/0/488551667048375/1204694630980114/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3215   👈

This comment was auto-generated by Graphite.


screen recording

please i want a simple script like this for screen recording not something with a button to start and stop recording

[please i want a simple script like this for screen recording not something with a button to start and stop recording
](url)


Issue:- the file tested on 10.15 machine, This mac is 11.2

unable to update security patch

Hi! Could you give a little more information on the issue you're running into and which version of macOS your Mac is running? I'd recommend giving the latest release a try, which adds more customization options and improves stability on Apple Silicon Macs. Also, if you're editing the script for your environment, give the unmodified release a try and see if it behaves any better, as that can sometimes reveal issues with script modifications or deployment methods. Keep me posted!

The New release is giving an error. We have a locked software update option in system preferences, it's, again and again, poping up to go there. Screenshot attached. one more thing " sudo softwareupdate -a -i --restart" is working fine. but need to create policy in JamF.

Oh interesting. This workflow didn't take into account that folks might be blocking the Software Update preference. You could change the wording of the alert text to remove references to the manual update option if you don't want to direct folks there, at least on Intel Macs; Apple Silicon Macs will need the user to manually apply the update via the System Preferences UI; see the README for the rationale behind this behavior.

Added a note to Limitations on the README to clarify that running this script on Apple Silicon Macs requires the user to have a secure token, volume ownership, and the ability to open the Software Update preference pane. Thanks for flagging this behavior!


Add missing controllers and broadcasters to ros2_controllers dependencies

This PR adds missing dependencies of new controllers and broadcasters in ros2_controllers package

Humble needs a different patch, we don't have the parallel gripper controller there.

Humble needs a different patch, we don't have the parallel gripper controller there.

Sure. I can create a backport manually.


gb vendor fetch -tag, doesn't fetch tag if supplied with --no-recurse

Almost opposite of #270:
$ gb vendor fetch --tag v0.9.9 --no-recurse github.com/aws/aws-sdk-go

$ cat vendor/manifest
{
	"version": 0,
	"dependencies": [
		{
			"importpath": "github.com/aws/aws-sdk-go",
			"repository": "https://github.com/aws/aws-sdk-go",
			"revision": "7553d5227962c0f226768d0435881e99ec0cab35",
			"branch": "master"
		}
	]
}%

Yet, allowing recursion, gb vendor fetch -tag, works as expected:
$ gb vendor fetch -tag v0.9.9 github.com/aws/aws-sdk-go
....
╰─$ cat vendor/manifest
{
	"version": 0,
	"dependencies": [
		{
			"importpath": "github.com/aws/aws-sdk-go",
			"repository": "https://github.com/aws/aws-sdk-go",
			"revision": "c4ae871ffc03691a7b039fa751a1e7afee56e920",
			"branch": "HEAD"
		},
......

Not too critical of a bug, as I can keep recursion in until fixed, just increases the size of the project.
Thanks for the awesome tool!

--tag and --no-recurse are not flags, sorry. Can you retry your original
example with -tag and -no-recurse
On Thu, Sep 24, 2015 at 7:13 AM, Jake Champlin<EMAIL_ADDRESS>wrote:

Almost opposite of #270 https://github.com/constabulary/gb/issues/270:
$ gb vendor fetch --tag v0.9.9 --no-recurse github.com/aws/aws-sdk-go
$ cat vendor/manifest
{
"version": 0,
"dependencies": [
{
"importpath": "github.com/aws/aws-sdk-go",
"repository": "https://github.com/aws/aws-sdk-go",
"revision": "7553d5227962c0f226768d0435881e99ec0cab35",
"branch": "master"
}
]
}%
Yet, allowing recursion, gb vendor fetch -tag, works as expected:
$ gb vendor fetch -tag v0.9.9 github.com/aws/aws-sdk-go
....
╰─$ cat vendor/manifest
{
"version": 0,
"dependencies": [
{
"importpath": "github.com/aws/aws-sdk-go",
"repository": "https://github.com/aws/aws-sdk-go",
"revision": "c4ae871ffc03691a7b039fa751a1e7afee56e920",
"branch": "HEAD"
},
......
Not too critical of a bug, as I can keep recursion in until fixed, just
increases the size of the project.
Thanks for the awesome tool!
—
Reply to this email directly or view it on GitHub
https://github.com/constabulary/gb/issues/410.

sorry, must have typed/copied them wrong
$ gb vendor fetch -tag v0.9.9 -no-recurse github.com/aws/aws-sdk-go

$ cat vendor/manifest
{
	"version": 0,
	"dependencies": [
		{
			"importpath": "github.com/aws/aws-sdk-go",
			"repository": "https://github.com/aws/aws-sdk-go",
			"revision": "7553d5227962c0f226768d0435881e99ec0cab35",
			"branch": "master"
		}
	]
}%

Looks like it may be from here: https://github.com/constabulary/gb/blob/master/cmd/gb-vendor/fetch.go#L108

Pardon my ignorance though, first use of gb. Does convention stand that I should include recursive dependencies on a project anyways?

I'm not sure I understand.
On Thu, Sep 24, 2015 at 9:24 AM, Jake Champlin<EMAIL_ADDRESS>wrote:

Pardon my ignorance though, first use of gb. Does convention stand that I
should include recursive dependencies on a project anyways?
—
Reply to this email directly or view it on GitHub
https://github.com/constabulary/gb/issues/410#issuecomment-142758620.

What I mean to say is, the contents of $project/vendor/src represent the
set of all packages required either directly or transitively from the code
in $project/src. I think the simplest answer to your question is, yes.
On Thu, Sep 24, 2015 at 9:26 AM, Dave Cheney<EMAIL_ADDRESS>wrote:

I'm not sure I understand.
On Thu, Sep 24, 2015 at 9:24 AM, Jake Champlin<EMAIL_ADDRESS>wrote:

Pardon my ignorance though, first use of gb. Does convention stand that
I should include recursive dependencies on a project anyways?
—
Reply to this email directly or view it on GitHub
https://github.com/constabulary/gb/issues/410#issuecomment-142758620.

Okay cool, thank you

Awesome, thanks!


Fix theme in readme for code?

The current python code in README is a bit off-putting, I wonder why. Documenting the issue here so that we fix it:
Here is an image, notice the underline and pretty much no color theme:

It seems that the issue is on github side: https://github.com/orgs/community/discussions/86715
A solution would be to rewrite the readme in Markdown (instead of .rst) but that would also require some update on the doc setup as well.