iOS build failing on fresh react native project

Description
npm run android has been failing on a fresh react native project

Full Error Link
I have tried sooo many things none worked, I feel so helpless now
Version
0.70.6
Output of npx react-native info
info Fetching system and libraries information...
System:
OS: macOS 11.6.8
CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Memory: 127.79 MB / 8.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
Yarn: Not Found
npm: 9.2.0 - ~/.nvm/versions/node/v18.12.1/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.3 - /Users/mac/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK:
API Levels: 28, 29, 31, 33
Build Tools: 29.0.2, 30.0.2, 30.0.3, 31.0.0, 33.0.0, 33.0.1
System Images: android-24 | Google Play Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-31 | Intel x86 Atom_64, android-31 | Google APIs Intel x86 Atom_64
Android NDK: Not Found
IDEs:
Android Studio: 2021.2 AI-212.5712.43.2112.8815526
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.17 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: 0.70.6 => 0.70.6
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce
Install a new project
npx react-native init Name
npm run iOS
Snack, code example, screenshot, or link to a repository
npx react-native init Name

Its also worth noting that if I run pod install with this command
RCT_NEW_ARCH_ENABLED=1 pod install
I get this error

Which is the same error I get when I run
npm run iOS
on any of my react native project so currently, I can't build iOS on my old projects and I can't create a new project
I have tried deleting derived data
Clearing cache
Deleting node modules and Pods
I even deleted node,cocoapods, watchman, and everything related to react native and did a new install
Yet same issue

I just tried using expo prebuild
And I am getting same error

expo run:ios

› Planning build
› Compiling react-native Pods/React-RCTVibration » RCTVibration.mm
❌  (node_modules/react-native/Libraries/Vibration/RCTVibration.mm:16:28)
14 | #import "RCTVibrationPlugins.h"
15 |

16 | @interface RCTVibration()
|                            ^ cannot find protocol declaration for 'NativeVibrationSpec'
17 | @end
18 |
19 | @implementation RCTVibration

❌  (node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:20)
31 | }
32 |

33 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                    ^ use of undeclared identifier 'facebook'
34 | {
35 |   return std::make_sharedfacebook::react::NativeVibrationSpecJSI(params);
36 | }

❌  (node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:72)
31 | }
32 |

33 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                                                                        ^ use of undeclared identifier 'facebook'
34 | {
35 |   return std::make_sharedfacebook::react::NativeVibrationSpecJSI(params);
36 | }

❌  (node_modules/react-native/Libraries/Vibration/RCTVibration.mm:35:27)
33 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
34 | {

35 |   return std::make_sharedfacebook::react::NativeVibrationSpecJSI(params);
|                           ^ use of undeclared identifier 'facebook'
36 | }
37 |
38 | RCT_EXPORT_METHOD(vibrateByPattern:(NSArray *)pattern

› Compiling react-native Pods/React-RCTSettings » RCTSettingsManager.mm
❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:18:34)
16 | #import "RCTSettingsPlugins.h"
17 |

18 | @interface RCTSettingsManager()
|                                  ^ cannot find protocol declaration for 'NativeSettingsManagerSpec'
19 | @end
20 |
21 | @implementation RCTSettingsManager

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:55:14)
53 | }
54 |

55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
|              ^ no member named 'react' in namespace 'facebook'
56 | {
57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
58 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:55:4)
53 | }
54 |

55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
|    ^ expected a type
56 | {
57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
58 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:60:14)
58 | }
59 |

60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants
|              ^ no member named 'react' in namespace 'facebook'
61 | {
62 |   return facebook::react::typedConstantsJS::NativeSettingsManager::Constants({
63 |     .settings = RCTJSONClean([_defaults dictionaryRepresentation])

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:60:4)
58 | }
59 |

60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants
|    ^ expected a type
61 | {
62 |   return facebook::react::typedConstantsJS::NativeSettingsManager::Constants({
63 |     .settings = RCTJSONClean([_defaults dictionaryRepresentation])

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:115:30)
113 | }
114 |

115 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                              ^ no member named 'react' in namespace 'facebook'
116 | {
117 |   return std::make_sharedfacebook::react::NativeSettingsManagerSpecJSI(params);
118 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:115:82)
113 | }
114 |

115 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                                                                                ^ no member named 'react' in namespace 'facebook'
116 | {
117 |   return std::make_sharedfacebook::react::NativeSettingsManagerSpecJSI(params);
118 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:57:21)
55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
56 | {

57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
|                     ^ no member named 'react' in namespace 'facebook'
58 | }
59 |
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:57:44)
55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
56 | {

57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
|                                            ^ use of undeclared identifier 'JS'
58 | }
59 |
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:57:81)
55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
56 | {

57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
|                                                                                ^ expected expression
58 | }
59 |
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:57:83)
55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
56 | {

57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
|                                                                                ^ missing '[' at start of message send expression
58 | }
59 |
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:57:101)
55 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)constantsToExport
56 | {

57 |   return (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)[self getConstants];
|                                                                                ^ expected ']'
58 | }
59 |
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:62:20)
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants
61 | {

62 |   return facebook::react::typedConstantsJS::NativeSettingsManager::Constants({
|                    ^ no member named 'react' in namespace 'facebook'
63 |     .settings = RCTJSONClean([_defaults dictionaryRepresentation])
64 |   });
65 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:62:42)
60 | - (facebook::react::ModuleConstantsJS::NativeSettingsManager::Constants)getConstants
61 | {

62 |   return facebook::react::typedConstantsJS::NativeSettingsManager::Constants({
|                                          ^ use of undeclared identifier 'JS'
63 |     .settings = RCTJSONClean([_defaults dictionaryRepresentation])
64 |   });
65 | }

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:63:5)
61 | {
62 |   return facebook::react::typedConstantsJS::NativeSettingsManager::Constants({

63 |     .settings = RCTJSONClean([_defaults dictionaryRepresentation])
|     ^ expected expression
64 |   });
65 | }
66 |

❌  (node_modules/react-native/Libraries/Settings/RCTSettingsManager.mm:117:37)
115 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
116 | {

117 |   return std::make_sharedfacebook::react::NativeSettingsManagerSpecJSI(params);
|                                     ^ no member named 'react' in namespace 'facebook'
118 | }
119 |
120 | @end

› Compiling react-native Pods/React-RCTNetwork » RCTNetworking.mm
❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:27:30)
25 | NSString *const RCTNetworkingPHUploadHackScheme = @"ph-upload";
26 |

27 | @interface RCTNetworking ()
|                              ^ cannot find protocol declaration for 'NativeNetworkingIOSSpec'
28 |
29 | - (RCTURLRequestCancellationBlock)processDataForHTTPQuery:(NSDictionary<NSString *, id> *)data
30 |                                                  callback:(RCTHTTPQueryResult)callback;

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:687:32)
685 | #pragma mark - JS API
686 |

687 | RCT_EXPORT_METHOD(sendRequest:(JS::NativeNetworkingIOS::SpecSendRequestQuery &)query
|                                ^ use of undeclared identifier 'JS'
688 |                   callback:(RCTResponseSenderBlock)responseSender)
689 | {
690 |   NSDictionary *queryDict = @{

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:734:30)
732 | }
733 |

734 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                              ^ no member named 'react' in namespace 'facebook'
735 | {
736 |   return std::make_sharedfacebook::react::NativeNetworkingIOSSpecJSI(params);
737 | }

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:734:82)
732 | }
733 |

734 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
|                                                                                ^ no member named 'react' in namespace 'facebook'
735 | {
736 |   return std::make_sharedfacebook::react::NativeNetworkingIOSSpecJSI(params);
737 | }

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:691:22)
689 | {
690 |   NSDictionary *queryDict = @{

691 |     @"method": query.method(),
|                      ^ property 'method' not found on object of type '__strong id'
692 |     @"url": query.url(),
693 |     @"data": query.data(),
694 |     @"headers": query.headers(),

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:692:19)
690 |   NSDictionary *queryDict = @{
691 |     @"method": query.method(),

692 |     @"url": query.url(),
|                   ^ property 'url' not found on object of type '__strong id'
693 |     @"data": query.data(),
694 |     @"headers": query.headers(),
695 |     @"responseType": query.responseType(),

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:693:20)
691 |     @"method": query.method(),
692 |     @"url": query.url(),

693 |     @"data": query.data(),
|                    ^ property 'data' not found on object of type '__strong id'
694 |     @"headers": query.headers(),
695 |     @"responseType": query.responseType(),
696 |     @"incrementalUpdates": @(query.incrementalUpdates()),

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:694:23)
692 |     @"url": query.url(),
693 |     @"data": query.data(),

694 |     @"headers": query.headers(),
|                       ^ property 'headers' not found on object of type '__strong id'
695 |     @"responseType": query.responseType(),
696 |     @"incrementalUpdates": @(query.incrementalUpdates()),
697 |     @"timeout": @(query.timeout()),

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:695:28)
693 |     @"data": query.data(),
694 |     @"headers": query.headers(),

695 |     @"responseType": query.responseType(),
|                            ^ property 'responseType' not found on object of type '__strong id'
696 |     @"incrementalUpdates": @(query.incrementalUpdates()),
697 |     @"timeout": @(query.timeout()),
698 |     @"withCredentials": @(query.withCredentials()),

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:696:36)
694 |     @"headers": query.headers(),
695 |     @"responseType": query.responseType(),

