Fix build errors when inheriting RCTAppDelegate in Swift modules

Summary
When inheriting RCTAppDelegate in a module with swift code, the compiler will have a build error when it goes through module headers. because swift does not support cxx headers. we found this issue when we try to inherit the class at Expo's EXAppDelegateWrapper with RCTAppDelegate in new architecture mode.
Changelog
[IOS][FIXED] - Fix build errors when inheriting RCTAppDelegate in Swift modules
Test Plan

ci passed
tested with expo's setup: https://github.com/expo/expo/pull/20470

@cipolleschi would be appreciated if you can review this pr when you get a chance 🙇♂

This fix looks more a cure for a symptom rather than the cure for the cause.
When RCT_NEW_ARCH_ENABLED==1, we have to use C++ compiler, so I expected that the __cplusplus flag was already enabled (making this addition a no-op, basically). It feels to me that, if that's not the case, we are actually missing a global configuration. If we proceed with this fix, we may solve this symptom, but the problem could manifest again in the future in other files.
Can we try to understand what's going on and see if we can fix it at the root cause? 🙏

let me share the detailed error log:
CompileC /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/Objects-normal/x86_64/EXReactDelegateWrapper.o /Users/kudo/RNNext/node_modules/expo-modules-core/ios/ReactDelegates/EXReactDelegateWrapper.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler (in target 'ExpoModulesCore' from project 'Pods')
    cd /Users/kudo/RNNext/ios/Pods
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -target x86_64-apple-ios13.0-simulator -fmessage-length\=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -std\=gnu11 -fobjc-arc -fmodules -fmodules-cache-path\=/Users/kudo/Library/Developer/Xcode/DerivedData/ModuleCache.noindex -fmodules-prune-interval\=86400 -fmodules-prune-after\=345600 -fbuild-session-file\=/Users/kudo/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror\=non-modular-include-in-framework-module -fmodule-name\=ExpoModulesCore -Wno-trigraphs -fpascal-strings -Os -fno-common -Wno-missing-field-initializers -Wno-missing-prototypes -Werror\=return-type -Wdocumentation -Wunreachable-code -Wno-implicit-atomic-properties -Werror\=deprecated-objc-isa-usage -Wno-objc-interface-ivars -Werror\=objc-root-class -Wno-arc-repeated-use-of-weak -Wimplicit-retain-self -Wduplicate-method-match -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wno-float-conversion -Wnon-literal-null-conversion -Wobjc-literal-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wdeprecated-implementations -Wno-implicit-fallthrough -DPOD_CONFIGURATION_RELEASE\=1 -DCOCOAPODS\=1 -DNS_BLOCK_ASSERTIONS\=1 -DOBJC_OLD_DISPATCH_PROTOTYPES\=0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.2.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -Winfinite-recursion -Wcomma -Wblock-capture-autoreleasing -Wstrict-prototypes -Wno-semicolon-before-method-body -Wunguarded-availability -fobjc-abi-version\=2 -fobjc-legacy-dispatch -iquote /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/ExpoModulesCore-generated-files.hmap -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/ExpoModulesCore-own-target-headers.hmap -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/ExpoModulesCore-all-non-framework-target-headers.hmap -ivfsoverlay /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/all-product-headers.yaml -iquote /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/ExpoModulesCore-project-headers.hmap -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Products/Release-iphonesimulator/ExpoModulesCore/include -I/Users/kudo/RNNext/ios/Pods/Headers/Private -I/Users/kudo/RNNext/ios/Pods/Headers/Private/ExpoModulesCore -I/Users/kudo/RNNext/ios/Pods/Headers/Public -I/Users/kudo/RNNext/ios/Pods/Headers/Public/DoubleConversion -I/Users/kudo/RNNext/ios/Pods/Headers/Public/ExpoModulesCore -I/Users/kudo/RNNext/ios/Pods/Headers/Public/FBLazyVector -I/Users/kudo/RNNext/ios/Pods/Headers/Public/RCT-Folly -I/Users/kudo/RNNext/ios/Pods/Headers/Public/RCTRequired -I/Users/kudo/RNNext/ios/Pods/Headers/Public/RCTTypeSafety -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-Codegen -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-Core -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-Fabric -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-RCTFabric -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-callinvoker -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-cxxreact -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-graphics -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-jsi -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-jsiexecutor -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-jsinspector -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-logger -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-perflogger -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-runtimeexecutor -I/Users/kudo/RNNext/ios/Pods/Headers/Public/ReactCommon -I/Users/kudo/RNNext/ios/Pods/Headers/Public/Yoga -I/Users/kudo/RNNext/ios/Pods/Headers/Public/fmt -I/Users/kudo/RNNext/ios/Pods/Headers/Public/glog -I/Users/kudo/RNNext/ios/Pods/Headers/Public/hermes-engine -I/Users/kudo/RNNext/ios/Pods/boost -I/Users/kudo/RNNext/ios/Pods/DoubleConversion -I/Users/kudo/RNNext/ios/Pods/RCT-Folly -I/Users/kudo/RNNext/ios/Pods/Headers/Public/React-hermes -I/Users/kudo/RNNext/ios/Pods/Headers/Public/hermes-engine -I/Users/kudo/RNNext/ios/Pods/Headers/Private/React-Core -I/Users/kudo/RNNext/ios/Pods/Headers/Private/React-bridging/react/bridging -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Products/Release-iphonesimulator/React-bridging/react_bridging.framework/Headers -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/DerivedSources-normal/x86_64 -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/DerivedSources/x86_64 -I/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/DerivedSources -F/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Products/Release-iphonesimulator/ExpoModulesCore -F/Users/kudo/RNNext/ios/Pods/hermes-engine/destroot/Library/Frameworks/universal -F/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Products/Release-iphonesimulator/XCFrameworkIntermediates/hermes-engine/Pre-built -F/Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Products/Release-iphonesimulator/React-hermes -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/RCTTypeSafety/RCTTypeSafety.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/React-Core/React/React-Core.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/React-RCTFabric/RCTFabric/React-RCTFabric.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/ReactCommon/ReactCommon.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/React_Codegen/React-Codegen.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/React_RCTAppDelegate/React-RCTAppDelegate.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/folly/RCT-Folly.modulemap -fmodule-map-file\=/Users/kudo/RNNext/ios/Pods/Headers/Public/yoga/Yoga.modulemap -DFOLLY_NO_CONFIG -DFOLLY_MOBILE\=1 -DFOLLY_USE_LIBCPP\=1 -Wno-comma -Wno-shorten-64-to-32 -DREACT_NATIVE_MINOR_VERSION\=71 -DRN_FABRIC_ENABLED -DRCT_NEW_ARCH_ENABLED -include /Users/kudo/RNNext/ios/Pods/Target\ Support\ Files/ExpoModulesCore/ExpoModulesCore-prefix.pch -MMD -MT dependencies -MF /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/Objects-normal/x86_64/EXReactDelegateWrapper.d --serialize-diagnostics /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/Objects-normal/x86_64/EXReactDelegateWrapper.dia -c /Users/kudo/RNNext/node_modules/expo-modules-core/ios/ReactDelegates/EXReactDelegateWrapper.m -o /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/Objects-normal/x86_64/EXReactDelegateWrapper.o