696 |     @"incrementalUpdates": @(query.incrementalUpdates()),
|                                    ^ property 'incrementalUpdates' not found on object of type '__strong id'
697 |     @"timeout": @(query.timeout()),
698 |     @"withCredentials": @(query.withCredentials()),
699 |   };

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:697:25)
695 |     @"responseType": query.responseType(),
696 |     @"incrementalUpdates": @(query.incrementalUpdates()),

697 |     @"timeout": @(query.timeout()),
|                         ^ property 'timeout' not found on object of type '__strong id'
698 |     @"withCredentials": @(query.withCredentials()),
699 |   };
700 |

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:698:33)
696 |     @"incrementalUpdates": @(query.incrementalUpdates()),
697 |     @"timeout": @(query.timeout()),

698 |     @"withCredentials": @(query.withCredentials()),
|                                 ^ property 'withCredentials' not found on object of type '__strong id'
699 |   };
700 |
701 |   // TODO: buildRequest returns a cancellation block, but there's currently

❌  (node_modules/react-native/Libraries/Network/RCTNetworking.mm:736:37)
734 | - (std::shared_ptrfacebook::react::TurboModule)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
735 | {

736 |   return std::make_sharedfacebook::react::NativeNetworkingIOSSpecJSI(params);
|                                     ^ no member named 'react' in namespace 'facebook'
737 | }
738 |
739 | @end

› Compiling react-native Pods/React-RCTNetwork » RCTNetworkPlugins.mm
› Compiling react-native Pods/React-RCTNetwork » RCTHTTPRequestHandler.mm
› 33 error(s), and 0 warning(s)
CommandError: Failed to build iOS project. "xcodebuild" exited with error code 65.

I have the same issue, any update on this?

As I have only ever used Expo to develop native apps, I have not idea what this means, however I managed to get passed this particular error as follows:
$ find . -name FBReactNativeSpec.h
./apps/expo-app/ios/build/generated/ios/out/FBReactNativeSpec/FBReactNativeSpec.h
./apps/expo-app/ios/build/generated/ios/FBReactNativeSpec/FBReactNativeSpec.h

$ stat ./apps/expo-app/ios/build/generated/ios/FBReactNativeSpec/FBReactNativeSpec.h | grep Size
  Size: 1               Blocks: 8          IO Block: 4096   regular file

$ stat ./apps/expo-app/ios/build/generated/ios/out/FBReactNativeSpec/FBReactNativeSpec.h | grep Size
  Size: 89394           Blocks: 176        IO Block: 4096   regular file

$ cp ./apps/expo-app/ios/build/generated/ios/out/FBReactNativeSpec/FBReactNativeSpec.h ./apps/expo-app/ios/build/generated/ios/FBReactNativeSpec/FBReactNativeSpec.h

$ npx expo run:ios

Notice how the header file was empty.

Same here:
$ cat ./ios/build/generated/ios/FBReactNativeSpec/FBReactNativeSpec-generated.mm ./ios/build/generated/ios/FBReactNativeSpec/FBReactNativeSpec.h
$

In our setup (without expo) we don't have the out directory and so unfortunately nothing to copy from...

Continued: I have also notice the .podspec file alongside it was also empty, so I have just copied the entire contents of the directory and I now have a successful build!

Interesting - you are not talking about ./ios/build/generated/ios/React-Codegen.podspec.json, but a podspec file in FBReactNativeSpec? That does not even exist for me 🤔 The two empty files from above are all I have in that folder...

Hello,
I've been struggling my whole afternoon trying to run our app on iOS Simulator and it would not compile (same error message).
I can confirm that I was able to successfully compile with the cp command:
cp ios/build/generated/ios/out/FBReactNativeSpec/* ios/build/generated/ios/FBReactNativeSpec/
npx expo run:ios

Thanks!

I was having the same issue as above (no member named 'react' in namespace 'facebook'), but using the proposed solution of copying the FBReactNativeSpec files resulted in another error (ld: 98 duplicate symbols for architecture arm64). Perhaps not too surprising as two identical copies were included as per ios/build/generated/ios/React-Codegen.podspec.json ("source_files": "**/*.{h,mm,cpp}"), although I do wonder why and how it worked for others in this thread. Oh well, nevermind that for now.
The solution that worked for me was to move the non-empty files like so:
mv -v ios/build/generated/ios/out/FBReactNativeSpec/* ios/build/generated/ios/FBReactNativeSpec/

This is still an issue.


Fixed redis sorted set member uniqueness (zadd)

The problem:
Redis sorted set data type have 2 main properties:

range (integer - sorted)
member (string - unique)

When watchmen adds a new latency measurement to redis the following command is used:
ZADD event range member

Currently watchmen is using the timestamp as the range (because it is automatically sorted) and the elapsed time as the member. For a measurement of 20ms on 1/1/00 00:00:
ZADD event<PHONE_NUMBER>00 20

The issue happens when we have another measurement WITH THE SAME ELAPSED TIME (member):
ZADD event<PHONE_NUMBER>0 20

The fist record will be overwritten because the member value is the same! That's why sometimes the charts misses some data, like this one taken from watchmen's live example:

The solution:
When adding a new latency we must change the member to "timestamp:elapsed" (thus making sure the member is unique). Example:
ZADD event<PHONE_NUMBER>0<PHONE_NUMBER>0:20

Now every time we need to read the latency from redis we must to remove the "timestamp:" part and keep the elapsed time. I also added I check for the ":" character to make sure the solution would still work for the older latency format (added a new test for this check)!

Obrigado! this is awesome =)


PR #1512 reintroduced std::round( )

It seems that previously TFLite Micro had avoided std::round() -- see comment here: https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/kernels/internal/quantization_util.cc#L396-L398
Is this new use inadvertent, or is it something we (as users) need to deal with now?
Thanks!

The new use: https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/kernels/internal/common.h#L413

It is an inadvertent use that was created when https://github.com/tensorflow/tensorflow/blob/v2.10.0/tensorflow/lite/kernels/activations.cc#L122 was moved into common.h to replace the previous gen_lut for more general usage.
Sorry for that, it should be safely replaceable by TfLiteRound.

I have an internal change that switches std::round to TfLtiteRound in the TF repo. Once that is merged, it will get sync'd to the TFLM repo as well and then we should be good to go.


maybe a Bug? responders location_responder.rb:5: syntax error

I put in my controller:
responders :flash, :location
and I get an syntax error:
responders-2.0.2/lib/responders/location_responder.rb:5: syntax error, unexpected ',', expecting keyword_end "no need to include it", caller
If I remove the :location and the ',' it works, and the location behaviour in the action:
respond_with({}, location: root_path())

works fine, it redirects as it should do.
Now I don't understand, I am doing something wrong? or the readme need to be update and the :location in responders is not required because already included?
Thanks
Dinuz

I've encountered the same error on responders 2.0.2 today. I "patched" the gem (added the backslash on the line 4 of the file in question).

This has been fixed in c71303e8a763edeae962fe495b372d339c7db692 and responders 2.1.0 contains the fix, please upgrade.


Race condition fix

While testing activeadmin, our parallel test suite run into the following error:
bin/rspec --color --tty -O .rspec_parallel spec/requests/stylesheets_spec.rb spec/unit/active_admin_spec.rb spec/unit/batch_actions/settings_spec.rb spec/unit/controller_filters_spec.rb spec/unit/devise_spec.rb spec/unit/helpers/scope_chain_spec.rb spec/unit/localizers/resource_localizer_spec.rb spec/unit/menu_spec.rb spec/unit/namespace_spec.rb spec/unit/page_controller_spec.rb spec/unit/page_spec.rb spec/unit/pundit_adapter_spec.rb spec/unit/resource/naming_spec.rb spec/unit/resource/page_presenters_spec.rb spec/unit/resource/routes_spec.rb spec/unit/resource_registration_spec.rb spec/unit/routing_spec.rb spec/unit/scope_spec.rb spec/unit/view_helpers/download_format_links_helper_spec.rb spec/unit/views/components/index_table_for_spec.rb spec/unit/views/components/menu_item_spec.rb spec/unit/views/components/paginated_collection_spec.rb spec/unit/views/components/panel_spec.rb spec/unit/views/components/table_for_spec.rb spec/unit/views/components/unsupported_browser_spec.rb spec/unit/views/pages/base_spec.rb 2>&1
Run options:
  include {:focus=>true}
  exclude {:changes_filesystem=>true}

All examples were filtered out; ignoring {:focus=>true}

Randomized with seed 28908
F..............................................................................................................................................................................................................................................................................................................................

Failures:

  1) Registering an object to administer when being registered multiple times should run the dsl in the same config object
     Failure/Error: Unable to find org/jruby/RubyDir.java to read failed line

     Errno::EEXIST:
       File exists - db
     # org/jruby/RubyDir.java:590:in `mkdir'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-jdbc-adapter-50.4-java/lib/arjdbc/sqlite3/connection_methods.rb:55:in `parse_sqlite3_config!'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-jdbc-adapter-50.4-java/lib/arjdbc/sqlite3/connection_methods.rb:17:in `sqlite3_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:729:in `new_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:773:in `checkout_new_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:752:in `try_to_checkout_new_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:713:in `acquire_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:490:in `checkout'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:364:in `connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:883:in `retrieve_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:128:in `retrieve_connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:91:in `connection'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/fixtures.rb:516:in `create_fixtures'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/fixtures.rb:1015:in `load_fixtures'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/fixtures.rb:977:in `setup_fixtures'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/fixtures.rb:852:in `before_setup'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-rails-3.8.2/lib/rspec/rails/adapters.rb:126:in `block in MinitestLifecycleAdapter'
     # org/jruby/RubyBasicObject.java:2680:in `instance_exec'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example.rb:450:in `instance_exec'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/hooks.rb:373:in `execute_with'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/hooks.rb:606:in `block in run_around_example_hooks_for'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example.rb:345:in `call'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/hooks.rb:605:in `run_around_example_hooks_for'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/hooks.rb:464:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example.rb:460:in `with_around_example_hooks'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example.rb:503:in `with_around_and_singleton_context_hooks'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example.rb:254:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example_group.rb:633:in `block in run_examples'
     # org/jruby/RubyArray.java:2584:in `map'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example_group.rb:629:in `run_examples'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example_group.rb:595:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example_group.rb:596:in `block in run'
     # org/jruby/RubyArray.java:2584:in `map'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/example_group.rb:596:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:116:in `block in run_specs'
     # org/jruby/RubyArray.java:2584:in `map'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:116:in `block in run_specs'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/configuration.rb:2008:in `with_suite_hooks'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:111:in `block in run_specs'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/reporter.rb:74:in `report'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:110:in `run_specs'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:87:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:71:in `run'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/lib/rspec/core/runner.rb:45:in `invoke'
     # /root/project/vendor/bundle/jruby/2.5.0/gems/rspec-core-3.8.2/exe/rspec:4:in `<main>'
     # org/jruby/RubyKernel.java:1022:in `load'
     # bin/rspec:1:in `<main>'
     #
     #   Showing full backtrace because every line was filtered out.
     #   See docs for RSpec::Configuration#backtrace_exclusion_patterns and
     #   RSpec::Configuration#backtrace_inclusion_patterns for more information.

Finished in 42.84 seconds (files took 11.27 seconds to load)
319 examples, 1 failure

Failed examples:

rspec ./spec/unit/resource_registration_spec.rb:53 # Registering an object to administer when being registered multiple times should run the dsl in the same config object

Randomized with seed 28908

Coverage report generated for regular specs 2, regular specs 3 to /root/project/coverage. 6758 / 7559 LOC (89.4%) covered.
SimpleCov failed with exit 1

As I understand it, this is a race condition where two threads would check File.directory?(dirname) and both get a negative answer because the directory does not yet exist, and then both try to create the directory, causing the last thread to crash.
This PR attempts to fix the error by rescuing the potential exception caused by the race condition.

fine with this, since this isn't a hot path (in a production run) we'd like to avoid exception raising.
any objections @enebo ?
@deivid-rodriguez you might want to target 50-stable if you'd like this in next 50.x 51.x 52.x releases

@kares I don't have any objection in the sense this probably is not super common and will only pay a penalty in those particular circumstances.  Otherwise we will need to lock access and I feel like that will be a higher per use penalty.
I guess if this is really common then perhaps we do something else?  Is it though?

I guess if this is really common then perhaps we do something else? Is it though?
pbly not - the reported use-case is pretty much artificial ... its a test-case run

@kares yeah then we won't sweat it until we see -Xlog.exceptions and notice it is happening too much :)

Yeah, if I understood the error correctly, this is happening when creating the db folder, so this code path should probably just be hit once for the whole life time of a production application.

@deivid-rodriguez you might want to target 50-stable if you'd like this in next 50.x 51.x 52.x releases

Sure, yeah. Activeadmin currently supports all of those, so ideally we would want the change backported to all stable branches. I just wanted to start with master to agree on what the best fix is for this, then I can open backports :+1:.

Yeah, if I understood the error correctly, this is happening when creating the db folder, so this code path should probably just be hit once for the whole life time of a production application.

Actually, this is the connection method so I guess this happens once every time we connect to the DB? What I don't understand is that in our specs this folder should've already been created by the time the exception happened. So, I don't understand how this happened.

I got this error again and dug in a bit more but I'm still very confused.
The backtrace is now slightly different since now it shows an absolute path in the error message:
Errno::EEXIST:

  File exists - /root/project/db

  (...)

From reading the surrounding code, it sounds like Rails.root is not yet defined at that point, that's why it tries to read a configuration from the current directory instead of from the actual Rails root (the test application at /root/project/tmp/test_apps/rails_50).
But since RSpec first loads all tests files before trying to run them and I'm requiring rails_helper on top of all of them, and that initializes the test application, I don't understand how that would happen.

I never experienced this again, and I don't like this "solution" anyways, so closing!


Testing if modifications are handled.

I recommend @chrisma as code reviewer for this pull request.
(See reason for why I think this)


implement build-push ci

This PR mainly implements GitHub Action workflows for automatically building and pushing controller, bundle, and daemon images to the repository.
There are three workflows:

build_push_controller: build and push controller and its bundle images
build_push_daemon: build CNI, move to daemon local folder, and build and push daemon image
unittest: run test for controller

To avoid unnecessary build and push,

The code changes related to controller should be pushed to controller branch first to execute build_push_controller.
Similarly, the code changes related to daemon should be pushed to daemon branch to execute build_push_daemon.
As any change related to CI pipelines might affect image build and push, the first two workflows will be also executed on ci branch.

The unittest will be executed for all branches except explicitly non-related doc branch.
Detail modifications:

to reduce confusion, re-add prefix (multi-nic-cni-) to the image name
update daemon/CNI Makefile to suppress folder not found error
update operator-sdk to latest version (v1.23.0)

Signed-off-by: Sunyanan Choochotkaew<EMAIL_ADDRESS>

Thanks for quick implementation!


Updating validations.py python script

Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

CLosing


module not found when using lazy loading in routing

Hi
I am using nested modules and for defining route i am using lazy loading in routing like
{
path: '',
loadChildren: 'app/search/search.module#SearchModule'
}
it's working good, in case i am building same project in angular cli, where in search module i have defined another routing.
Basically, I had made a project using angular cli, not i have moved in to visual studio using webpack, and i am getting this issue.

See #20

Hi @nitin27may I'm closing see issue #20 as @robisim74 pointed out
Thanks Damien


Multiprocessor support

An elegant idea from Scott Lowder:

I watched your presentation at DjangoCon a few weeks ago, you mentioned you were having some trouble with DB issues with multiprocess testing. I am very familiar with that pain, I have an 8+ hour test suite with crazy ad-hoc DB modification all over the tests. I never got the built-in multiprocess testing working against all our code, although I tried some crazy hacks to get it going, such as using a custom DB connection class that checks to see whether your current test database is specific for the current process, and getting a fresh copy if not. I did however get it working another way: 8+ hours is now 22 minutes, spread over 3 hosts and 40 cores, without having to figure out how each test was uniquely incompatible. The solution was to go multiprocess before importing Django, so that I can uniquely patch TEST_NAME in the database settings in the initializer method of each process. Same technique for any other shared resources, like KEY_PREFIX for Memcache settings.

+1

+1


Release-8.3.0

Summary of the Pull Request
OneFuzz Release 8.3.0
8.3.0
Changed

CLI/Service: Don’t validate error codes on client side #3131

Fixed

Agent: Switched from unmaintained Rust dependency tui to ratatui #3155
Agent: Removed dependency on the abandoned Rust users crate #3150
Agent/CLI/Service: Bumped several C#, Python, and Rust dependencies #3118, #3132, #3088, #3106, #3140, #3120, #3145, #3151
CLI/Service: Include a reason when a task has never started #3148
Service: Fixed bug for scale-in protection #3144

Codecov Report

Merging #3159 (36b80b4) into main (c76cb9b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #3159   +/-   ##
=======================================
  Coverage   31.59%   31.59%
=======================================
  Files         308      308
  Lines       36562    36562
=======================================
  Hits        11553    11553
  Misses      25009    25009


Change behavior of shareReplay

Feature Request
Is your feature request related to a problem? Please describe.
I'm always confused by the current implementation of shareReplay because it behaves different than the share operator.
Describe the solution you'd like
It want to suggest shareReplay should reconnect to the source if the source was completed and a new observer subscribes. But not like in rxjs 5. It should still replay the last n values of the completed source on new subscription.
This is an example implementation.
function shareReplayNew<T>(count: number) {
  let lastSubject: ReplaySubject<T>;

  return function(source: Observable<T>): Observable<T> {
    return source.pipe(
      multicast(() => {
        const rs = new ReplaySubject<T>(count);
        if (lastSubject) lastSubject.forEach(v => rs.next(v));
        lastSubject = rs;
        return rs;
      }),
      refCount()
    );
  };
}

Additional context
I created a Stackblitz to demonstrate the desired behavior.

Changing it (again) will break and confuse other developers: https://ncjamieson.com/whats-changed-with-sharereplay/ IMO, devs using shareReplay should be explicit about the behaviour they need and should specify the config argument. There is a lint rule to enforce this.

@cartant Thanks for your reply. I appreciate the last changes on refCount default behavior. This is quite handy.
But my suggestion is about how shareReplay behaves on source completion. I think this is independently of the refCount setting. If I understand this correctly, share is reconnecting on the source on a new subscription, even after the source completed or errored. shareReplay is not doing so. This feels kind of inconsistent to me.

Completion effects unsubscription for all subscribers - dropping the red count to zero - so the two are directly related. share only connects to the source of the ref count is being incremented from zero.

Sure, but the ref count drops to zero independently of the reference counting setting being active or inactive. This is what I meant with it's independently from the config setting refCount. But I definitely agree it has something to do with ref counting.
shareReplay connects to the source initially if the ref count is incremented from zero first. share does this always. This is what feels inconsistent to me.

Okay, I see what you mean. The replaying of the complete notification is intentional and that's not going to change. You can get reset-on-complete behaviour using multicast:
const shared = source.pipe(
  multicast(() => new ReplaySubject(/* whatever */)),
  refCount()
);