In file included from /Users/kudo/RNNext/node_modules/expo-modules-core/ios/ReactDelegates/EXReactDelegateWrapper.m:6:
In file included from /Users/kudo/RNNext/node_modules/expo-modules-core/ios/ReactDelegates/EXReactDelegateWrapper+Private.h:3:
In file included from /Users/kudo/RNNext/node_modules/expo-modules-core/ios/Swift.h:13:
In file included from /Users/kudo/Library/Developer/Xcode/DerivedData/RNNext-dgsfutaofrmtlgfznlavduhdrrvo/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/ExpoModulesCore.build/DerivedSources/ExpoModulesCore-Swift.h:763:
In file included from /Users/kudo/RNNext/node_modules/expo-modules-core/ios/ExpoModulesCore.h:12:
In file included from /Users/kudo/RNNext/ios/Pods/Target Support Files/ExpoModulesCore/ExpoModulesCore-umbrella.h:14:
In file included from /Users/kudo/RNNext/node_modules/expo-modules-core/ios/AppDelegates/EXAppDelegateWrapper.h:7:
In file included from /Users/kudo/RNNext/ios/Pods/Headers/Private/React-RCTAppDelegate/RCTAppDelegate.h:14:
/Users/kudo/RNNext/ios/Pods/Headers/Private/React-Core/React/RCTCxxBridgeDelegate.h:8:10: fatal error: 'memory' file not found
#include <memory>
         ^~~~~~~~

in a nut shell, ExpoModulesCore-umbrella.h (to build a clang module) -> EXAppDelegateWrapper.h -> RCTAppDelegate.h -> RCTCxxBridgeDelegate.h. the compiler is clang -x objective-c which doesn't support c++.
i could also upload the RNNext project to github for you if you want to investigate further.

I think that that's the problem. We can't build New Architecture files using Objective-C, we need to use Objective-C++. That's why the files are .mm and not just .m.
Have you tried to set the compiler to c++17? Looking at here it should be possible. Also this post seems useful.

Can't you rename all those .m to .mm?

then we should rename all .m to .mm even those .m doesn't import RCTAppDelegate. that is not quite correct.

NewArch enabled/disabled.

yes you are right, the only problem is when RCT_NEW_ARCH_ENABLED=1
Minimal Reproducible Example
well, to demonstrate the complicated problem, i've tried to have a minimal reproducible example with create-react-native-library. you could check with my repo here: https://github.com/Kudo/test-swift-module
Steps:

yarn
cd example ; open ios/TestSwiftModuleExample.xcworkspace

i have my repro in commit history: https://github.com/Kudo/test-swift-module/commits/main

https://github.com/Kudo/test-swift-module/commit/440e163400 - the repro. it's little complicated:

TestSwiftModule is a module with objective-c and swift interoperability
ObjcSwiftInterop.m calls to TestSwiftModule.swift, so it needs the TestSwiftModule-Swift.h swift generated header.
TestSwiftModule.swift inherits ObjcMultiply.m, so it needs the TestSwiftModule.h and TestSwiftModule-umbrella.h. and in the swift generated header, e.g. "$HOME/Library/Developer/Xcode/DerivedData/TestSwiftModuleExample-doouuozeuqeyrrcincfceivjjjbt/Build/Products/Debug-iphonesimulator/TestSwiftModule/Swift Compatibility Header/TestSwiftModule-Swift.h", it has the #import <TestSwiftModule/TestSwiftModule.h> import.
CustomAppDelegate.h is an independent class which is nothing to do with other classes, and it has .mm already.
you could try to build the project when git checkout  440e163400. the error chain is from ObjcSwiftInterop.m -> TestSwiftModule-Swift.h -> TestSwiftModule.h -> TestSwiftModule-umbrella.h -> CustomAppDelegate.h -> RCTAppDelegate.h -> RCTCxxBridgeDelegate.h

https://github.com/Kudo/test-swift-module/commit/17fe4b5 we may need DEFINES_MODULE in RCTAppDelegate for swift integration
https://github.com/Kudo/test-swift-module/commit/b44909e we can add #if __cplusplus in CustomAppDelegate.h, but there's a build error from main.m
https://github.com/Kudo/test-swift-module/commit/3e51058 - change main.m -> main.mm works
https://github.com/Kudo/test-swift-module/commit/db21524 - if we don't touch main.m, the workaround i am going to have.

Conclusion
even though most module doesn't have such complicated objc <-> swift mixed code. i think there is a problem from react-native currently. when building main.m even in new architecture mode, we don't pass RCT_NEW_ARCH_ENABLED=1 compiler flag, that AppDelegate.h is different when building main.m and AppDelegate.mm. it is coincidently work because we only pass NSStringFromClass([AppDelegate class]) in main.m.
i'll leave a problem and discuss here. maybe we don't have to land this pr as we could apply the workaround internally.

Something feels off, to me.

when building main.m even in new architecture mode, we don't pass RCT_NEW_ARCH_ENABLED=1 compiler flag, that AppDelegate.h is different when building main.m and AppDelegate.mm.

The RCT_NEW_ARCH_ENABLED=1 is set at project level by Cocoapods. Here the post install phase and here the logic
If pod install is invoked with RCT_NEW_ARCH_ENABLED=1, this works
If pod install are installed using the parameters of use_react_native!, this line should take care of setting the environment variable.
When RCT_NEW_ARCH_ENABLED=1, the __cplusplus flag must be true as well (so the suggested fix does not look right, it should basically do nothing).

I'll try to explore better why we have the RCT_NEW_ARCH_ENABLED=1 with __cplusplus set to false and fix this root problem.

Repro

I don't think I have time to try the repro in these days, but I'll give it a shot.
I also created these guides in these days, that works with Swift Modules, and I have not encountered any of these problems.

https://github.com/react-native-community/RNNewArchitectureLibraries/tree/feat/turbomodule-swift
https://github.com/react-native-community/RNNewArchitectureLibraries/tree/feat/swift-event-emitter

So, I'm even more inclined to think that there could be a problem in the setup more than in React Native.

when building main.m even in new architecture mode, we don't pass RCT_NEW_ARCH_ENABLED=1 compiler flag, that AppDelegate.h is different when building main.m and AppDelegate.mm.

since main.m is resident in app project, you should update the app's project.pbxproj. those cocoapods post_install handlers don't update this. that's why compiling for main.m doesn't have RCT_NEW_ARCH_ENABLED=1 even ENV['RCT_NEW_ARCH_ENABLED']=1.

https://github.com/react-native-community/RNNewArchitectureLibraries/tree/feat/turbomodule-swift
https://github.com/react-native-community/RNNewArchitectureLibraries/tree/feat/swift-event-emitter