It's likely that the multicasting infrastructure will be replaced in version 7 with something that's more flexible and will let you specify the reset-on-complete behaviour in the configuration passed to share - see https://twitter.com/TheAnkurTyagi/status/1327887768287014914 However, those changes will still include a shareReplay that behaves as it does now.

Closing for the reasons mentioned in the comment above.

The solution for version 7 for the equilavent of shareReplay({ refCount: true, bufferSize: 1}) with reset for completed observables is:
share({
  connector: () => new ReplaySubject(1),
  resetOnError: true,
  resetOnComplete: true,
  resetOnRefCountZero: true
})


Update CMakeLists.txt to add install targets for the libraries and the header files

This PR modifies the CMakeLists.txt in the /snapshots/hacl-c and in the / folders, so that when the Makefile is generated from them a make install target is created.
After a successful make build in the root directory, installing the compiled libraries is then just  a matter of cd build && make install.
The prefix for installation can be tweaked when calling cmake by invoking it as
cmake -DCMAKE_INSTALL_PREFIX:PATH=/path/to/prefix ...
The static and the shared libraries are installed to $PREFIX/lib while the header files to $PREFIX/include/hacl.

@romen Thank you for the patch ! I cherry-picked the commit for the root CMakefile, I am currently working on the snapshot generation at the moment, so I will update the hacl-c snapshot with this change soon enough...
https://github.com/mitls/hacl-star/commit/72f40a4e500f50f54fd19ecb76517c281a1aa48d

@beurdouche  Thanks for the quick feedback!


could not create deployments

Hi,
The command below creates 3 kubernetes clusters and does not create necessary pods and deployments like istio prometheus spinnaker
gcloud deployment-manager deployments create --config workshop.yaml adv-bc-$(date +%s)
Also i deleted all service accounts associated with dm's deployment. Are there any additional tasks to do? When you delete service accounts  only prometheus is deployed. Could you please assist me to re create the lab environment in the same project.
regards.

It's difficult to debug remotely without more detail but it is possible you are hitting a CPU quota limit that is preventing the deployment from completing successfully. Please increase the CPU quota in the us-central1 region and try again.
If you plan on completing the lab modules, you'll find that the lab content in this repository is currently inconsistent with what is deployed, with different regions in use and so on. This is because the labs have now been imported into the Qwiklabs environment (from where this training course is designed to be run), and modified in-place. I plan to merge these changes back in to this repo, but can't give an estimate on when this will be complete.

Hi @henrybell
I tried to figure out but the case is not related with Quotas. I deleted all the vms and checked the Quotas and tried to complete the initial setup for several times. Thank you very much for your quick response. I will debug it and inform you.
regards

Hi @henrybell
In newly created projects it is working like a charm. On the other hand, you have to delete everthing. Instead of deleting service accounts / clusters  vms ..etc, creating a fresh project is ok.


Support es7 Rest/Spread properties

es7 proposal : https://github.com/sebmarkbage/ecmascript-rest-spread
Spread properties
Typing
In my opinion the goal of this method is to be able to duplicate an object and changing some props, so I think it's particularly important in this case to not check duplicate property declaration :
var obj = { x: 1, y: 2};
var obj1 = {...obj, z: 3, y: 4}; // not an error

I have a very naive type check algorithm for a similar feature (JSXSpreadAttribute) in my little jsx-typescript fork: I just copy the properties of the spread object in the properties table when I encounter a spread object, and override those property if I encounter a declaration with a similar name.
Emitting
jstransform use Object.assign, babel introduce a shim:
var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };

We could either force the presence of assign function on ObjectConstructor interface, or provide a similar function (with a different name).
I think that the optimal solution would be to not emit any helper in es6 target (or if Object.assign is defined), and to emit an helper function for es5, es3.
var obj = { x: 1, y: 2};
var obj1 = {...obj, z: 3};

/// ES6 emit
var obj = {x: 1, y: 2};
var obj1= Object.assign({}, obj, { z: 3 });

//ES3 emit
var __assign = function (target) {
	for (var i = 1; i < arguments.length; i++) {
		var source = arguments[i];
		for (var key in source) {
			if (Object.prototype.hasOwnProperty.call(source, key)) {
				target[key] = source[key];
			}
		}
	}
	return target;
};

var obj = {x: 1, y: 2};
var obj1= __assign({}, obj, { z: 3 });

Rest properties
Typing
For simple object the new type is a subtype of the assignation that does not contains properties that has been captured before the rest properties :
var obj = {x:1, y: 1, z: 1};
var {z, ...obj1} = obj;
obj1// {x: number; y:number};

If the destructuring assignment has an index declaration, the result has also a similar index declaration:
var obj: { [string: string]: string };
var {[excludedId], ...obj1} = obj;
obj1// { [string: string]: string };

new/call declarations are obviously not captured:
var obj: { (): void; property: string};
var { ...obj1} = obj;
obj1// { property: string };

Emitting
It is not possible to emit rest properties without an helper function, this one is from babel:
var obj = {x:1, y: 1, z: 1};
var {z, ...obj1} = obj;

var __objectWithoutProperties = function(obj, keys) {
    var target = {};
    for (var i in obj) {
        if (keys.indexOf(i) >= 0) continue;
        if (!Object.prototype.hasOwnProperty.call(obj, i)) continue;
        target[i] = obj[i];
    }
    return target;
};

var obj = {x:1, y: 1, z: 1};
var z = obj.z;
var obj1 = __objectWithoutProperties(obj, ["z"]);

Edit: added some little typing/emitting example

We'd probably need some examples of how this could plausibly be emitted in downlevel (if that's in scope).

@RyanCavanaugh, I added some little emitting example and typing idea.
I would like to work on that one since anyway it's more or less a jsx feature and I will need to add it to my fork, but if it's added to typescript core it's better ^^.

I recently discovered this feature in ES7 via this article. I have to say, it's quite handy!
Would love to see this in TypeScript!

Any updates on this? Would love to see this in 1.6 as it would come super handy when using with React :smile:

@prabirshrestha for the record, we currently have the property spread operator for JSX.

@DanielRosenwasser Could you elaborate? Does that mean this works on master with the --jsx flag? Does that include rest properties or just spread properties?

Sorry @mnpenner and @prabirshrestha, yes, I meant on master. @RyanCavanaugh knows more about this than I do, but I believe it's just spread properties.

JSX supports spread attributes, e.g. <TagName {...spreadedExpr} />. Nothing to do with the ES6 spread operator other than sharing the same token and having roughly equivalent semantics.

I'm very interested in both Redux and React, the manipulation in state is made much easier with this. Would love to see this implemented.

Rest/Spread is approved for Stage 2 now https://github.com/tc39/tc39-notes/blob/master/es7/2015-07/july-30.md

We want to wait for the proposal to reach Stage 3 before addressing this.

It's very useful in react and redux , please implement it as soon as possible , please :-)

Here's a helper module I've been using to work around this. It's not ideal as you have to specify all the keys twice, once on the left hand side and once as strings on the right hand side, but I can't think of a better way to do it. Any feedback welcome, I'm sure there's edge behaviour I've missed!
https://gist.github.com/tomduncalf/fbae862b123445c117cb

Is this something you'd accept a patch for? (to be merged once it reaches stage 3). And if so, have any pointers of where to start making changes to support it?
This is the last ES7+ feature that my team heavily uses that's preventing us from switching over to typescript; would definitely love to have to sooner, if possible.

We would consider a PR here. One note though, wiring the type system for this feature is not a simple task. If you are interested in perusing this I would keep it incremental, and would start by parsing then emit then type checking. @sandersn should be able to help you if you have any questions.

Just a note for those interested in using this with Redux.  I agree the notation is convenient.  But I've actually been getting by just fine without it by leverage the updeep library.  I created some basic typings for it and it works pretty well.  I even have a simple library that implements an updeep based store and actions.  If anybody is interested in this, just contact me.
In any case, :+1: for spread operators in TS. :smile:

@xogeny I would be very interested in having a look at that library. Thanks

@cur3n4 I have a repository where I've been playing with these ideas.  It changes quite a bit (since this is all still evolving).  I was using a special modules that leveraged updeep initially and that functionality is still in the library.  But I've stopped using it because I found it difficult to maintain the necessary type constraints.  I suspect if Typescript had something along the lines of Java's super generic type constraints, updeep (and several other libraries, like lodash or ramda) could be made a lot more type safe.
But don't get me wrong, I still think a spread operator would be really useful.  It would actually allow you to express and do things safely and tersely in the language that I don't see how to do with the current type system (i.e., allowing you to describe the right type constraints on external libraries).  For the moment, I sacrifice the terseness for the safety (while the updeep approach sacrificed safety for terseness).

After using Babel for past few months, converted my project to TS and had to go and redo all these. Would love to see this implemented!

:+1:

would love to see this.

+1

must have feature, please implement

+1

+1 much nicer syntax than Object.assign + JSX support

+1 it a must have for react development for passing props down (var { checked, ...other } = this.props;. see the react docs

it a must have for react development

Let's be honest, it is a convenience, not a must have.  The proposal is at Stage 2 with TC39.  The TypeScript team have made it clear, they don't want to consider implementing things that aren't originated in TypeScript until they are Stage 3.  The place to "+1" is with TC39.

@kitsonk - you can't expect good adoption when frameworks like react / etc specifically call out these types of things in their docs. People will start using Typescript, see all these issues and go back to Babel. Thats what i did.

Well, I think we are talking about a broader topic.  Not one browser vendor will implement anything that isn't in Stage 3 (unless they personally like it).  TC39 have been trying to give some level of organisation for their part of the web.  TypeScript has gotten bitten, hugely, by jumping the gun before (modules, and look at the chaos that that has caused since).  I respect that they are trying to at least put some guidance and structure around what they are willing to implement and when.  Is there some other suggestion of what standard should be used? I don't think "because X framework mentions it in their docs" would be a good one.

frameworks like react / etc specifically call out these types of things in their docs

Which they mark as only a proposal and then go on to instruct you how to jump through hoops to configure Babel 6 to use it.  I would rather blame frameworks for depending on syntactical technologies that are only at a draft specification.  Personally, we in Dojo, got burned by Object.observe and I am reticent again to try to depend on technologies before they get to Stage 3 in Dojo.
The particular path is a lot more than just supporting transforming the syntax on emit for TypeScript.  There are all the type inference that needs to follow with it.  I have looked at the draft spec to understand, but where do symbols go?  Where do non-enumerable properties go?  I assume in both cases they just disappear into the ether, but there will be all sorts of type splitting and merging that will need to go on in the background for this, so I can totally understand that TypeScript team saying "ok, let's hold off on this until TC39 has really kicked the tires on this".

Overall I think that TS is quite well featured today. There was a time (around 1.4 ~ 1.5 I think) where I was frustrated by lack of some ES2015 features, but as of today TS has catched up pretty well with the standard.
Of course, there is sometimes feature envy wrt other languages. For instance, Babel offers pretty much any JS proposal, including "experimental" stuff. Personally, I am looking forward to this issue and the function bind operator as well.
But at the same time we have to acknowledge that the TS team takes compatibility a lot more seriously than Babel does. They don't want to change the semantics of your code between releases, or simply remove a feature, which is what Babel does. For some (enterprise?) projects that's important.
I can also understand that MS doesn't want to invest a lot of resources into features that may get dropped, the Object.observe fiasco comes to mind. Actually, they said they would consider a PR on this one for instance :wink:.
In the past some features were added early behind an experimental compiler switch (e.g. async), which meant you had to opt in and acknowledge that the feature might change or get removed in future releases. Maybe that could be done again for the most popular requests?

Just a quick note here. We have been rather slow in adopting stage 0-1 proposed ES features mainly due to backward compatibility concerns. We do follow the discussions in the TC39 meetings closely, and participate directly in the meetings or in proposal preparations before the meetings; and when we put a feature in we would like to know what that means to users who take a dependency on them.
If you look at the TC39 process documentation a feature at stage 1 can expect "Major" post acceptance changes. This was the cases for classes, modules, iterators, and almost all non-trivial ES6 features..
Putting my user hat on, breaking changes to syntax can be mechanical to respond to, whereas breaking changes to semantics can be extremely hard to catch and fix; this can be a huge cost on teams using any of these features, and/or a blocker for adopting newer versions of the tools. and we would like to minimize that when possible. The is why we have adopted a policy to enable features by default when they reach stage 3, and under an experimental flag before that (e.g. decorators).
Having said that, the object property spread and rest are on our roadmap, and we do plan to tackle it in a future release.

Maybe it is worth consider to add to compiler ability to inject some 3rd party extensions, as done in babel ?

Another thought: what about support for preprocessing typescript sources (with Babel)?
If we can get Babel (or whatever system) to expand object spreads into Object.assign calls, that might work well enough?

@kitsonk - broader topic absolutely, dang wish github had better discussions ;). I disagree w/ you quite a bit tho:

. TypeScript has gotten bitten, hugely, by jumping the gun before (modules, and look at the chaos that that has caused since).
They went off and did their own implementation mirroring .NET not using anything from the community, thats their own fault.

put some guidance and structure around what they are willing to implement and when
they implement decorators ( stage 1 ), class properties ( stage 1 ), etc.

I don't think "because X framework mentions it in their docs" would be a good one.
your kidding right? react is the most popular framework and has a projection to stay that way for awhile now. not supporting that would really hurt adoption.

I think TypeScript has a lot of catching up to do with Babel and its got a lot of challenges such as: really difficult to start using it with an existing app, migrating from babel to typescript for A2 is a NIGHTMARE!, lack of decoupled plugins makes working w/ Node extremely difficult.

your kidding right? react is the most popular framework and has a projection to stay that way for awhile now. not supporting that will/has really hurt adoption.

I have a lot of respect for React, but I am not kidding.  It isn't the only game in town and it is certainly on a large hype curve.  6 months ago it was React + Flux, now React + Redux is the flavour of the day.  A year ago, Angular and Polymer.  Two years ago it was Backbone and Ember. Six years ago it was Dojo, MooTools, jQuery, gwt, ExtJS, etc...

don't start framework wars here :exclamation:
{..., } syntax is much handsome as is, no matter any framewrok

They went off and did their own implementation mirroring .NET not using anything from the community, thats their own fault.

What exactly are you referring to? I can only assume you are referring to the module as namespace issue, which has nothing to do with .NET and is also not one of the major pain points with modules in TypeScript.

+1 for this to be included in typescript

let typescript = { ...typescript, object_spread };  // Yes please.

Bummer there's no movement on this, I really hope this reaches stage 3 soon. Going to be killing syntax error highlighting in VSCode if possible

I wonder if Salsa changes anything to the game?
I understand that TS doesn't want to implement unstable features early: limited resources, shielding us users from possible breaking changes, etc.
But now that Salsa is VS Code default JS engine, the pressure for newer JS syntax (at least just the syntax, not full TS typing) is going to increase. Especially given the popularity of Babel.
Is Salsa going to be able to accept a broader syntax faster than TS?

+1

Is this going to be in 2.1 rather than 2.0? :cry:
https://github.com/Microsoft/TypeScript/wiki/Roadmap#21

Considering how large 2.0 is already turning out to be, I'm not too suprised.

We try to keep the releases 6-8 weeks apart; so that limits what can go in. we are doing some emitter refactoring at the moment, and should be able to add this feature once that is completed.

So is this fixed?

...standalone helper function for spread attributes
https://github.com/Microsoft/TypeScript/releases/tag/v1.8.10

Not exactly. That fix is specifically for JSX spread attributes:
const props = { foo: "bar" };
return <SomeComponent {...props} />;

which already worked, before React v15 removed an undocumented internal function that TypeScript's JSX compiler depended on. Oops 😃
Object spread is a different proposal, with an admittedly similar syntax (it may have even been proposed by Facebook engineers and inspired by the JSX equivalent, although I don't know for sure).

So since {...props} does not yet work, how would you using TypeScript achieve something similar to that?

So since {...props} does not yet work, how would you using TypeScript achieve something similar to that

Use xtend : https://www.npmjs.com/package/xtend it has great typings : https://github.com/typed-typings/npm-xtend (by @blakeembrey :rose:) thanks to the intersection type

Or don't use any library at all!
Object.assign({} /*new object*/, props /* add all attributes of props */, {
   // add additional props
  bar: "baz"
});

It's a bit verbose, but it is native to ES2015, so if you've already got a polyfill for that you're solid.

This operator is one of the main reasons we decided to use babel in a project instead of typescript.
Completely changes the game for handling objects immutably.

As alternative is there anything planned that let you plug in custom transformation to TSC like you can do in babel? Maybe even based on the same API, that would be awesome and solve problems like this.

As alternative is there anything planned that let you plug in custom transformation to TSC like you can do in babel

Yes. Just search for the [Transforms] tags. These are needed to get proper async/await/generator transpilation into the TypeScript compiler :rose:

After a little search, you are referencing this? https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
Sounds great.I just do not finde anything related to the Object Spread for that API. Maybe it would be a nice little project to solve this issue based on the Compiler API :)

@Niondir sorry for not providing better help in my original message. I am talking about https://github.com/Microsoft/TypeScript/issues/5595 < which will allow pluggable emit for ESNext syntax.  TypeScript is a bit more involved than Babel because it needs to have semantic type system understanding of your code so object spread work will probably need to come from TypeScript team.
Having a plugin based emitter would make this easier. Yes you would use the compiler API (or potentially fork the compiler in the beginning till a plugin system is made public + for the semantic / scanner logic)

This might be a question for another issue, but wouldn't it be possible to add an option "allow-experimental" and have TypeScript allow future things? For example, allow spread operator and output as is. I can handle that with babel afterwards.
This is a must have feature for some projects I'm working on and I cannot migrate without essential stuff like this. It would be awesome if I could.