these examples are not complicated enough 😑. you need both objc -> swift and swift -> objc to trigger the problem. that's why i have a swift class inherits objc class in my repro.
feel free to visit this whenever you get a chance (maybe) next year. i could workaround the problem internally before that. if you have any questions, either replying here or ping me on discord. i can help to clarify the questions for you.

This is a new application created with the template, and with the pods installed with RCT_NEW_ARCH_ENABLED=1.
As you can see, the main app has the flag properly set in the Other Cplusplus Flags. React Native seems fine to me.
I made another test, stepping into the flags in the main.m file with the debugger. And yes, it skips them, but it does not skips them in the AppDelegate.mm.
If we rename it main.mm, it works.

I tried to set the RCT_NEW_ARCH_ENABLED=1 flag also in the OTHER_CFLAGS. With this setup, the problem presents even with a fresh app.

I think that the root problem is that RCTCxxBridgeDelegate uses the namespaces and it exposes the a std::unique_ptr which resides in <memory>. We should have wrapped in a more compatible type, probably.

I have to think about this, because I don't like that solution, tbh. It looks like that .h files never has the __cplusplus flag set to true, and they are treated as c files, when they should be considered cpp files.

As you can see, the main app has the flag properly set in the Other Cplusplus Flags. React Native seems fine to me.
I made another test, stepping into the flags in the main.m file with the debugger. And yes, it skips them, but it does not skips them in the AppDelegate.mm.
If we rename it main.mm, it works.

oh yes you are right. since main.m is objc, so the compile flag should be "other c flags" (OTHER_CFLAGS). it has -DRN_FABRIC_ENABLED but not -DRCT_NEW_ARCH_ENABLED=1

What happens if we put the -DRCT_NEW_ARCH_ENABLED=1 flag also in the Others C Flags of the RCTAppDelegate pod? 🤔
Perhaps this fixes the problem completely.

What happens if we put the -DRCT_NEW_ARCH_ENABLED=1 flag also in the Others C Flags of the RCTAppDelegate pod?

if we add -DRCT_NEW_ARCH_ENABLED=1 and still stick on main.m, then the build error should expose to an app created from react-native template. maybe we should both add -DRCT_NEW_ARCH_ENABLED=1 and use main.mm where that feel more correct. however, i'm not 100% confident whether renaming main.mm would break other apps or not.

I investigated this a little bit more. I think that the right fix is to forward declare the class that are needed and use import them in the implementation file only.
So, the changes are:

In the RCTAppDelegate.h

#import <UIKit/UIKit.h>

#if RCT_NEW_ARCH_ENABLED
// When the new architecture is enabled, the RCTAppDelegate imports some additional headers

- #import <React/RCTCxxBridgeDelegate.h>
- #import <React/RCTSurfacePresenterBridgeAdapter.h>
- #import <ReactCommon/RCTTurboModuleManager.h>
+ @protocol RCTCxxBridgeDelegate;
+ @protocol RCTTurboModuleManagerDelegate;
+ @class RCTSurfacePresenterBridgeAdapter;
+ @class RCTTurboModuleManager;

#endif

// ...
#if RCT_NEW_ARCH_ENABLED
/// Extension that makes the RCTAppDelegate conform to New Architecture delegates
- @interface RCTAppDelegate () <RCTTurboModuleManagerDelegate, RCTCxxBridgeDelegate>
+ @interface RCTAppDelegate ()

In the RCTAppDelegate.mm

#if RCT_NEW_ARCH_ENABLED
+ #import <React/RCTCxxBridgeDelegate.h>
+ #import <React/RCTSurfacePresenterBridgeAdapter.h>
+ #import <ReactCommon/RCTTurboModuleManager.h>
#import <React/CoreModulesPlugins.h>
#import <React/RCTFabricSurfaceHostingProxyRootView.h>
#import <React/RCTSurfacePresenter.h>
#import <react/config/ReactNativeConfig.h>

static NSString *const kRNConcurrentRoot = @"concurrentRoot";

- @interface RCTAppDelegate () {
+ @interface RCTAppDelegate () <RCTTurboModuleManagerDelegate, RCTCxxBridgeDelegate> {
  std::shared_ptr<const facebook::react::ReactNativeConfig> _reactNativeConfig;
  facebook::react::ContextContainer::Shared _contextContainer;
}
@end

#endif

In this way, the header file does not have to import any C++ class, because they are limited to the implementation file, which is already, correctly, a .mm file, and the header file can be compiled with C.
Could you give these changes a try in your setup? If they work, we can try and bring them in 0.71.0/0.71.1.
What do you think?

it's a clever idea and works like a charm. thanks @cipolleschi!

I'm glad to hear that! Would you update this PR with the suggested changes, so that I can import and land it? Or should I do it myself?

thanks @cipolleschi for the great idea and help. i've tested old architecture on my end and it works well. also the ios circle ci jobs look fine but those android ci jobs break at unstable sonatype maven server. please let me know whatever i can help.

thanks for the great help 👍


[4.9.x] Fixing UI issue in main and config tabs

Purpose

To fix https://github.com/wso2/api-manager/issues/2817

Goals

Isolate the cause of the issue and fix the UI glitch in the Management console

Approach

When using the updated YUI library, it is necessary to hide unnecessary UI elements when switching between menu action items. This change ensures that only the required UI elements for the main and config tabs in the menu list are shown or hidden as needed. In this change the following regions are manipulated in template.js file.

region1_identity_menu

region1_manage_menu

region3_registry_menu

Release note

Isolate the cause of the issue and fix the UI glitch in the Management console

@BiyonFernando can you check whether adding these changes only to the //Handle click sections of the main and config menus will be sufficient for the fix?

@BiyonFernando can you check whether adding these changes only to the //Handle click sections of the main and config menus will be sufficient for the fix?

Only changing '//Handle click' will allow us to handle the click on tab buttons show in the bellow image.

But when we click on menu list items still the menu overlapping is happening as shown in the issue.


Flaky tests

Hi,
I have tested Allure with Maven and Jenkins and I saw a little thing embarrassing, there is no feature for Flaky tests (or Flakes).
When I use the -Dsurefire.rerunFailingTestsCount=x option see https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html , tests are all registered, not marked as "corrected" like in Junit report.
In Junit report a test that constantly fail is a fail and a test that succeed the first time is a success, a Flaky test is a test which failed at least one time and succeed when retrying.
I think the better way to implement it is to create in the HTML report a new tab named Flakes or Flaky or Corrected.
Can it be implemented ?

In my opinion this is a test smell when your test result is not 100% reproducible, so I'm not sure whether we need this functionality. However if you provide us a reasonable example where this is really needed - then let's discuss.

It could be useful for us too, for example in functional testing there are some exterior elements very specific which can cause a test to fail : wi-fi not available during a short period, or when you are using external API which breaks during a few seconds (and you haven't the hand on it).
It can also come from the test, when we forget a verification so it makes the test flaky, but in this case it would be nice to have the flaky category to easily identify these forgetting (we added video recording -video link with @Attachment-, so if the wi-fi breaks we instantaneously see it on video -> false negative).
It's a way to manage false negative. 90% of the time relaunch the test will succeed. The plugin is awesome so it could be nice to integrate the flaky category.
Actually, the rerun is not filtered by the plugin, a solution should be to identify the state of rerun tests, if it passes from failed to succeeded, add them to flaky category (and not shown in fail/success).

I totally agree with @Fanch- it's a new feature not a big modification.
For all users that are not using the rerun option, nothing will change. But for us, it's a big improvement in readability of the Allure report.

Seems like reasonable

Think it linked with issue about historical changes in reports (miss the exact number).

For example Jenkins has a plugin : https://wiki.jenkins-ci.org/display/JENKINS/Flaky+Test+Handler+Plugin

+1 to this feature.  @vania-pooh is not wrong that it may be a test smell when a test is flaky, but this feature would be helpful in detecting and fixing that exact scenario.

+1, maybe create another type of testresult besides passed/failed/broken/pending/cancelled and call it, well... flaked :)

+1

Yeah, i would love to have this feature as well. I could try to do a pull request, but without guidance and help i'll most probably fail because of experience lack

+1

+1
this is not about historical results, but for reruns of failing tests in a single test run.
retries is a common feature of test frameworks. So if test passes in 10 times, it still passes, but needs to be quarantined and improved, so it gives more stable results. It is important that Allure could identify flaky tests visually somehow.

+1

+20 , but this is really me looking for a server / report manager for Allure. Something which Repauto (they demoed at SelenConf 2015) were trying to do.

I'm excited to see some movement on this. I'd love to see this added as well.

Same !!! By the way how will you manage that?
I guess there will be a flaky category, with some checks on test name and state, but will we have the possibility to ignore the flakes tests in the product defects ? (People might have different visions for that), maybe a product flakes ?
How to keep the success/fail state of a test along with the flaky one? I mean for example in the test suites view, how will you display it ? A flaky green and a flaky red ? Just wondering !
It wiIl be a great feature anyway :)