I'm not sure how we'll eventually ship it, but I started work on rest/spread in object literals and destructuring. Right now the plan is to use our __assign polyfill for emit.

This is the best news that i heard in past 3 months!

Unfortunately, it turns out that getting this to work with generics is a lot of work. You have to properly support code like this:
function addId<T>(t: T): {...T, id: number} {
    return { ...t, id: 1 };
}

As you can see, addId returns a new kind of type, an object type that includes a spread operator.
After some discussion, we decided to delay until 2.1 and look at this again. We need to focus on getting 2.0 features done right now.

Forgive my ignorance... but it feels like addId in that case be able to return T & { id: number }? Or is there some quirk of union types that stops that from being an optimal solution?

I think he mean that actually T should be checked, since you can pass anything to T
addId<boolean>(true);
addId<number>(5);

Babel silently ignores such statements  let { ...true } but i think they shouldn't be valid

It's not T & { id: number } because if T has an id property, it will get overridden.
On the other hand, the intersection, the resulting type of id would be the intersection of  T's id type and number.
So what @sandersn is saying is that you need a separate type operator.

While we'd definitely benefit from a better typing solution here, Object.assign already exists and naively use intersections as an output type. Why couldn't we have, as a stop gap measure, the rest operator doing exactly what Object.assign does ?
It would ease a lot of concerns about the missing feature and it wouldn't bring unwanted behaviour since people already use Object.assign instead.

Was actually extremely surprised this wasn't supported.

As soon as we get this the merrier. Will work great with react!

I would be happy even if it was not typed

@2426021684 It might sound reasonable but consider the implications. If it is not typed, that is to say typed as any, any uses of the syntax will percolate any to the leaves of expressions.

@aluanhaddad it would be the same as Object.assign which is the workaround everyone has to use because they have no choice (see JabX post above)

Please consider implementing @JabX's suggestion in the near term. This proposal is stage 3 in all but name, it is definitely going to be a part of the standard, and has very clear and simple semantics. Putting in place the syntactic support for property spreads + naive typing of Object.assign would be a very helpful stopgap while we wait for the "right" implementation. Don't let perfect be the enemy of good.

Rest properties is extremely important with React 15.2 as can be seen here https://facebook.github.io/react/warnings/unknown-prop.html
const divProps = Object.assign({}, props)
delete divProps.layout

is very ugly, especially if the amount of props on a component is higher

for those who can't wait anymore here is a workaround:
function steal(result: any, data: any): any {
    for (var key in data) {
        if (value.hasOwnProperty(key)) {
            result[key] = (<any>data)[key];
        }
    }
    return result;
}

export class SameAs<a> {
    constructor(public result: a) { }
    public and<b>(value: b): SameAs<a & b> {
        return new SameAs<a & b>(steal(this.result, value));
    }
}
export function sameAs<a>(value: a): SameAs<a> {
    return new SameAs(steal(<any>{}, value));
}

// example of use:

const mixture = sameAs(one).and(anotherOne).and(yetAnotherOne).result; // <-- ta-da!

Here is what I came up with for a poor (typescript) coder's destructuring operation:
declare interface ObjectConstructor {
  destruct<T extends Object>(data: T, props: any): T;
  destruct<T extends Object>(data: T, ...propNames: string[]): T;
}

function destruct<T extends Object>(data: T, ...removals: string[]) {
  const rest = <T>{};

  const keys = removals.length === 1 && typeof removals[0] === 'object' ?
    Object.getOwnPropertyNames(removals[0]) :
    <string[]>removals;

  Object
    .getOwnPropertyNames(data)
    .filter(x => keys.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return rest;
}

Object.destruct = destruct;

// Usage example:

const srcObj = { A: 'a', B: 'b', C: 'c' };
// destruct using an object template
const onlyC = Object.destruct(srcObj, { A: null, B: null });
// destruct using property names
const onlyA = Object.destruct(srcObj, 'B', 'C');

The obvious advantage of using an object layout is that you can type the layout and at the very least get type conflicts if you happen to refactor anything.

export function rest(obj, delete_keys) {
  var target = {};
  for (var key in obj) {
    if (delete_keys.indexOf(obj[key]) >= 0) continue;
    if (!Object.prototype.hasOwnProperty.call(obj, key)) continue;
    target[key] = obj[key];
  }
  return target;
};

const {children, data} = this.props;
const props = rest(this.props, [children, data]);

IMO, not much is gained by posting non-typesafe workarounds for this problem.

agreed, i'm working on a more typesafe version right now.

Another stab at this:
The main object extension:
declare interface ObjectConstructor {
	rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]): { rest: TData, props: TProps };
}

function rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]) {
  const rest = <TData>{};
  const props = <TProps>propsCreator.apply(this, [ data ]);

  Object
    .getOwnPropertyNames(data)
    .filter(x => props.hasOwnProperty(x) === false && omits.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return {
    rest,
    props,
  };
}

Object.rest = rest;

A React specific extension:
declare module React {
  interface Component<P, S> {
    restProps<T>(propsCreator: (x: P) => T, ...omits: string[]): { rest: P, props: T };
  }
}

function restProps<P, S, T>(propsCreator: (x: P) => T, ...omits: string[]) {
  return Object.rest((<React.Component<P, S>>this).props, propsCreator, ...omits.concat('key', 'ref'));
}

React.Component.prototype.restProps = restProps;

Some sample usage:
const src = { A: 'a', B: 'b', C: 'c' };
const { rest, props } = Object.rest(src, x => {
	const props = { A, C } = x;
  return { A, C };
});

All typing should be preserved. the only part that bugs me is the props creator because it requires duplication. I think I could hack it and assume the destructured object lives at _a but that seems dangerous...
Here is a Fiddle to play around with.

I'm thinking returning an array might make more sense, as you can rename the outputs as needed.

Since mostly people here want to use this with react, why not implement this just for tsx files until it reaches stage 3?

This very useful not only for react, but in redux reducers for example.

I think the tags and missing milestone on this are a bit out of date.  Because this is committed and being worked on (#10727) for TypeScript 2.1.  So no need to debate the value of it anymore.
ping @mhegazy

Updated the tags. I should clarify that the reason this has not been implemented yet is not that the value, but rather the complexity of the type system implementation. the transformation it self is rather trivial, i.e. {...x} into Object.assign({}, x). the issue is how these types are pretested and how they behave. for instance for a generic type parameter T is {...T} assignable to T, what about {x: number, ...T}, what about if T has methods, etc.. https://github.com/Microsoft/TypeScript/issues/10727 provides a more in depth explanation of the type system changes needed.

I fully appreciate that the type system augmentations required for an ideal treatment of this feature are not trivial. I would just reiterate that,

putting in place the syntactic support for property spreads + naive typing of Object.assign would be a very helpful stopgap while we wait for the "right" implementation. Don't let perfect be the enemy of good.

It seems like the proposal has reached stage 3: https://github.com/tc39/proposals

@ddaghan your example with tsx won't work

any timeframe for this feature?

@SpyMaster356 I've been lurking this for a while and it looks like it's close. @sandersn has been kicking ass on this for (at least) the past few weeks. 🙌
You can follow along here (https://github.com/Microsoft/TypeScript/pull/12028) and here (https://github.com/Microsoft/TypeScript/pull/11150)

Some one should update the Roadmap

Forgive me that I'm sure this is answered somewhere in this large thread, but I am playing with this in the nightly and there was unexpected behavior:
interface State {
  a: string;
  b: number;
}

let state: State = { a: "a", b: 0 };

state = {...state, x: "x"}; // No error

I was expecting an error that x is not a known property of State. Is this not how the feature works?
For example, my current workaround before this PR was this:
state = update(state, { x: "x" }); // Error: Property 'x' is missing in type 'State'.

function update<S extends C, C>(state: S, changes: C): S {
  return Object.assign({}, state, changes);
}

Is it possible to achieve this with object spread/rest?

Object Rest and Spread, as per the ES proposal, behaves similar to Object.assign. the last mention of the property "wins". no errors are reported. in the example you had, the type of {...state, x:"X"} is { a: string, b:number, x:string }; and this type is assignable to State and thus the assignment works. this is the same as saying let state: State = { a: "a", b:0, x: "X" }; would be allowed as well.

But that's what I'm confused about: let state: State = { a: "a", b:0, x: "X" } gives the error Object literal may only specify known properties, and 'x' does not exist in type 'State' which is what I want... why is it assignment when coming out of an object literal containing a spread?

sorry.. object literals are a special case. my example was wrong. here is a better example:
let obj = { a: "a", b:0, x: "X" };
let state: State = obj; // OK

The issue here is if rather subjective. When the compiler sees  let state:State = { a: "a", b:0, x: "X" }, chances are x is a typo, either a stale propoerty that was left off after refactoring, or a type for an optional property, that is why it is reported as an error.
however, if you spread an object, let's say let myConfig : State=  { a: 1, ...myOtherBigConfigBag}, if the myOtherBigConfigBag has a few properties that you do not care about, you just need the a and the b, an error here would force you to keep these two interfaces in sync, or cast to make these errors go away.
that said. we should reconsider this decision. filed https://github.com/Microsoft/TypeScript/issues/12717 to track that.

I see. I love your idea in #12717, that's exactly what I was thinking. I would actually like such behavior even for the spread props but I can see your point that it's very subjective and might be annoying for some common JS use cases.

@aaronbeall I agree, it would be annoying for common JS use cases...  Most of the time, you just want to ensure the object has the shape of the interface specified and not directly inspect the spread object, the current implementation is okay IMO

Hi guys, Congrats for the great release! Now is time for a deserved rest... speacking of whitch I've an issue with the rest operator :)
Using React you tipically have a component like:
export interface MyLinkProps extends React.HTMLAttributes {
    myUrl: string
}

class MyLink{

    render(){
      const {myUrl, ...attrs } = this.props;
     return <a href={calculate(myUrl)} ...attrs>Click here</a>;
   }
}

The issue is that when you hover with the mouse over attrs you get the list of all the properties (hundreds) instead of React.HtmlAttributes.
I know that typescript is structurally typed and all that, but could be possible to assign an explicit type to the rest variable?
Some alternatives:
    const {myUrl, ...attrs as React.HtmlAttributes } = this.props; //Is not really a casting

    const {myUrl, ...attrs : React.HtmlAttributes } = this.props; //conflicts with ES6?

    const attrs : React.HTMLAttributes;
    const { myUrl, ...attrs } = this.props;  //re-declare the variable

@bondz Well, its not true in 100% of the uses in my project. :) But in another project it may be very annoying. In my case I'm using Redux and making heavy use of immutable state, which means to update or combine state objects I must copy all props onto a new object literal... in all cases I want 100% type safety that I'm trying to copy the right data onto the target state interface. Currently I use functions to ensure this safety, but I would prefer to use object spread because its cleaner.

https://github.com/Microsoft/TypeScript/issues/2103#issuecomment-145688774
We want to wait for the proposal to reach Stage 3 before addressing this.

Seems it's already state 3, any plan of supporting this?
Btw, we use VSCode mainly for ES development, not TS yet :)

@evisong this feature has shipped and is already available in the latest version of vsCode. Update your vsCode to version 1.8


Incorrecting test summary backbone.js

Incorrecting test
<% _.each(items, function( item ){ %><input value="<%= item.name %>" /><% })%>
Use for test
<% _.each(items, function( item ){ %><input value="<%- item.name %>" /><% })%>

Could you explain? I have no clue how this relates to Mithril.

He probably means from the "Test Summary" link on the main website page which links to http://mithril.js.org/comparisons/backbone.safety.html

The point of the comparison was that you had to explicitly use <%- to avoid an attack, but documentation uses <%= as the default interpolation syntax and it's extremely reasonable to expect that a developer would use the wrong thing


Language and time format

Now it fits into develop

fixes #240

fixes #450

fixes #457

moved clan to another branch

Unit tests coming soon

Coverage increased (+1.07%) to 50.924% when pulling 38d8e4975208a3d89f1c1037178d6b4d63de6094 on languageAndTimeFormat into 6b8de78704862f4e5db5c506d4f72bc16e3a08ec on develop.

Coverage increased (+1.2%) to 51.093% when pulling 6d8235e80a13c445c7b722a59b6c079b16cef706 on languageAndTimeFormat into 6b8de78704862f4e5db5c506d4f72bc16e3a08ec on develop.

Coverage increased (+1.3%) to 51.151% when pulling 8f13a2f884044bf108161a9295a3c698dba3edd0 on languageAndTimeFormat into 6b8de78704862f4e5db5c506d4f72bc16e3a08ec on develop.

Coverage increased (+1.2%) to 51.093% when pulling 829be4358ccedc5dfcc32ebb03493d6aa7fb9277 on languageAndTimeFormat into 6b8de78704862f4e5db5c506d4f72bc16e3a08ec on develop.

Coverage increased (+1.3%) to 51.126% when pulling 7ddca99d8ad2b752c23b50b09e41c9650824dc5b on languageAndTimeFormat into 6b8de78704862f4e5db5c506d4f72bc16e3a08ec on develop.


patch: Fix incosistent between tying and comments in 'from_native' when 'strict=True'

What type of PR is this? (check all applicable)

[ ] 💾 Refactor
[ ] ✨ Feature
[x] 🐛 Bug Fix
[ ] 🔧 Optimization
[ ] 📝 Documentation
[ ] ✅ Test
[ ] 🐳 Other

Related issues

Related issue #833
Closes #

Checklist

[ ] Code follows style guide (ruff)
[ ] Tests added
[ ] Documented the changes

If you have comments or can explain your changes, please do so below.
I believe this branch should be merged from my personal repository into our development repository. This is a careless mistake which I push locally wrong to our dev. Sorry for mass up, if need, I would like to deleted the current and reopen one.

Close because unexpected mypy error, and will reopen a proper one.


Improve repo code for cfme-rolling-os-update-and-upgrade.yml

Need to improve repo code design to automatically choose the correct version when using cfme-rolling-os-update-and-upgrade.yml.  The version is currently hardcoded into the playbook.

Could also remove the repo code and make the assumption the correct repos are enabled.  Thoughts @itewk @henrygrover ?

Done.

@curt-matthews just so you know if you put the issue number in the git commit message it will link to the issue here in git. so like adding "issue #8" in the comment.


[e2e]: container tag main gcp-workload-identity slsa3

Repo: https://github.com/slsa-framework/example-package/tree/v32.0.145
Run: https://github.com/slsa-framework/example-package/actions/runs/5285805331
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container.tag.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container.tag.main.gcp-workload-identity.slsa3.yml
Trigger: push
Branch: v32.0.145
Date: Fri Jun 16 03:09:21 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/v32.0.146
Run: https://github.com/slsa-framework/example-package/actions/runs/5296020405
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container.tag.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container.tag.main.gcp-workload-identity.slsa3.yml
Trigger: push
Branch: v32.0.146
Date: Sat Jun 17 03:14:23 UTC 2023
Tests are passing now. Closing this issue.


timebar missing

What is your question?
The time bar just vanishes or its still the same color when I try to tween its color
setProperty('timeBar.color', 'DB115B')

doTweenColor('timeBarColor', 'timeBar', '#DDB115B', 0.2, 'linear')

these two just doesn't work

setProperty('timeBar.color', 0xDB115B)

It works, Thanks!


no_std build for tendermint-rs (October 2021 snapshot)

This is a fork of #988 as #988 has caught up to master, but with no_std support being broken.
This fork is lagging behind master since October 2021, and no changes are going to be made to keep this branch up to date with master.

[ ] Referenced an issue explaining the need for the change
[ ] Updated all relevant documentation in docs
[ ] Updated all code comments where relevant
[ ] Wrote tests
[ ] Added entry in .changelog/

This can now be closed with master already supporting no_std.


Fix logic error in core core for key static metadata

Coverage remained the same at 97.858% when pulling e1350765b36c4eadbd366557a4c7d2108b5ccc72 on MrCreosote:master into 5cae48a07b0ebe02511757a115e7d5aa4aa19b03 on kbaseIncubator:master.


Added alternative titles to search index

Fixes #235
By adding this users will be able to search for anime/manga with languages other than Japanese/English.
E.g. Attack on Titan's spanish title: Ataque a los

@irfan-dahir in prod env there will be a need to reindex anime/manga in typesense


update to latest runtime rc and update protos baseurl

Description
update to latest runtime rc and update protos baseurl
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Extended the documentation

The proto being updated resulted in a required change bc in Dapr we updated the Shutdown request. See the prior version we referenced in the java-sdk of the dapr protos version (v1.12.2) had:
// Shutdown the sidecar
rpc Shutdown (google.protobuf.Empty) returns (google.protobuf.Empty) {}

And now we have in runtime v1.13-rc.5:
// Shutdown the sidecar
rpc Shutdown (ShutdownRequest) returns (google.protobuf.Empty) {}


Initial QField Configuration

Generate QGIS project with 4 layers: survey (tracking), trip, environment and observations.
Configure layers and forms as outlined in:
New form layout_FOR IDOX.xlsx
This configuration should consider the 25 user story issues labelled "Must have"

@emmawilsonJNCC The ICES binocular vocab (http://vocab.ices.dk/?ref=1719) does not include "Binoculars used for ID only". Does this need adding? If not which of the values from the vocab is the default?

Hi Claire, please could the options within 'use of binoculars' be 'binoculars used for ID only', 'binoculars used for scanning far ahead' and 'binoculars used extensively for scanning ahead and to the side'. These are not the exact same as the ICES options but that's ok - the ICES option of 'no binoculars used' would potentially be confusing for volunteers, hence we have amended this.
From: Claire Lush @.>
Sent: Tuesday, November 7, 2023 12:21 PM
To: jncc/vsas-app-development @.>
Cc: Emma Wilson @.>; Mention @.>
Subject: Re: [jncc/vsas-app-development] Initial QField Configuration (Issue #34)
CAUTION: Please remember your Cyber Security training. This email originated from outside the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
@Emmawilsonjncchttps://github.com/Emmawilsonjncc The ICES binocular vocab (http://vocab.ices.dk/?ref=1719) does not include "Binoculars used for ID only". Does this need adding? If not which of the values from the vocab is the default?

Reply to this email directly, view it on GitHubhttps://github.com/jncc/vsas-app-development/issues/34#issuecomment-1798395708, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDPC6J2GZLKVD5JIT7RKXQTYDIRT5AVCNFSM6AAAAAA7A6PFE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM4TKNZQHA.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.comhttp://www.symanteccloud.com/

For information on how we handle personal data please see our Privacy Notice at https://jncc.gov.uk/privacy
This email and any attachments is intended for the named recipient(s) only. If you are not the named recipient then any copying, distribution, storage or other use of the information contained in them is strictly prohibited. In this case, please inform the sender straight away then destroy the email and any linked files.
JNCC may have to make this message, and any reply to it, public if asked to under the Freedom of Information Act, data protection legislation or for litigation. If you have a Freedom of Information/Environmental Information request, please refer to our website page.
This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com. However we can accept no responsibility once it has left our systems. The recipient should check any attachment before opening it.
JNCC Support Co. registered in England and Wales, Company No. 05380206. Registered Office: Quay House, 2 East Station Road, Fletton Quays, Peterborough, PE2 8YY https://jncc.gov.uk/

@Emmawilsonjncc the spreadsheet doesn't include any mention of different fields/LUTs for non-birds. Are these still required?

Non-birds are still required and should be found in the same way that bird species are found i.e. using the observation form, selecting the first drop down for species group and then species from the second drop down. For non-birds, this will look something like drop down 1 = cetaceans, drop down 2 = porpoise. I am currently putting together a list of species groups and species for each drop down and will get this over to you soon!
From: Claire Lush @.>
Sent: Friday, November 10, 2023 11:52 AM
To: jncc/vsas-app-development @.>
Cc: Emma Wilson @.>; Mention @.>
Subject: Re: [jncc/vsas-app-development] Initial QField Configuration (Issue #34)
CAUTION: Please remember your Cyber Security training. This email originated from outside the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
@Emmawilsonjncchttps://github.com/Emmawilsonjncc the spreadsheet doesn't include any mention of different fields/LUTs for non-birds. Are these still required?

Reply to this email directly, view it on GitHubhttps://github.com/jncc/vsas-app-development/issues/34#issuecomment-1805602236, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDPC6J6VVYKPCGPZ7OGSM5TYDYIM7AVCNFSM6AAAAAA7A6PFE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBVGYYDEMRTGY.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.comhttp://www.symanteccloud.com/

For information on how we handle personal data please see our Privacy Notice at https://jncc.gov.uk/privacy
This email and any attachments is intended for the named recipient(s) only. If you are not the named recipient then any copying, distribution, storage or other use of the information contained in them is strictly prohibited. In this case, please inform the sender straight away then destroy the email and any linked files.
JNCC may have to make this message, and any reply to it, public if asked to under the Freedom of Information Act, data protection legislation or for litigation. If you have a Freedom of Information/Environmental Information request, please refer to our website page.
This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com. However we can accept no responsibility once it has left our systems. The recipient should check any attachment before opening it.
JNCC Support Co. registered in England and Wales, Company No. 05380206. Registered Office: Quay House, 2 East Station Road, Fletton Quays, Peterborough, PE2 8YY https://jncc.gov.uk/


return 400 when encounter invalid encrypted key

https://github.com/projectkudu/kudu/blob/6152ca9c6d5d40a0dca4b0f450b8659805457c75/Kudu.Services/Filters/FunctionExceptionFilterAttribute.cs#L29-L32
will do the conversion of 400 --> 500
this should address #2555

TODO need to verify that encryption key and decryption key used in test is consistent, ie: set environment variable AzureWebEncryptionKey

@watashiSHUN what's the status of this PR?

waiting for approval

rebased https://github.com/projectkudu/kudu/commit/94fccd0c4d4607fe5c1076b9aef0f1d588a27061


Join together outputs from multiple labeling jobs

Hi, I really liked this sample and it helped me an awfully lot. I am quite a newbaby to AWS so I would like to have one question regarding section of Join together outputs from multiple labeling. I have multiple labeling jobs and I would like to join labeled data from this jobs into one bigger dataset, but the data are stored in different s3 buckets. Do you think, it is possible, to join even these datasets?
Because when I try it, I always get errors while training, so I am not sure, if it is even possible.
Thank you very much for you response, I would greatly appreciate it.

Why don't you just copy multiple outputs or manifests in different s3 buckets into one big manifest file in one s3 bucket and pass it to that step?

Why don't you just copy multiple outputs or manifests in different s3 buckets into one big manifest file in one s3 bucket and pass it to that step?

Because when I tried to do it this simple way, I always got error during training.
In fact, the answer to this question already is in the notebook, sagemaker_client.describe_labeling_job(LabelingJobName=label_job_id)['LabelingJobOutput']['OutputDatasetS3Uri']
this function is commented and I was blind enough not to see it. Using this, I was able to merge my datasets.
But thank you very much for your answer, Raunak.
I will close the issue now.


Failed to connect raw kernel session: Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname

Environment data

VS Code version: 1.78.2
Jupyter Extension version (available under the Extensions sidebar): v2023.4.1011241018
Python Extension version (available under the Extensions sidebar): v2023.8.0
OS (Windows | Mac | Linux distro) and version: MacOS 13.0.1
Python and/or Anaconda version: 23.3.1
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): Conda
Jupyter server running: Local

Expected behaviour
Executing a cell within VSCode should not result in an error.
Actual behaviour
When attempting to execute a cell I receive the following error message:
Failed to connect raw kernel session: Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname

Steps to reproduce:

Create a new notebook
Run the created notebook using the VS Code extension

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

13:53:31.225 [info] Starting Kernel startUsingPythonInterpreter, .jvsc74a57bd008eadf134f1a785b62499d4dedb87e2ed67104e28a6ed43ea93d4902c042f2a6.~/Code/music/.conda/python.~/Code/music/.conda/python.-m#ipykernel_launcher  (Python Path: ~/Code/music/.conda/bin/python, Conda, 3.10.11) for '~/Desktop/minimal.ipynb' (disableUI=false)
13:53:31.228 [error] Kernel Launcher. launch, Class name = Kg, completed in 1ms, has a falsy return value, Arg 1: "~/Code/music/.conda/python.~/Code/music/.conda/python.-m#ipykernel_launcher", Arg 2: 60000, Arg 3: "~/Desktop/minimal.ipynb", Arg 4: "~/Desktop", Arg 5: "" Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
    at ~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:3100
    at ~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:7177
    at a (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:10108)
    at ~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:9560
    at ~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:2742
    at Server.o (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/351.node.js:1:1458)
    at Object.onceWrapper (node:events:628:26)
    at Server.emit (node:events:513:28)
    at emitErrorNT (node:net:1459:8)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  vslsStack: [
    CallSite {}, CallSite {},
    CallSite {}, CallSite {},
    CallSite {}, CallSite {},
    CallSite {}, CallSite {},
    CallSite {}, CallSite {}
  ]
}
13:53:31.229 [error] Failed to connect raw kernel session: Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
13:53:31.230 [info] Process Execution: ~/Code/music/.conda/bin/python -c "import ipykernel; print(ipykernel.__version__); print("5dc3a68c-e34e-4080-9c3e-2a532b2ccb4d"); print(ipykernel.__file__)"
13:53:31.231 [warn] Error occurred while trying to start the kernel, options.disableUI=false Error: Failed to start the Kernel '.conda (Python 3.10.11)'.
View Jupyter [log](command:jupyter.viewOutput) for further details. Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
    > at new dr (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/extension.node.js:2:1642280)
    > originalException = Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
13:53:31.231 [warn] Kernel Error, context = start Error: Failed to start the Kernel '.conda (Python 3.10.11)'.
View Jupyter [log](command:jupyter.viewOutput) for further details. Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
    > at new dr (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/extension.node.js:2:1642280)
    > originalException = Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
13:53:31.233 [info] Process Execution: ~/Code/music/.conda/bin/python -c "import ipykernel;print('6af208d0-cb9c-427f-b937-ff563e17efdf')"
13:53:31.343 [info] Dispose Kernel '~/Desktop/minimal.ipynb' associated with '~/Desktop/minimal.ipynb'
13:53:31.344 [error] Error in execution Error: Failed to start the Kernel '.conda (Python 3.10.11)'.
View Jupyter [log](command:jupyter.viewOutput) for further details. Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
    > at new dr (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/extension.node.js:2:1642280)
    > originalException = Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
13:53:31.344 [error] Error in execution (get message for cell) Error: Failed to start the Kernel '.conda (Python 3.10.11)'.
View Jupyter [log](command:jupyter.viewOutput) for further details. Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname
    > at new dr (~/.vscode/extensions/ms-toolsai.jupyter-2023.4.1011241018-darwin-arm64/out/extension.node.js:2:1642280)
    > originalException = Error: Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname

Provided host <IP_ADDRESS> could NOT be bound. Please provide a different host address or hostname

@kyledecot looks like you might have some anti-virus software or the like that is preventing some ports from being opened.
Please could you try launching Jupyter Notebook from the Conda environment ~/Code/music/.conda/python
Hopefully there will be some better logs. I.e. open a terminal outside VS Code, then launch Jupyter notebook from there and let me know what errors you get.
Ensure you activate the above conda env in the terminal, then sure you have Jupyter notebook installed into the above conda enviornment. and finally launch using python -m jupyter notebook

Closing this issue as its been over 4 weeks, since the information was requested.
We'll be happy to reopen the issue when the requested information has been provided.


[v2] - Interface hooks (optional)

Interface hooks (optional)
PostUp
PostDown
PreUp
PreDown
v2- i think Interface hooks don't run any type of shell

all commands are executed inside a BASH.
the execution uses: bash -ce <THE INTERFACE HOOK COMMAND>