It would be a very nice feature indeed. Looking for for it.

:(

Almost done in Allure2. It now displays flaky tests https://github.com/allure-framework/allure2/releases/tag/2.0-BETA4
Also Allure2 already supports surefire.xml, issue to support retryFailure/retryError for it https://github.com/allure-framework/allure2/issues/148
Other integrations and server reporting is coming soon


⚠ Bofrost.at has degraded performance

In d50ac73, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1515 ms

Resolved: Bofrost.at performance has improved in 3fdaa5b after 6 minutes.


problemMatcher's "relative" fileLocation should be smarter

VSCode Version: 1.19.3
OS Version: Ubuntu 16.04

I have a cmake project I am using with cpptools.  Because of the way this project is set up, all compiler errors use  absolute source file paths.
However, cpptools' $gcc problem matcher uses "fileLocation": ["relative","${workspaceRoot}"], so paths get unconditionally concatenated with the prefix.
An error location such as /home/vadimcn/project/src/application.cpp:123:45 gets interpreted as /home/vadimcn/project/home/vadimcn/project/src/application.cpp:123:45, and when I click on an error in the Problems panel, VSCode complains:  Unable to open 'application.cpp': File not found (file:///home/vadimcn/project/home/vadimcn/project/src/application.cpp).
I would suggest that the "relative to" prefix should not be added if the error location path is already absolute.

Report to https://github.com/Microsoft/vscode-cpptools thanks.

I can file it with the extension of course, but I think his bug will circle back to VSCode: The extension does not know whether the path will be absolute or relative, but they have to choose one of the two values for fileLocation.   Whichever they choose will be wrong for some projects.  This is a missing feature in the VSCode itself.

I see. Giving to @dbaeumer.

Dups #449


chore: bdd-spring-1583893505 to 0.0.1

chore: Promote bdd-spring-1583893505 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Fix issues due to LocalStorage not being available

LocalStorage can throw exceptions at any time. Any usage should be wrapped in try catch.

Thank you! The on-wiki script has been updated.


z-index values in .css preceded by a # character

After updating to version 12.0.1 the .scss files are not being processed correctly, and some values that should be just an integer, are preceded by an # character on the resulting .css file.
Is this a regression?
Yes, it was working until version 12.0.0
Description
My updated packages are:
"@angular/cli": "^12.0.0", --> "^12.0.1",
"@angular-devkit/architect": "^0.1200.0", --> "^0.1200.1"
"@angular-devkit/core": "^12.0.0", --> "^12.0.1",
"@angular/animations": "^12.0.0", --> "^12.0.1",
"@angular/cdk": "^12.0.0", --> "^12.0.1",
"@angular/common": "^12.0.0", --> "^12.0.1",
"@angular/compiler": "^12.0.0", --> "^12.0.1",
"@angular/core": "^12.0.0", --> "^12.0.1",
"@angular/forms": "^12.0.0", --> "^12.0.1",
"@angular/platform-browser": "^12.0.0", --> "^12.0.1",
"@angular/platform-browser-dynamic": "^12.0.0", --> "^12.0.1",
"@angular/platform-server": "^12.0.0", --> "^12.0.1",
"@angular/router": "^12.0.0", --> "^12.0.1",
"@schematics/angular": "^12.0.0", --> "^12.0.1",
"@angular-devkit/build-angular": "~12.0.0", --> "^12.0.1",
"@angular/compiler-cli": "~12.0.0", --> "^12.0.1",
"@types/node": "^15.3.0", --> "^15.3.1",
"eslint-plugin-jsdoc": "^34.7.0", --> "^34.8.2",
On Visual Studio Code I can see the expected values, but on the resulting .css (browser) I can see that some of the values are preceded by a #, then it is marked by the browser as an illegal value, and ignored.
The calculated values on the components classes are correct, only preceded with a # on the resulting .css file (browser)
Minimal Reproduction
This is my general files structure:
src/
src/_global.scss
 $zIndexBackdropModal: 900;

src/styles.scss
@import "./global";
.someClass { z-index: $zIndexBackdropModal; }

src/app/
src/app/app.component.scss
@import "../global";
.someClass2 { z-index: $zIndexBackdropModal; }
.someClass21{ z-index: $zIndexBackdropModal * 2; }

src/app/component1/
src/app/component1/component1.component.scss
@import "../../global";
$zIndex4Debug: $zIndexBackdropModal * 2;
.someClass3 { z-index: $zIndex4Debug; }
.someClass4 { z-index: $zIndex4Debug + 10; }

This is what it would be expected as resulting .css (the result up to version 12.0.0):
.someClass { z-index: 900;}
.someClass2 { z-index: 900; }
.someClass21 { z-index: 1800; }
.someClass3 { z-index: 1800; }
.someClass4 { z-index: 1810; }

This is what I get now after updating to version 12.0.1:
.someClass { z-index: 900;}
.someClass2 { z-index: #900; }
.someClass21 { z-index: 1800; }
.someClass3 { z-index: #1800; }
.someClass4 { z-index: #1810; }

I have the same issue:
:host div {
    position: absolute;
    top: 25px;
    left: 0;
    min-width: 100px;
    z-index: 100;
    background: #FFFFFF;
    box-shadow: 0 4px 5px rgba(0, 0, 0, 0.15);
    padding: 8px 12px;
}

is converted to:
[_nghost-ged-c146] div[_ngcontent-ged-c146] {
    position: absolute;
    top: 25px;
    left: 0;
    min-width: 100px;
    z-index: #100;
    background: #fff;
    box-shadow: 0 4px 5px rgb(0 0 0 / 15%);
    padding: 8px 12px;
}

While I did manage to replicate the other issue. I didn't manage to replicate this.
Input
$zIndex4Debug: 1000 * 2;
.someClass3 { z-index: $zIndex4Debug; }
.someClass4 { z-index: $zIndex4Debug + 10; }

Output
.someClass3{z-index:2000}.someClass4{z-index:2010}

It does not happen for all the components in my case, and this .someClass3 and .someClass4 are just an example. I have many components, and this happens only for some of them, and even in not all the css classes of a component.
I have reverted to 12.0.0 until a fix is done. Maybe it has to do something with nanocss as @JoostK suggested...

What a coincidence... #20869

Please post your reproductions here: https://github.com/cssnano/cssnano/issues/1115 since this is not actionable by us.

We're experiencing this as well.
.breadcrumbs-container {
  position: relative;
  font-size: 15px;
  background-color: $white;
  color: mat.get-color-from-palette($fab-accent-palette, 600);
  height: $breadcrumbs;
  width: 100%;
  white-space: nowrap;
  margin-bottom: 0 !important;
  z-index: 300;
}

.breadcrumbs-container[_ngcontent-kxa-c34] {
    position: relative;
    font-size: 15px;
    background-color: #fff;
    color: #6d6d6a;
    height: 28px;
    width: 100%;
    white-space: nowrap;
    margin-bottom: 0!important;
    z-index: #300;
}

$white = #ffffff.  I can't help but notice that in common in all of our examples.  the #ffffff -> #fff

I'm experiencing this as well.
.appointments .appointment-block {
    display: flex;
    position: absolute;
    z-index: 100;
    min-height: 58px;
    max-height: 58px;
    top: 0;
    left: 0;
    overflow: hidden
}

.appointments .appointment-block {
    display: flex;
    position: absolute;
    z-index: #100;
    min-height: 58px;
    max-height: 58px;
    top: 0;
    left: 0;
    overflow: hidden
}

We're experiencing this as well.
.breadcrumbs-container {
  position: relative;
  font-size: 15px;
  background-color: $white;
  color: mat.get-color-from-palette($fab-accent-palette, 600);
  height: $breadcrumbs;
  width: 100%;
  white-space: nowrap;
  margin-bottom: 0 !important;
  z-index: 300;
}

.breadcrumbs-container[_ngcontent-kxa-c34] {
    position: relative;
    font-size: 15px;
    background-color: #fff;
    color: #6d6d6a;
    height: 28px;
    width: 100%;
    white-space: nowrap;
    margin-bottom: 0!important;
    z-index: #300;
}

$white = #ffffff. I can't help but notice that in common in all of our examples. the #ffffff -> #fff

#fff is a shorthand for #ffffff, so no problem, all browsers should know about this equivalency.
but your z-index: #300 is the real problem

Yeah, and the example after mine didn't have that. So just coincidental it seems.

We had the same issue with our production build adding # in front of z-index.
We fixed it temporarily by explicit using this package:
"@angular-devkit/build-angular": "0.1102.10"

This package uses an older version of the cssnano package cssnano "4.1.11" that doesn't have this issue.

We removed ~ character of the version number and temporarily fixed.
"@angular-devkit/build-angular": "0.1102.3" thanks

This has been fixed upstream https://github.com/cssnano/cssnano/pull/1122

So, how should I update to get the issue fixed? I tried npm update, and several packages where updated, but the issue is still there. Thanks!

@alan-agius4 It looks like their update isn't being picked up by /build-angular.  Seems your package is locked at 5.0.2.  Their fix is 5.0.4
"cssnano": "5.0.2",
So this is still an issue.

Sorry, false alarm.  Yes cssnano is locked at that version, but it still picked up the upstream colord 2.0, which was the important bit.  I've verified this fixes the issue. @igorosabel: you might just try deleting node_modules/colord and running install again.  Or, all else fails, clear your node_modules and package-lock entirely.


fix: Empty all placeholder menu

Description
The empty placeholder menu currently does not work (#7389). The url is not rendered into the template.
This PR corrects the template and uses the url template tag to retrieve the admin url for "Empty all".

Checklist

[x] I have opened this pull request against develop-4
[ ] I have added or modified the tests when changing logic
[x] I have followed the conventional commits guidelines to add meaningful information into the changelog
[x] I have read the contribution guidelines  and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.

I see your point. This was not detected since {{ }} expansions in templates fail silently. So what we would need to do is to find all those expansions and generate a test suite for those. Luckily {% %} template tags fail loudly and with this particular item I guess we have a good chance of being fine.
I am actually thinking of a linter to identify those variable expansions. (There's a longstanding bug #7188 where page ids are put into an url in localized form rendering the page tree unusable in localizations with thousands separator - that's probably something to port to v4, too.)
Will look into other variable expansions at risk and see what tests make sense.

@Aiky30  It turns out there was a test for the extended menu items. The new test also includes the standard items. (Copy, Paste, Empty all)  Other critical template elements ({{ object.property }}) can be found in these files:
(.venv.) $ find cms -name "*.html" -print -exec egrep 'href="{{\s*[a-zA-Z0-9_.]+\.[a-zA-Z0-9_]+\s*}}"' {} \;
cms/templates/cms/toolbar/toolbar_with_structure.html

{% trans "It is being redirected to:" %} {{ cms_toolbar.redirect_url }}

cms/templates/cms/toolbar/items/live_draft.html
    href="{{ cms_toolbar.get_object_preview_url }}">
    href="{{ cms_toolbar.get_object_edit_url }}">
cms/templates/cms/toolbar/dragitem_extra_menu.html

{{ item.name }}

cms/templates/cms/toolbar/dragitem_menu.html

{{ p.name }}

Afaics these are covered with tests.

Wait: The first two are tested but do not detect missing links. I'll add two more tests.

@Aiky30 Do you know if cms/templates/toolbar/items/live_draft.html is used at all in v4? I believe the edit, preview and publish buttons are generated programmatically in python.
Same with cms/templates/cms/toolbar/toolbar_with_structure.html (which is in use, obviously):  it seems that the cms_toolbar.redirect_url property is never used. Hence you never get the message "This page redirects to ...". I cannot go to edit a language that does not have a page content, correct?

@Aiky30 Do you know if cms/templates/toolbar/items/live_draft.html is used at all in v4? I believe the edit, preview and publish buttons are generated programmatically in python.
Same with cms/templates/cms/toolbar/toolbar_with_structure.html (which is in use, obviously): it seems that the cms_toolbar.redirect_url property is never used. Hence you never get the message "This page redirects to ...". I cannot go to edit a language that does not have a page content, correct? Hence the last part is not rendered (if not a custom toolbar causes it to be rendered):
    {% if cms_toolbar.redirect_url %}

{% trans "This page has no preview!" %}

{% trans "It is being redirected to:" %} {{ cms_toolbar.redirect_url }}

    {% endif %}

You could possibly get this message if you have content in one language but you've not yet created content in another.
cms/templates/toolbar/items/live_draft.html is possibly not used, although it could still be used and the name wasn't updated ...

You could possibly get this message if you have content in one language but you've not yet created content in another.

Is there an endpoint for that? It seems that the page content object needs to be created (and thereby the language) to edit it. If you can give me an edit endpoint for a non-existing language I can add a test for the message.
OK, it it could be used we better keep the live_draft.html template. There's not tests for it (and I see no way of testing it if it is not rendered at some point 😉).


When running RuboCop is run as a rake task it fails, but not if not a rake task

Response when running just rubocop
rubocop
Inspecting 400 files
................................................................................................................................................................................................................................................................................................................................................................................................................

400 files inspected, no offenses detected

When running rubocop via rake task
rake
Running RuboCop...
Inspecting 400 files
......................................................................................................................................................
To see the complete backtrace run rubocop -d.
..........................................................................................................................................................................................................................................................

400 files inspected, no offenses detected

Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
Mention the following information in the issue report:
0.33.0 (using Parser <IP_ADDRESS>, running on ruby 2.2.2 x86_64-darwin14)
RuboCop failed!

Rakefile
require File.expand_path('../config/application', __FILE__)
Rails.application.load_tasks

if %w(development test).include? Rails.env
  require 'rubocop/rake_task'
  RuboCop::RakeTask.new

  task(:default).clear
  task default: [:rubocop, :spec]
end

.rubocop.yml
AllCops:
  Exclude:
    - 'bin/**/*'
    - 'db/**/*'
    - 'log/**/*'
    - 'tmp/**/*'
    - 'vendor/**/*'
    - 'Guardfile'
  DisplayCopNames: true
  RunRailsCops: true

Metrics/AbcSize:
  Enabled: false

Metrics/CyclomaticComplexity:
  Enabled: false

Metrics/PerceivedComplexity:
  Enabled: false

Metrics/MethodLength:
  Enabled: false

Metrics/LineLength:
  Max: 99
  Exclude:
    - 'config/**/*'

Metrics/ModuleLength:
  Max: 150

Rails/HasAndBelongsToMany:
  Enabled: false

Rails/Validation:
  Enabled: false

Style/AsciiComments:
  Enabled: false

Style/BlockComments:
  Enabled: false

Style/BlockDelimiters:
  Enabled: true
  Exclude:
    - 'spec/controllers/*'

Style/RegexpLiteral:
  Enabled: false

Style/ClassAndModuleChildren:
  Enabled: false

Style/Documentation:
  Enabled: false

Style/Lambda:
  Enabled: false

Style/StringLiterals:
  Enabled: false

Style/SpaceInsideStringInterpolation:
  Enabled: false

Lint/NestedMethodDefinition:
  Enabled: false

Style/ExtraSpacing:
  Enabled: false

rubocop -D also works with no problem

If you add the following to your Rakefile:
RuboCop::RakeTask.new(:rubocop_debug) do |t|
  t.options = ['-d']
end

You should be able to pinpoint the problem by running rake rubocop_debug. Let us know what you find.

@jonas054 Produces the same results as above i.e. rubocop -d
436 files inspected, no offenses detected

Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
Mention the following information in the issue report:
0.33.0 (using Parser <IP_ADDRESS>, running on ruby 2.2.2 x86_64-darwin14)
RuboCop failed!

Don't you get a stack trace?

@ericbrooke Can you confirm that when t.options = ['-d'] is added to your Rakefile, you still don't get a stack trace?

Closing due to lack of activity.

Had a similar issue: running "rubocop ." was ok, but running as a Rake task using patterns argument with '**/*.rb' and formatters with 'files' was failing, outputting only the files having issues, but no other error message.
The issue came after an update of chefdk tool which is using a newer version of ruby; the solution was to use:
Metrics/BlockLength:
  Max: 100

where block length was previously increased to 80, but still, the error wasn't thrown by simple rubocop call in CLI .

It happened to me too.
This is minimal settings.
Rakefile
require 'treetop'
require 'rubocop/rake_task'

RuboCop::RakeTask.new

.rubocop.yml
inherit_gem:
  foo-bar: .rubocop.yml

foo-bar: .rubocop.yml
Metrics/BlockLength:
  Exclude:
    - spec/**/*.rb

$ rake rubocop
:
spec/unit/recipes/base_spec.rb:3:1 C: Block has too many lines. [27/25]
describe 'sample::base' do ...
^^^^^^^^^^^^^^^^^^^^^^^^^^

Exculde has no effect.
But $ rubocop is OK.
This error happens when treetop is required and configuration is written in inherit_gem.
Treetop is required by foodcritic (https://github.com/acrmp/foodcritic/blob/master/lib/foodcritic.rb)
$ gem list | grep -E 'rubocop|treetop'
rubocop (0.46.0)
treetop (1.6.8)

I get a different result with the rake task too, but it is not related to exclude patterns. Seems like different rules are loaded. I get this error with the rake task, but not with rubocop :
file.rb:84:3: W: Lint/ShadowedException: Do not shadow rescued Exceptions.
  rescue JSON::ParserError, Faraday::ClientError, Faraday::ResourceNotFound => e
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I tried above measures, still getting error,
rake aborted
NameError: constant Object:config not defined

What's the output if you define the task as
RuboCop::RakeTask.new(:rubocop_debug) do |t|
  t.options = ['-d']
end

Anybody who has the problem can answer.

It looks like the rake task doesn't load all defaults.
# bundle exec rails rubocop_debug
Running RuboCop...
For /Users/j15e/repos/project: configuration from /Users/j15e/repos/proejct/.rubocop.yml
Inspecting 173 files

VS
# bundle exec rubocop -d
For /Users/j15e/repos/project: configuration from /Users/j15e/repos/project/.rubocop.yml
configuration from /Users/j15e/.rvm/gems/ruby-2.5.0/gems/rubocop-rspec-1.25.1/config/default.yml
configuration from /Users/j15e/.rvm/gems/ruby-2.5.0/gems/rubocop-rspec-1.25.1/config/default.yml
Default configuration from /Users/j15e/.rvm/gems/ruby-2.5.0/gems/rubocop-0.55.0/config/default.yml
Inheriting configuration from /Users/j15e/.rvm/gems/ruby-2.5.0/gems/rubocop-0.55.0/config/enabled.yml
Inheriting configuration from /Users/j15e/.rvm/gems/ruby-2.5.0/gems/rubocop-0.55.0/config/disabled.yml
Inspecting 173 files

Full logs here (removed file names / project name for confidentiality) :
https://gist.github.com/j15e/6389efeb0fd3112e19c26e602ccef0cf

For anyone interested, I just merged a fix for this, see #8636.


Rename the output html file based on markdown title

@zhengdavy, whould you like to try this?
We usually use the first line of the markdown as our slideshow title. e.g.
# My Awesome Presentation
## by Shing Lyu
...

So we want to

parse the first line
remove the #
slugify the title
then use gulp-rename module to rename the output file from template.html to my_awesome_presentation.html

3 questions:

currently gulp takes all the md files to generate html file.

36   var content = gulp.src([path.join(md_path, '*.md')])
37                     .pipe(exclude)
does it mean we will have more than one md files? if so, what to take for the name?

what if there is no #in the first line? or there is no # at all? I assume we would default it to default name "template.html"?

I assumed following line takes 'template.html' as the file name.

var template = gulp.src(path.join(gulpfile_path, 'custom', 'template.html'))
Why don't we just dynamically generate the file name from the md file instead of use gulp-rename?

Good catch, usually there will be just one md file, (and I don't want to support multiple md files now), so we can raise an exception if there are more then one md files
If there is no # in the first line, just take anything that is in the first line. If the first line is empty, find the first line that is not empty and use it.
The line takes an template.html with no content as the source, we then replace a placeholder with the actual content from the md file, so the output should be renamed. If we change the filename here, it won't be able to locate the original template file.

Resolved.


Add mypy - check types

Fix #205

Looks like the test fixtures should be excluded. (I guess they could also be tested one by one, but that soulnds like too much work for too little benefit.)

Looks like the test fixtures should be excluded. (I guess they could also be tested one by one, but that soulnds like too much work for too little benefit.)

I' ve removed tests and freezeyt blog I ve supposed they are not important for mypy checking

To silence the no type hints or library stubs errors, the easiest way is putting the following in the file pyproject.toml:
[tool.mypy]
ignore_missing_imports = true

There are more fine-grained ways to handle these errors; you can open an issue to look into that.


zgpu: Memory leak in samples (Dawn leaks ~20KB per frame on macOS)

It seems like all the samples have are leaking memory. One can detect this by observing the memory usage of the sample goes up over time.
zig version: 0.10.0-dev.4249+11dce7894
$ zig build triangle_wgpu-run
info: [zgpu] High-performance device has been selected:
info: [zgpu]   Name: Apple M1
info: [zgpu]   Driver: Metal driver on macOS Version 12.6 (Build 21G115)
info: [zgpu]   Adapter type: discrete_gpu
info: [zgpu]   Backend type: meta

Here is a capture of the triangle sample's memory usage captured once per second:
    48 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
 95216 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
 96368 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
 97424 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
 98512 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
 99504 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
100528 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
101552 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
102544 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
103584 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
104576 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
105584 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
106656 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
107696 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
108720 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
109712 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu
110800 michal-z/zig-gamedev/zig-out/bin/triangle_wgpu

In Activity Monitor memory usage seems to go up by 40 megabytes per second.
I commented out zgui and the leak remains.

The oldest commit that still runs the triangle demo for me is c0fcbfd1484d7d943248153533b2e553df291085 and it also leaks memory. I wonder if its env specific. I don't have access to another computer right now.

The memory leaks is faster when the sample isn't being showing on screen. This is likely caused by an extremely high frame rate being off-screen and the memory leak is made more obvious.
I created a memory-leak branch to run the triangle sample with std.testing.allocator to see if it catches the problem, but atlas it does not.
Run zig build test and it will launch the triangle sample with std.testing.allocator.

This is a bug in Dawn and it affects only macOS. This should be fixed after we update to newer Dawn versions.

Thanks. I found it in the issue tracker https://bugs.chromium.org/p/dawn/issues/detail?id=1175

We were discussing this issue on Zig > game-dev channel: https://discord.com/channels/605571803288698900/634812978994085888/1008307672484954213

still leaks memory with

zig-gamedev 5d64954d7570d336854af1b0fbfbde26fc626c76
zig 0.11.0-dev.78+28288dcbb

Is there any new news on this? I just had my machine crash after the program used all available app memory for the first time, this bug is still definitely there.

zig-gamedev de7b2bc
zig 0.11.0-dev.2191+30427ff79

Yes, the bug is still there unfortunately. They have decided to fix it after WebGPU 1.0 release (which should happen this Summer).

Gotcha! Thanks for the info!

@michal-z I got a notification that this was fixed I believe, looking at the dawn issue tracker it shows fixed as of 2 days ago. What are the steps to get this into zig-gamedev? I'm itching to get rid of that leak on macOS :D

That's a good news! We need to re-compile and update our Dawn binaries for all platforms. I'm planning to do it in coming weeks.

Any update on this?

Yes and also if you need any help with anything! I started trying to look at it locally using the latest mach prebuilt but I was getting a lot of errors I didn't know how to solve, but I could look into that further if it would help.

Coincidentally our project recently crossed a threshold of usage where this now affects us as well. Previously our app was meant to be used only used for a few minutes at a time, and this didn't break things, now it needs to be run longer.

as of
commit eb355bb3edcf7f667597bae78f1be93c70e6297a (HEAD -> main, origin/main, origin/HEAD)
Author: Austin Eng<EMAIL_ADDRESS>Date:   Fri Jul 14 01:10:52 2023 +0000

it still leaks, but the rate on my test app has gone from 20mb/s to a few kb/s. So it's gone from unusable to tolerable.
Note also that the dawn build was broken for a couple of days, there was some defunct codegen which they fixed today. The hash I posted here is viable. Hope that saves some time if you are experimenting with an update.

mach uses the same lib (Dawn) so if a leak is there it will affect every build. That said, mach may be using different version than @meshula .
Anyway, I will start working on the update today.

I tested with dawn's top of tree as of July 14. The issue is reproducible for us, with the version of zgpu currently referenced by ziggamedev, and all the related zgd demos demonstrate the leak on the several machines we tried, all M1 or M2 based.

@meshula have you reported your findings to google? You can refer to the fix https://bugs.chromium.org/p/dawn/issues/detail?id=1175

I think it would make sense to do so after zgpu is updated to latest. Otherwise I am only one data point, and I would be happy to discover that after the zgpu update the problem has been resolved.

Just to let you know, I'm still working on an Dawn update, some changes in zgpu are needed so it may takes few more days.

@Pyrolistical @meshula We now have new binaries and @foxnne doesn't see memory leak on macOS anymore. I highly recommend to upgrade.

Thanks! We'll upgrade as soon as possible.

Can confirm leak is gone. Thank you.


NTR: positive regulation of cell cycle switching, mitotic to meiotic cell cycle

Please provide as much information as you can:

Suggested term label:

positive regulation of cell cycle switching, mitotic to meiotic cell cycle ,

Definition (free text)

standard

Reference, in format PMID:#######

PMID:22375066

Parent term(s)

GO:0110044
regulation of cell cycle switching, mitotic to meiotic cell cycle

Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

Cross-references

For enzymes, please provide RHEA and/or EC numbers.

Can also provide MetaCyc, KEGG, Wikipedia, and other links.

Any other information

+id: GO:0140648
+name: positive regulation of cell cycle switching, mitotic to meiotic cell cycle
+namespace: biological_process
+def: "Any process that activates or increases the frequency, rate or extent of mitotic to meiotic cell cycle switching, the process in which a cell switches cell cycle mode from mitotic to meiotic division." [PMID:22375066]
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/21506 xsd:anyURI
+created_by: pg
+creation_date: 2021-05-25T06:18:49Z
+


(Edge case?) Mediation scenario creating unqualified DIDs

POST /mediation/update-keylist/{conn_id} can create a DID if one does not exist for a connection. The goal of this was to enable the controller to ensure the keys associated with a connection are definitely known to the mediator before responding to an invite or request in connections or DID Exchange.
I think this approach needs reworking. I'm not sure if anyone is actually using this endpoint or not.
The mediation race condition problem is one I've attempted to solve before. To summarize the issue, since DIDComm and, therefore, the coordinate mediation protocol are asynchronous, it is difficult to complete an operation like creating keys and then responding to a DID Exchange request when using mediation since we'd have to wait indefinitely for the mediator to process the keylist update request. Most of the time, the mediator responds promptly, sooner than we're able to send off our DID Exchange request. But even slight network delays can disrupt this.
Having attempted to solve this problem a number of ways, I think I've come to a conclusion:
The most destward mediator (the "exit node" of a chain of mediators or the mediator closest to the recipient, the one accepting pickup and key list update requests from the mediated agent) must support responding to mediation clients with return routing when using the coordinate mediation protocol and must do so within a reasonable timeout (if using something like WebSockets for the transport where there isn't necessarily request-response return route semantics). All alternatives place a significant burden on implementers of agents supporting or requiring operation as a mediation client.
Enforcing operation in this manner dramatically simplifies the implementation of these chained actions where a tight turnaround is expected.
Maybe something to discuss on an Aries WG call or something.

Philosophically, there is not a difference between waiting for a POST synchronous response and waiting for an inbound DIDComm message. Practically, it may be easier in an HTTP library than in our DIDComm message handling infrastructure. While I'd love to improve the message handling so that waiting for a response is easy and reliable, this may not be the moment.
Why only impose this on the exit mediator? I think setting the expectation of response like you describe should be imposed on all mediators.


Sign operation - Add operation cost, hide technical parameters, edit fees

Context
Tackles the part of the Need 1 identified in the 'improvement of Sign operation' suggestions for SC-type operations, transaction and roll buy/sell initiated by a dapp. The need should also applied transactions sent in-app.
User flow
All types of Operations initiated by dApps:

initiate operations types
Sign wails pop up is shown to the user.
Display only the Operation cost, which is a sum of 'fees' + 'coins' parameters.
User must be able to edit parameter 'fees'.

Sending Transactions in MW:

initiate MAS transfer in the wallet
Sign wails pop up is shown to the user
instead of transaction fee show 'Operation cost' as mentioned above.
User must be able to edit parameter 'fees'.

How to

[x] #819

Enable editing 'fee' parameter. User should see the operation cost change due to his edit.
User should be able to reset the 'fee' value to a recommended one by the initiator: dApp or Massa wallet.

[x] #817
[ ] #814

Designs for Wails pop up: https://www.figma.com/file/LSaOibVDFb1reF6FePVn5l/Massastation?type=design&node-id=6671-41583&mode=design&t=eRL7yXNkjLB0lf71-0
Edit fees flow: https://www.figma.com/file/LSaOibVDFb1reF6FePVn5l/Massastation?type=design&node-id=6845-13599&mode=design&t=YrmdmD91CV1EVFlo-0
Technical details
Give the technical insights so anyone in the team can tackle the tasks - Dev
QA testing
Does this task require some QA tests ?
If yes, explain how to validate it

QA ok


Issue #1511: Vector const copy

Add const qualifiers to indicate that VectorOperations::Copy does not modify the source Vector.  A small change was needed to remove the dependence on Vector::Normalify, which was only using the sequence branch of the case statement.

Thanks, looks good now!


Lack of DUnitX in Delphi Starter Edition

@vincentparrett I am building an object pascal track at exercism.io.  At the moment it is featuring Delphi and DUnitX.  Not having your code as part of the starter edition adds a layer of complexity for the student that is trying out object pascal for the first time and is using the starter edition.  Documenting for them, on exercism.io site, on how to manually setup DUnitX is not the end of the world; it would just be nice if it wasn't necessary.  It should only be necessary for those that would happen to be using a version prior to XE8 (I believe?).  I thought it better to mention this as a new issue then to tack it on to #160.

I have no control over what embarcadero bundle with the starter edition. As for documentation, well that's always a problem with open source projects. I have very limited time to work on DUnitX these days, so I can only hope that someone else might be interested in contributing.


SuspendInstallation and UnsuspendInstallation for GitHub Apps

Add support for Suspend and Unsuspend GitHub App installation.
Fixes #1517

Thank you, @wesleimp!
Merging.


Is there a way to use pilkit from the linux command line to take 3 optimized png files and create a compressed .ico file?

Is there a way to use pilkit from the linux command line to take 3 optimized png files and create a compressed .ico file?
I used imagemagik like this but it took the 3 ~130 byte png files and turned them into a 14kb ico file:
convert favicon-16x16.png favicon-32x32.png favicon-48x48.png favicon.ico

pilkit does not have command line interface. This is out of scope for this project. The main idea behind this project was to expose some handy utilities that where part of django-imagekit for people to use them. If there is someone willing to create new project which is wrapping pilkit and is providing CLI probably will be useful, but as I already mentioned it is outside of the scope of the project.


Is there a way to use it with Browserify

does it have to run on server-side or could it run on the browser with browserify?


Issue #310 Fix method wired_autoconfig_service_running for windows

Use locale independent variant to check if service dot3svc is running: sc query dot3svc
This fixes issue #310

Superseded by pull request #326 which amend the approach.


No shared schemes

Carthage build stops.
*** Skipped building Base64 due to the error:
Dependency "Base64" has no shared framework schemes

Version 1.1.2

Carthage was never a supported build system.  Feel free to submit a pull request.

@ekscrypto I agree with you about Carthage.