0.73 fails to build on iOS with use_frameworks! :static due to yoga header path issue

Old Version
0.72.7
New Version
0.73.0
Description
As seems to happen with every new version, header paths are broken on iOS with use_frameworks! :static
pnpm install
pnpm expo start
eas build -p ios --profile development --local
fails to compile due to header paths issue
[RUN_FASTLANE] › Compiling .pnpm Pods/Yoga » PixelGrid.cpp
[RUN_FASTLANE]
❌  (node_modules/.pnpm/react-native@0.73.0_@babel+core@7.23.6_@babel+preset-env@7.23.6_react@18.2.0/node_modules/react-native/ReactCommon/yoga/yoga/algorithm/PixelGrid.cpp:10:10)

   8 | #include <yoga/Yoga.h>
   9 |
> 10 | #include <yoga/algorithm/PixelGrid.h>
     |          ^ 'yoga/algorithm/PixelGrid.h' file not found
  11 | #include <yoga/numeric/Comparison.h>
  12 |
  13 | namespace facebook::yoga {

Steps to reproduce
https://github.com/evelant/expo50upgrade/
git clone https://github.com/evelant/expo50upgrade/
cd expo50upgrade
pnpm install
pnpm expo start
eas build -p ios --profile development --local
Affected Platforms
Build - MacOS
Output of npx react-native info
System:
  OS: macOS 14.2
  CPU: (10) arm64 Apple M1 Pro
  Memory: 348.45 MB / 16.00 GB
  Shell:
    version: 0.85.0
    path: /etc/profiles/per-user/imagio/bin/nu
Binaries:
  Node:
    version: 20.8.0
    path: /etc/profiles/per-user/imagio/bin/node
  Yarn:
    version: 1.22.21
    path: /etc/profiles/per-user/imagio/bin/yarn
  npm:
    version: 10.1.0
    path: /etc/profiles/per-user/imagio/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.12.1
    path: /etc/profiles/per-user/imagio/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - watchOS 10.2
  Android SDK:
    API Levels:
      - "33"
    Build Tools:
      - 33.0.0
    Android NDK: Not Found
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 15.1/15C65
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: <IP_ADDRESS>
    path: /etc/profiles/per-user/imagio/bin/javac
  Ruby:
    version: 3.1.4
    path: /etc/profiles/per-user/imagio/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.0
    wanted: 0.73.0
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Stacktrace or Logs
[RUN_FASTLANE] › Compiling .pnpm Pods/Yoga » PixelGrid.cpp
[RUN_FASTLANE]
❌  (node_modules/.pnpm/react-native@0.73.0_@babel+core@7.23.6_@babel+preset-env@7.23.6_react@18.2.0/node_modules/react-native/ReactCommon/yoga/yoga/algorithm/PixelGrid.cpp:10:10)

   8 | #include <yoga/Yoga.h>
   9 |
> 10 | #include <yoga/algorithm/PixelGrid.h>
     |          ^ 'yoga/algorithm/PixelGrid.h' file not found
  11 | #include <yoga/numeric/Comparison.h>
  12 |
  13 | namespace facebook::yoga {

Reproducer
https://github.com/evelant/expo50upgrade/
Screenshots and Videos
N/A

I can't run successfully iOS build even with Readme.md

Install npm deps, gems, cocoapods.
npm start

Xcode 15.1, Sonoma 14.2

npm run ios ( in second terminal window ) failed:

❯ npm run ios

<EMAIL_ADDRESS>ios
react-native run-ios

info A dev server is already running for this project on port 8081.
info Found Xcode workspace "RnTemplate.xcworkspace"
info Found booted iPhone SE (3rd generation)
info Building (using "xcodebuild -workspace RnTemplate.xcworkspace -configuration Debug -scheme RnTemplate -destination id=C26067CA-B437-43C3-BA26-072C31EA0211")
▸ Running script '[CP] Copy XCFrameworks'
▸ Running script '[CP] Copy XCFrameworks'
▸ Running script '[CP] Copy XCFrameworks'
Run script build phase '[CP-User] [Hermes] Replace Hermes for the right configuration, if needed' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'hermes-engine' from project 'Pods')
▸ Running script '[CP-User] [Hermes] Replace Hermes for the right configuration, if needed'
▸ Running script '[CP] Copy XCFrameworks'
▸ Processing ResourceBundle-RCTI18nStrings-React-Core-Info.plist
▸ Running script '[CP-User] Generate Specs'
Run script build phase 'Bundle React Native code and images' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'RnTemplate' from project 'RnTemplate')
info 💡 Tip: Make sure that you have set up your development environment correctly, by running npx react-native doctor. To read more about doctor command visit: https://github.com/react-native-community/cli/blob/main/packages/cli-doctor/README.md#doctor
error Failed to build iOS project. "xcodebuild" exited with error code '65'. To debug build logs further, consider building your app with Xcode.app, by opening 'RnTemplate.xcworkspace'.

@iron-leo I think that's a totally separate issue. Did you run react-native start before trying to build? It no longer gets started automatically and IIRC that's the (not super helpful) error message it gives.

cc @cipolleschi

Hi @evelant thanks for the report.
There are at least two things that concern me:

pnpm is not officially supported yet, we know that there are issues with that setup
you are using expo
Dynamic frameworks jobs passed on 0.73. So we are confident that static frameworks will works as well, because dyn frameworks have stricter requirements.

npx react-native@latest init StaticFrameworks --version latest --skip-install
cd StaticFrameworks
yarn install
cd ios
bundle install
USE_FRAMEWORKS=static NO_FLIPPER=1 bundle exec pod install
open StaticFrameworks.xcworkspace

and then ⌘+B works properly.

@cipolleschi I think I bumped into the same issue https://github.com/react-native-webview/react-native-webview/issues/3263 when building a project using react-native-webview with iOS / RN v0.73 / New Arch. Using Yarn, no expo.

And the project I was building is this one: https://github.com/birdofpreyru/react-native-static-server/tree/master, more specifically its Example App: https://github.com/birdofpreyru/react-native-static-server/tree/master/example

@cipolleschi This same issue has happened in previous releases. I had a PR for 0.72 that fixed it then. It seems like it just keeps creeping back in due to the way cocoapods handles symlinks when given a relative path in a podfile. See the older PR here https://github.com/facebook/react-native/pull/38158 and an explanation of the problem here https://github.com/facebook/react-native/issues/38140#issuecomment-1615082380
It would be great if pnpm could be added to the automated tests. It should require zero extra setup. Just substitute yarn or npm for pnpm, that's all.

yeah, i remember. But we had to revert those changes because they were failing on other test cases, now I don't remember the specifics, unfortunately, as some weeks has passed. :(

I've observed this with lottie-react-native. I made a simple repro: https://github.com/heath-clink/rn73-lottie-repro

For folks maintaining webview and lottie, does the problem go away if you add install_modules_dependenciesas referenved here make the issue go away? https://reactnative.dev/docs/0.71/the-new-architecture/pillars-fabric-components#ios-create-the-podspec-file

https://github.com/facebook/react-native/commit/33ebb5d6365c3dd5d5214afc42c373d265280e27 made changes to Yoga header structure with new architecture. There is a lot of manual finagling of header search paths happening right now.

I think there are different problems:

The problem highlighted by @evelant is due to pnpm and the relative patch that are specified in the podspecs, which stops working correctly with some pnpm setups
The problem highlighted by react-native-webview and lottie should be solved using install_modules_dependenciesas as @NickGerleman suggested. I'll fix those on Monday as I fixed several libraries already. Notice that they will require a new release of the two libs, anyway.

For webview, there is already a PR pending with the fixes: https://github.com/react-native-webview/react-native-webview/pull/3231/files

I created the PR for Lottie as well: https://github.com/lottie-react-native/lottie-react-native/pull/1139

I too am experiencing this with nx as my monorepo setup.
Started as soon as I use_frameworks! :linkage => :static (required by firebase).

Monorepo setup are not officially supported, unfortunately.
We haven't figured out a proper way to handle them. In monorepo setup the problems are likely to be the various relative path we have in the podspecs. In the Yoga.podspec we have a few of them.
Monorepo setups put those files in different paths w.r.t. the standard setup, and the podspecs layout is not handling that case.

I'll certainly have to read more into static frameworks to understand how this breaks monorepos vs it usually working just fine without.

I'm creating a "SDK", using cocoapods lib create.
I'm having this issue:

Here is my podfile:
`platform :ios, '13.4'
source 'https://github.com/jveronezi/sdk-specs.git'
source 'https://github.com/CocoaPods/Specs.git'
use_frameworks!
target 'TestingSDK' do
pod 'SdkPod', '0.1.3'
end
This is my Yoga.podspec.json{
"name": "Yoga",
"version": "1.14.1",
"license": {
"type": "MIT"
},
"homepage": "https://yogalayout.com",
"documentation_url": "https://yogalayout.com/docs/",
"summary": "Yoga is a cross-platform layout engine which implements Flexbox.",
"description": "Yoga is a cross-platform layout engine enabling maximum collaboration within your team by implementing an API many designers are familiar with, and opening it up to developers across different platforms.",
"authors": "Facebook",
"source": {
"git": "https://github.com/facebook/react-native.git",
"tag": "v0.73.1"
},
"module_name": "Yoga",
"header_dir": "Yoga",
"requires_arc": false,
"pod_target_xcconfig": {
"DEFINES_MODULE": "YES"
},
"compiler_flags": [
"-fno-omit-frame-pointer",
"-fexceptions",
"-Wall",
"-Werror",
"-std=c++17",
"-fPIC"
],
"platforms": {
"ios": "13.4"
},
"source_files": "packages/react-native/ReactCommon/yoga/yoga//*.{cpp,h}",
"header_mappings_dir": "yoga",
"public_header_files": "ReactCommon/yoga/yoga/{Yoga,YGEnums,YGMacros,YGNode,YGStyle,YGValue}.h",
"private_header_files": [
"packages/react-native/ReactCommon/yoga/yoga/Yoga-internal.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/Align.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/Baseline.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/BoundAxis.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/Cache.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/CalculateLayout.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/FlexDirection.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/FlexLine.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/PixelGrid.h",
"packages/react-native/ReactCommon/yoga/yoga/algorithm/ResolveValue.h",
"packages/react-native/ReactCommon/yoga/yoga/bits/BitCast.h",
"packages/react-native/ReactCommon/yoga/yoga/bits/NumericBitfield.h",
"packages/react-native/ReactCommon/yoga/yoga/config/Config.h",
"packages/react-native/ReactCommon/yoga/yoga/debug/AssertFatal.h",
"packages/react-native/ReactCommon/yoga/yoga/debug/Log.h",
"packages/react-native/ReactCommon/yoga/yoga/debug/NodeToString.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Align.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Dimension.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Direction.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Display.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Edge.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Errata.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/ExperimentalFeature.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/FlexDirection.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Gutter.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Justify.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/LogLevel.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/MeasureMode.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/NodeType.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Overflow.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/PositionType.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/PrintOptions.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Unit.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/Wrap.h",
"packages/react-native/ReactCommon/yoga/yoga/enums/YogaEnums.h",
"packages/react-native/ReactCommon/yoga/yoga/event/event.h",
"packages/react-native/ReactCommon/yoga/yoga/node/CachedMeasurement.h",
"packages/react-native/ReactCommon/yoga/yoga/node/LayoutResults.h",
"packages/react-native/ReactCommon/yoga/yoga/node/Node.h",
"packages/react-native/ReactCommon/yoga/yoga/numeric/Comparison.h",
"packages/react-native/ReactCommon/yoga/yoga/numeric/FloatOptional.h",
"packages/react-native/ReactCommon/yoga/yoga/style/CompactValue.h",
"packages/react-native/ReactCommon/yoga/yoga/style/Style.h"
],
"preserve_paths": ["ReactCommon/yoga/yoga//*.h"]
}
`

You should not use cocoapods lib create to create a library for react-native.
Cocoapods is the tool we use but the base use case is to create a lib for a standard iOS project.
For React Native, there is much more running under the hoods. The tool you should use to create a library compatible with React Native is Bob that will properly setup the podspec and the whole folder structure for you.
It will also create an Example folder with a React Native sample app that you can use to test your library.

Monorepo setup are not officially supported, unfortunately.
We haven't figured out a proper way to handle them. In monorepo setup the problems are likely to be the various relative path we have in the podspecs. In the Yoga.podspec we have a few of them.
Monorepo setups put those files in different paths w.r.t. the standard setup, and the podspecs layout is not handling that case.

Any way we can get around this? why use_frameworks! :linkage => :static is causing this to monorepo setup? as I understand from the thread it works without it?

The problem is that use_frameworks changes how the files are arranged in the disk after pod install run.
Frameworks must follow a very specific structure:
FrameworkName
'-> Headers
    '-> headerA.h
    '-> headerB.h
'-> ImplementationA.m
'-> PrivateHeaderC.h

While static libraries doesn't.
On top of that, Monorepos usually moves the whole frameworks in a different location and uses symlinks to connect the expected position on disk to the monorepo location.
Those links get broken in our current setup. The specific details of what get broken depend on the monorepo that is used, but what I saw happening is that, with use frameworks, not all the symlink are set up correctly and that broke it.

Same issue here.
I see it's mentioned that monorepos aren't officially supported, but also I saw this comment which says symlinks are stable in 0.73. What other challenges remain for monorepos? I sort of expected the support for symlinks to remedy this problem.

Getting this issue in an Nx monorepo
Related: https://github.com/nrwl/nx/issues/20115

@Slapbox symlink is stable for Metro, but not for the whole framework. My colleague that worked on simlinks for metro is now tackling monorepo scenarios, so, hopeful, we are going to have them working soon.

@cipolleschi my app fails to be archived for macOS (Catalyst) release with the seemingly similar error:

at the same time it builds and works fine if I just build it in release or debug mode to run locally on macOS, and it also works fine for iOS (both local builds & archiving for Apple.Store release). I am a bit lost in this thread, thus maybe you can hint me please, how to fix / temporary workaround it? I am not using expo; I am using npm; and I have use_frameworks! :linkage => :static in my podspec.

I solved my issue by going into the podspec.json and fixing the paths

I solved my issue by going into the podspec.json and fixing the paths

Can you please share the changes here?

I solved my issue by going into the podspec.json and fixing the paths

@joaoveronezi  Can you please share the changes here?

@Johan-dutoit sure. But I had to make a lot of changes.
The thing is, generally this error occurs when the XCODE can't find the header path or something like that.
If you are creating just a React native app, without making any changes, and using it along with node_modules and all the support files, those issues probably won't appear. However, if you are creating a Bridge, like me, that only uses .podspecs.json to install the pods, you need to make some changes.
The first thing I did was change the Yoga version from 1.14.0 to 1.14.1. The second one was adjusting all the paths on my .podspec.json:
{   "name": "Yoga",   "version": "1.14.1",   "license": {     "type": "MIT"   },   "homepage": "https://yogalayout.com",   "documentation_url": "https://yogalayout.com/docs/",   "summary": "Yoga is a cross-platform layout engine which implements Flexbox.",   "description": "Yoga is a cross-platform layout engine enabling maximum collaboration within your team by implementing an API many designers are familiar with, and opening it up to developers across different platforms.",   "authors": "Facebook",   "source": {     "git": "https://github.com/facebook/react-native.git",     "tag": "v0.73.1"   },   "module_name": "Yoga",   "header_dir": "Yoga",   "requires_arc": false,   "pod_target_xcconfig": {     "DEFINES_MODULE": "YES"   },   "compiler_flags": [     "-fno-omit-frame-pointer",     "-fexceptions",     "-Wall",     "-Werror",     "-std=c++20",     "-fPIC"   ],   "platforms": {     "ios": "13.4"   },   "source_files": "packages/react-native/ReactCommon/yoga/yoga/**/*.{cpp,h}",   "header_mappings_dir": "packages/react-native/ReactCommon/yoga/yoga",   "public_header_files": "packages/react-native/ReactCommon/yoga/yoga/{Yoga,YGEnums,YGMacros,YGValue}.h",   "private_header_files": [     "packages/react-native/ReactCommon/yoga/yoga/Yoga-internal.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/Align.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/Baseline.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/BoundAxis.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/Cache.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/CalculateLayout.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/FlexDirection.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/FlexLine.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/PixelGrid.h",     "packages/react-native/ReactCommon/yoga/yoga/algorithm/ResolveValue.h",     "packages/react-native/ReactCommon/yoga/yoga/bits/BitCast.h",     "packages/react-native/ReactCommon/yoga/yoga/bits/NumericBitfield.h",     "packages/react-native/ReactCommon/yoga/yoga/config/Config.h",     "packages/react-native/ReactCommon/yoga/yoga/debug/AssertFatal.h",     "packages/react-native/ReactCommon/yoga/yoga/debug/Log.h",     "packages/react-native/ReactCommon/yoga/yoga/debug/NodeToString.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Align.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Dimension.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Direction.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Display.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Edge.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Errata.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/ExperimentalFeature.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/FlexDirection.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Gutter.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Justify.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/LogLevel.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/MeasureMode.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/NodeType.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Overflow.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/PositionType.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/PrintOptions.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Unit.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/Wrap.h",     "packages/react-native/ReactCommon/yoga/yoga/enums/YogaEnums.h",     "packages/react-native/ReactCommon/yoga/yoga/event/event.h",     "packages/react-native/ReactCommon/yoga/yoga/node/CachedMeasurement.h",     "packages/react-native/ReactCommon/yoga/yoga/node/LayoutResults.h",     "packages/react-native/ReactCommon/yoga/yoga/node/Node.h",     "packages/react-native/ReactCommon/yoga/yoga/numeric/Comparison.h",     "packages/react-native/ReactCommon/yoga/yoga/numeric/FloatOptional.h",     "packages/react-native/ReactCommon/yoga/yoga/style/CompactValue.h",     "packages/react-native/ReactCommon/yoga/yoga/style/Style.h"   ],   "preserve_paths": ["packages/react-native/ReactCommon/yoga/yoga/**/*.h"] }
If you noticed, I added "packages/react-native" to every path we have, because that's where the files are (in react-native github)

@joaoveronezi I might be missing something, but for me changing the .podspec.json makes no difference — if I just do it, the Archive still fails, if I run pod update after doing it — the file is reset to its initial form. I only could pass the Archive if I go around all Yoga source and replace all include paths by relative ones... which works, but is very tedious.

Banged my head against this for a couple of days - it seems that if I update the :path => to point to the monorepo root folder everything builds fine. For reference this is in an NX monorepo using React Native 0.73.2
  use_react_native!(
    :path => "../../#{config[:reactNativePath]}"
.... remaining settings ....
)

Not had chance to review the full functionality of our app yet, but the build is successful and at first glance everything seems to work.

For me, it worked when I tried with pod version 1.14.3. The issue is with Subpath of the node for pod In symlinking
I dont know but somehow with this version the linking of private headers points to $(PRIVATE_HEADERS_FOLDER_PATH)/node.
Previously i was using pod 1.15.0 and headers were pointing to the linkage destinations.

Finally I managed this issue.
In GemFile, modify cocoapods gem like following:
gem 'cocoapods', git: 'https://github.com/zep-us/CocoaPods', branch: 'header-mappings-dir-symlink-fix'

I patched cocoapods to make it work correctly when header_mappings_dir is set to symlinked dir.
Then run bundle install, and then run bundle exec pod install in ios directory. Done!

@wjaykim tried, does not work for me (I only have the problem when archiving for macOS/Catalyst, on old Intel-based Mac).

We recently committed some changes that should fix archiving of Yoga, here. Could you try to add these changes to node_modules/react_native/ReactCommon/yoga/yoga.podspec and see if it works?
The commit has not been released in any version as of today, If that works for you, we might want to cherry pick it in all the supported versions.

@cipolleschi tested, it solves the problem for me 🎉 please, merge it into next releases 🙏

Created PR for the release crew and the issue for the cherry pick. 0.74 should pick the fix in the next RC happening this Monday.
I don't have a timeline for 0.73.

Hey, I still have this error. I tried to build the project using react versions 0.73, 0.74.0 and 0.74.1 and got the same error. 'yoga/Yoga.h' file not found. Please, help me.

@Aleksandriukas what operation are you trying to do? Building? Archiving?
For which platform? iOS, Catalyst?
What's your podfile? How are you installing pods?
Which version of Xcode are you using?

@cipolleschi we're on 0.74.2 and still facing this very difficult issue. Was the change every cherry-picked? Did it simply not have the desired effect?

I've been trying all day, but no workarounds seem to remedy this. I briefly had it working on 0.72.6, but not at all on 0.74.x.

Unfortunately the changes mentioned by @cipolleschi on April 3rd (https://github.com/facebook/react-native/commit/767330f21885e668bc0d9b5b3063113d0446bcbc) are already integrated in the version we're using, but the problem persists:
/Users/expo/workingdir/build/node_modules/react-native/React/Base/RCTConvert.h:19:9: fatal error: 'yoga/Yoga.h' file not found
#import <yoga/Yoga.h>
        ^~~~~~~~~~~~~
/Users/expo/workingdir/build/node_modules/react-native/React/Base/RCTConvert.h:19:9: note: did not find header 'Yoga.h' in framework 'yoga' (loaded from '/Users/expo/workingdir/build/packages/mobile/ios/build/Build/Products/Debug-iphonesimulator/Yoga')
1 error generated.

@cnorman1977 can you share where exactly you made that change?

@cipolleschi can you offer any advice or insights? Or is there anything else I can do to help get this resolved? We're on 0.74.2 and this is essentially a showstopper since we can't build.

Can anyone offer any advice on this? Even @cnorman1977's approach which everyone seems to agree worked for 0.73.x does not resolve this in 0.74.2 - and my understanding is that it shouldn't even be necessary since #42847 was merged.

Ogh… the patch solved the issue for me, and seemingly for everyone else but you; hence it reads like you do something wrong in your code.

Thanks for your reply @birdofpreyru. Unfortunately I use Expo in a managed workflow so there's not much in terms of what I personally could be doing wrong, but perhaps something upstream from us.
Is there anything in your mind that Expo might need to do to resolve this? There's an unresolved issue there with several people struggling with it: https://github.com/expo/expo/issues/25942

I never used Expo, and I am very disappointed it is the officially recommended way to use RN since 0.74 🤷♂ I’m glad to learn it doesn’t work smooth, unlike the barebone RN 😁

Not a good look to gloat while someone's facing a problem.

I tried removing the patch from #42847 and doing so restores the originally reported issue:
[RUN_FASTLANE] › Compiling react-native Pods/Yoga » event.cpp
[RUN_FASTLANE]
❌  (../../node_modules/react-native/ReactCommon/yoga/yoga/YGValue.cpp:9:10)

   7 |
   8 | #include <yoga/YGValue.h>
>  9 | #include <yoga/numeric/Comparison.h>
     |          ^ 'yoga/numeric/Comparison.h' file not found
  10 |
  11 | using namespace facebook;
  12 | using namespace facebook::yoga;

[RUN_FASTLANE] › Compiling react-native Pods/Yoga » YGPixelGrid.cpp
[RUN_FASTLANE]
❌  (../../node_modules/react-native/ReactCommon/yoga/yoga/YGPixelGrid.cpp:10:10)

   8 | #include <yoga/Yoga.h>
   9 |
> 10 | #include <yoga/algorithm/PixelGrid.h>
     |          ^ 'yoga/algorithm/PixelGrid.h' file not found
  11 |
  12 | using namespace facebook;
  13 | using namespace facebook::yoga;

But are we sure it really resolves 'yoga/Yoga.h' file not found @cnorman1977?
There are quite a few thumbs up on the comment here from long after the patch was theoretically applied, as well as #44340 which was closed as a duplicate - although I'm not sure that it really is.
It seems like for some people, the patch just got them one step closer to building, but exposed a new issue which is not addressed?

Friendly bump. I do not believe this issue has truly been resolved for the reasons stated in the comment immediately prior.

@Nantris - I am facing the same issue. I am upgrading a project from Expo 49 (RN 0.72.x) to Expo 51 (RN 0.74.2). The patch was able to clear some errors related to header path mappings to Yoga from other RN podspecs, and progress the build further. However, I also believe there are additional errors to do with locating the Yoga files during the linking phase of the iOS build.
It is not immediately clear to me at the moment what the issue is - but it is clear that the patch seems to fix header path mappings from packages inside the projects node_modules directory. The new error that I am seeing indicates that it is not able to find the Yoga file from the Build/Products directory as you are seeing in your above comment here.
VSCode throws this error during linking:
__
While Xcode throws this error for the same build:
__
I will be actively working on this for the next few weeks, and will keep you updated with any new discoveries.

Thanks @cipolleschi  - I'm going to create a minimal reproducible example to find out exactly where this issue is coming from. My understanding is that Expo is now working directly with the RN team for their releases to ensure compatibility between RN versions and Expo SDK's. I will confirm that Expo 51 works out of the box with RN 0.74.
I'm using pnpm as my package manager and also understand that it is not fully supported by react-native since it stores its packages in a separate location to alternatives like yarn and npm. I found a patch for Cocoapods which addresses this issue for RN > 0.73 but I'm aware that there could still be additional issues around this.
Since other people might run into this issue using any combination of RN with Expo + pnpm, npm, yarn etc - and since the discussion is already started about this issue on this thread, I am inclined to post my findings here (for the next guy). However, I will also be active on Expo's repo for any findings directly related to that.

@caustin24345 I had thought there was already an issue for this, but perhaps it was only a related issue. Please do share here when you create an issue on the Expo tracker and I'll be sure to join you there.

@caustin24345 I had thought there was already an issue for this, but perhaps it was only a related issue. Please do share here when you create an issue on the Expo tracker and I'll be sure to join you there.
Fwiw we're using Yarn and our error is identical to yours, so I don't think it's pnpm that's causing any problem for you. I tried Yarn 1.21 and Yarn 3.x and the error is identical with each.

Thank you for the info @cipolleschi, it is much appreciated.
To update you - I created a new Expo 51, RN 0.74 project using pnpm as the dependency manager and was able to build and run the project almost immediately. I slowly transferred packages and build configs across from my existing project to see what was causing the build issue that we have discussed. I was not able to reproduce it after replicating the package.json, and app.json - however, I was able to replicate it after moving to a monorepo structure and using nx to manage dependency caching. My hunch is that there is some confusion from the monorepo project as to which packages to reference when linking iOS frameworks i.e the packages in the node_modules directory at the project level, or the packages in the nx cached node_modules/.pnpm directory at the monorepo root.
With that being said, it is clear to me that this is NOT a react native, Expo or pnpm specific build issue and very likely related to caching and project infrastructure. I'm happy to move this conversation elsewhere now that I understand that it is not related to the react native package itself. I am however wondering if you are using similar tools or structure in your application @Nantris?

@caustin24345 I don't use pnpm anymore but when I did I ran into issues like this frequently (which is why I opened it originally). They generally fell within a couple categories of problems:

Part of the react-native build (usually a 3rd party library with native code) uses a hard coded path instead of using require.resolve( to find a path. Usually a relative path like ../../node_modules/something/or/other so it fails if dependencies are hoisted to root of a monorepo
React-native or another library has a "phantom dependency". That is it has a bug where it depends upon a package without declaring it as a dep or peer. Pnpm does the correct thing and doesn't make undeclared dependencies available so the dep isn't available and the build fails. It only happens to work on npm/yarn because they use a flat node_modules that allows you to resolve packages you don't actually declare a dependency on, you just get lucky that some transitive dependency installed it.
One or another tool doesn't play well with symlinks, usually metro or rubygems/cocoapods. IIRC symlinks like pnpm uses can cause cocoapods to copy headers to the wrong destination folder. I think I worked around that a few times by patching podfiles to resolve absolute paths to header dirs instead of using relative paths that broke with symlinks. If you look through the ios build outputs for headers you'll probably see them nested in really deep incorrect paths because cocoapods doesn't do well with symlinks.
Related to 3, sometimes xcode's behavior changes between releases frustratingly breaking workarounds for 3

I hope that summary is useful! Like I said however, I don't use pnpm anymore, I've been using bun without problems because it replicates the (bug prone and IMO incorrect) behavior of npm/yarn.

Monorepo setup are not officially supported, unfortunately. We haven't figured out a proper way to handle them. In monorepo setup the problems are likely to be the various relative path we have in the podspecs. In the Yoga.podspec we have a few of them.
Monorepo setups put those files in different paths w.r.t. the standard setup, and the podspecs layout is not handling that case.

@cipolleschi I know it's difficult due to JS tooling being the wild west but isn't it a little silly that react-native itself is a monorepo yet monorepo setups are not "officially" supported? I wonder if we can figure out what the real root cause of these repeated issues is and get it fixed. It seems to me it's primarily bad symlink behavior in cocoapods/rubygems. Might it be possible to get that fixed upstream so this whole class of problems could go away?

@caustin24345 and @evelant, thank you so much for your investigations and for sharing your findings. Those are extremely valuable and we really appreciate them.

I know it's difficult due to JS tooling being the wild west but isn't it a little silly that react-native itself is a monorepo yet monorepo setups are not "officially" supported? I wonder if we can figure out what the real root cause of these repeated issues is and get it fixed. It seems to me it's primarily bad symlink behavior in cocoapods/rubygems. Might it be possible to get that fixed upstream so this whole class of problems could go away?

I completely agree with you and I share the same frustrations and perplexities.
It is completely doable to upstream such changes if we find the right root cause.
@robhogan was working on monorepo support some month ago, but now our internal priorities changed a bit and I'm pretty sure we won't have capacity to work on  these topics in the very short term.
If there is a volunteer in the community that want to invest time in this, we are more than happy to support and make sure those changes land, but we don't have resources to work on this now. I'm hopeful that in six months or so, the situation might change a little.

I am however wondering if you are using similar tools or structure in your application @Nantris?

Yes we use an nx monorepo but I do not believe caching plays any role in this issue. I don't think it's correct to say this isn't a React Native or Expo issue, because in my view it has to be one of those, but for the fact React Native inexplicably fails to officially support monorepos in 2024.
I really wish we could get proper support for monorepo. When I started with React Native in 2018, it seemed right around the corner. Literally tens of thousands of developer hours end up wasted on this sort of stuff every year - including their own developers' time.
It worked with just a slightly older version of React Native and Expo. To me, that screams that it's a React Native or Expo problem.

One or another tool doesn't play well with symlinks, usually metro or rubygems/cocoapods. IIRC symlinks like pnpm uses can cause cocoapods to copy headers to the wrong destination folder. I think I worked around that a few times by patching podfiles to resolve absolute paths to header dirs instead of using relative paths that broke with symlinks.

Indeed, in React Native 0.72 making these path changes as a patch resolved all of our issues, but now with nothing having changed but React Native and Expo, it fails to work either with or without the patch. So it's got to be React Native, no?
-    s.header_mappings_dir     = './'
+    s.header_mappings_dir     = File.absolute_path('./')

I feel very confident this is not an nx caching issue, but if you want to investigate that, according to ChatGPT, this config in your nx.json should be a good template to fully disable caching. I haven't verified it myself, but if you want to give it a try, ensure it disables caching, and try a build, that would be a valuable troubleshooting step to prove or disprove your theory.

Update your nx.json to the below contents (update for your project - see docs: https://nx.dev/concepts/how-caching-works)
Run pnpm nx reset to clear existing cache

{
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx/tasks-runners/default",
      "options": {
        "cacheableOperations": []
      }
    }
  },
  "targetDefaults": {
    "*": {
      "inputs": ["default"],
      "outputs": ["{workspaceRoot}/dist/{projectName}"]
    }
  }
}

Using nrwl/nx and https://github.com/facebook/react-native/commit/767330f21885e668bc0d9b5b3063113d0446bcbc solved the problem

Thanks for sharing @dieguezz! Are you saying you used patch-package to backport that change to 0.73.x?

Exactly @Nantris

Thank you so much for sharing @dieguezz! This issue has been plaguing us and I'm excited to try your approach.
Would you mind sharing your React Native version? I noticed sometimes even patch-level version differences affect these workarounds.

So finally i needed to upgrade react native so i had to find a different workaround. What i did is remove use_frameworks!  (which removed the file not found errors) except for the case contemplated in
linkage = ENV['USE_FRAMEWORKS']
if linkage != nil
  Pod::UI.puts "Configuring Pod with #{linkage}ally linked Frameworks".green
  use_frameworks! :linkage => linkage.to_sym
end

And then add :modular_headers for packages that need it like:
  pod 'GoogleUtilities', :modular_headers => true
  pod 'FirebaseCore', :modular_headers => true
  pod 'nanopb', :modular_headers => true
  pod 'FirebaseInstallations', :modular_headers => true
  pod 'GoogleDataTransport', :modular_headers => true
  pod 'FirebaseCoreExtension', :modular_headers => true

@Nantris  let me know if this works for you

Thanks very much for sharing @dieguezz!
Invertase super-strongly recommends you do not rely on modular_header - but I wonder, are you using use_frameworks AND modular_headers? I wonder if that might be an acceptable solution @mikehardy.
I think there was another approach in one of these many threads that I haven't had time to try but now I can't even find it :(
I'll certainly report back with my findings as soon as I get a chance to try this. There always seems to be some other fire to fight first. Thank you again!

@Nantris I am just using use_frameworks for the case i pasted, when linkage != nil. In my case it will be nil so yeah, i just removed them completely. My podfile looks like the upgrade helper one but with a pair of things we are using (widgets and quantummetric conf), so the only substantial difference is what i posted in my last comment

@dieguezz I think you're probably in the clear with this approach? I'm the furthest thing from an expert. I think modular_headers is okay as long as you're not using it instead of use_frameworks but I'm not sure how brittle this approach might be. I'm certainly looking forward to giving it a try!

We started having this exact same issue after adding firebase to a project, and the only thing that fixed it for us was @dieguezz 's modular headers fix for the affected packages. Thank you so much!
One thing that may or may not contribute to any ongoing investigation into the issue though; in our case it was odd because the mentioned build errors only happened on some of our devs machines, while for others everything was totally fine. After merging the podfile changes though our project is working for everybody on the team, so not really sure what happened there.


Vite dev server crashes when HttpClient receives non-200 code

Command
serve
Is this a regression?

[x] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
v17
Description
Basically, it's a duplicate of https://github.com/angular/angular-cli/issues/26192
But now it's here again with v19, zoneless and outputMode: 'server'.
Is this behaviour expected and not-an-issue on new setup?
Minimal Reproduction
ng serve
Exception or Error
No response
Your Environment
HttpErrorResponse
Anything else relevant?
No response

This is a known issue with zoneless, and it not limited to dev-servers.

In prod env, server will crash too? Is there any catch error mechanism that can be applied to not stop dev/prod app, but respond with 500 code?

Yes, in the production environment, the server will crash because zone.js is not intercepting and handling unhandled errors and rejections.
Since the error is "unhandled," the request's lifecycle will continue in this scenario. For a potential workaround, please refer to this link: https://github.com/angular/angular-cli/pull/28405

Moving to the FW repo as following the convo in https://github.com/angular/angular-cli/pull/28405#discussion_r1791871459 the FW should handle the errors.


query options

please add this script to support query, I know seed query is short lived, but it will be very helpful for multi accounts that are prone to bans due to new accounts for create session.

do u still need it

sorry i forgot

sure, it will helpful

added

tysm


Incorrect "Unused variable" error with map

When I run futhark -s on
fun main () : []i32 =
  let x = 0
  let xs = map (+ x) [1]
  in xs

it prints
Unused variable 'x'.

even though it is used.

This is with the newest futhark from git.

Yeah, the unused-variable stuff is a total hack.  There's also some false positives around.  I can fix it, but we might want to think about how to automatically test it eventually.


Handling deme colors

Might be nice to be able to specify colors for demes in the same way we specify their positions, with a dictionary mapping deme to color. Gives the user more control of colors rather than a color map, maybe?

There is now a colours parameter to both size_history() and tubes(). It can be a dictionary mapping deme ids to colours, or a single colour, or None.


Feature: Simulated Output Prototype

Enables "testing" of the UI without actually connecting a device via serial.
To eventually be extended to a "visualization" of the device.

closed by #14


Add TLS 1.2 breaking change

In reference to https://github.com/dotnet/dotnet-docker/issues/6039

Internal previews

📄 File
🔗 Preview link

docs/core/compatibility/8.0.md
Breaking changes in .NET 8

docs/core/compatibility/containers/8.0/default-ciphers-for-tls-changed.md
Debian 12 container images no longer support TLS 1.2

docs/core/compatibility/toc.yml
docs/core/compatibility/toc

@gewarren and I had a follow-up conversation. This approach isn't going to scale. There are too many OS-specific breaking changes and there seem to be more in recent years. We're going to handle them in a different way, using GH issues.


New version breaks custom json and old customization

The new version breaks as soon as I create my own custom json for Design.
It fails serializing the json file:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'data parameter is nil'
*** First throw call stack:
(
0   CoreFoundation                      0x03b3f5e4 __exceptionPreprocess + 180
1   libobjc.A.dylib                     0x038c28b6 objc_exception_throw + 44
2   CoreFoundation                      0x03b3f3bb +[NSException raise:format:] + 139
3   Foundation                          0x036099e2 +[NSJSONSerialization JSONObjectWithData:options:error:] + 67

I just got the Error on the newest version of my app. No custom design of my notifications. Seems a new problem in my app without changing something in TSMessages.


bufio.ReadByte an error may occur

What version of Go are you using (go version)?

go version go1.14 windows/amd64

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

func (b *Reader) ReadByte() (byte, error) {
b.lastRuneSize = -1
for b.r == b.w {
if b.err != nil {
return 0, b.readErr()
}
b.fill() // buffer is empty
}
c := b.buf[b.r]
b.r++
b.lastByte = int(c)
return c, nil
}
at last, if buf is empty，b.r++，will not return err， and b.r is larger than r.w now
What did you expect to see?
What did you see instead?

if we get to the b.r++, we know for sure that b.r != b.w.  So I think that what you describe can't happen.
If you still think this is a problem, please write a program that demonstrates the problem.  You should be able to use a custom io.Reader that returns the values that cause the error.

i see, thanks


Missing a sample file of creating sandboxes on multiple farms

There is file shows how to create sandboxes on single farm node after deployment.
However, it is unclear how to create sandboxes if multiple farm nodes are registered.

Sorry for replay this issue so late.
Please see PR https://github.com/openvswitch/ovn-scale-test/pull/17.
The basic idea is simple, and the key point is change 'farm' field' to the farm node on which you want to create sandboxes.
If you need to create a lot of sandboxes, and finish it ASAP, you can run rally-ovs commands on different console at same time.

Lei, thanks for your comment. Let me close this and have discussion in #17


[Feature Request] Colored IRC nick-names to be displayed in-game

Currently all the text is white (non-colorized), and in-game players might not notice if they aren't already actively chatting. So, it'd be nice to see colored IRC nicks in game (just the <name@IRC> part); or the whole message can be fully colored too.

it seems this was merged with commit "Add support for configurable coloring of IRC messages in-game" at   https://github.com/minetest-mods/irc/commit/b4fbccd64ac758ee698f4f741250e9b682903363 using PR #52 so should be closed

Oh yes, this needs to be closed. Sorry. @sofar?


Automatic documentation build

So right now, the "new" documentation is on a separate repository (proteus-doc), and the process to push documentation is not automatic at all. There are 3 ways to do it:

Manual: build the intended version of proteus; build doc locally to specific folder; add changed files, new files, and remove unused files; commit; push to gh-pages branch.
readthedocs: can automatically document Proteus, fully externally. Ideal, but would require an install of Proteus for it to work properly, and readthedocs build time limit is around 900s, and I don't think there is a way to point at an existing build (not 100% sure about that).
Travis: can automatically build doc and push it to gh-pages, but only when someone commits to specific branch (such as master).

The last 2 require that the documentation is ported back to the main repository, and there is a way to do this without loosing commit authorship. I think the Travis solution might be the best one where a full installation of Proteus can be used for sphinx. This will make it very easy for anyone to add a page to the documentation and have it built as soon as it is committed to master.
The only issue I can see with that technique is that Travis could potentially time out when committing to master while it didn't on a PR because now it would also need to build the documentation.
Should we go that route?
@cekees

I think once we get the kinks worked out of the conda package (https://github.com/erdc/proteus/pull/1037), then readthedocs may work:
https://docs.readthedocs.io/en/stable/guides/conda.html#activating-conda
Agree that travis is probably the most flexible approach.


Include floating-ui libary

for tooltips, date selectors and search boxes
this is not a final choice but seems to be just fine for our needs
https://floating-ui.com/

i installed this and tried to get it working but it doesnt seem to be customizable enough to work with either our layout or all the nested scrolls. I removed it again.


Repository out of date

I see https://www.npmjs.com/package/cordova-plugin-share on npm,  version 0.1.3... and it links here which is only 0.1.3.
What is different?

@markmarijnissen ?

Anything?

Last ping,  @markmarijnissen ?

I'm not maintaining this plugin anymore, as there is a much better plugin available. https://github.com/EddyVerbruggen/SocialSharing-PhoneGap-Plugin


TypeScript example for params file in Routing docs

Describe the problem
I am reading through the docs and trying to understand a demo SvelteKit app. I'm on the Routing page: https://kit.svelte.dev/docs/routing
It has this example for: src/params/integer.js
/** @type {import('@sveltejs/kit').ParamMatcher} */
export function match(param) {
  return /^\d+$/.test(param);
}

I'm trying to figure out how to create the .ts version of this file.
Describe the proposed solution
It would be nice if these was a code switcher here so you could toggle between JS Doc and TS examples.
Is this correct? src/params/integer.ts
import type { ParamMatcher } from '@sveltejs/kit';

export const match: ParamMatcher = (param) => {
	return /^\d+$/.test(param);
};

Alternatives considered
No response
Importance
nice to have
Additional Information
No response

Duplicate of https://github.com/sveltejs/kit/issues/4452


presentationStyle In Storyboard?

I don't see presentationStyle in storyboard, so I tried to subclass and set it in viewDidLoad, but then navigation menu was broken. Can this be set in storyboard?

class SidebarViewController: SideMenuNavigationController {

    override func viewDidLoad() {
        super.viewDidLoad()

        presentationStyle = .viewSlideOutMenuOut

    }

    /*
    // MARK: - Navigation

    // In a storyboard-based application, you will often want to do a little preparation before navigation
    override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
        // Get the new view controller using segue.destination.
        // Pass the selected object to the new view controller.
    }
    */

}

Please follow the README carefully. You cannot set presentationStyle in storyboard.
Related: https://github.com/jonkykong/SideMenu/issues/627


ci: add clang rdc compilation error workaround to multiexp kernel component ( PROOF-630 )

Rationale for this change
The clang-18 compiler fails when compiling relocatable device code with dynamically allocated shared memory passed through a lambda expression (see issue). This situation happens in the multiexp/multiproduct_gup:kernel component.
In order to switch the compiler to clang-18, we need to use the a work around. The work around is to pass an object that points to the dynamically allocated shared memory object. This should be a temporary change while the clang compiler bug is still open.
What changes are included in this PR?

The function passed a dynamically allocated shared memory object in the multiexp/multiproduct_gup:kernel component is now passed an object that points to the dynamically allocated shared memory object

Are these changes tested?
Yes, from previous tests with additional benchmark results outlined below.
Benchmark results
Benchmarks were run on a System 76 laptop with an NVIDIA GeForce RTX 3080 GPU inside the Blitzar GPU Docker container to determine if any performance differences were introduced. The results are averaged over 5 consecutive executions. Both the method of testing (laptop instead of VM) and number of executions which might not make this benchmark statistically significant.
Test criteria
bazel run -c opt //benchmark/multi_commitment:benchmark -- gpu 1000000 5 1 32 1
backend : gpu
commitment length : 1000000
number of commitments : 1
element_nbytes : 32
is boolean : 0
table_size (MB) : 31250
num_exponentations : 1000000

Results before update
average compute duration (s) : 0.1797044
average compute std deviation (s) : 0.0024874
average throughput (exponentiations / s) : 5.56e+06

Results after update
average compute duration (s) : 0.1856728 (3.21% slower than before)
average compute std deviation (s) : 0.0047892 (48% more std deviation)
average throughput (exponentiations / s) : 5.39e+06 (3.25% less throughput)

:tada: This PR is included in version 0.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add install section

Thanks for your contribution. This was accepted in an identical PR #48. Sorry for the confusion.


[WIP] Add suuport for Bitbucket repositories

I have added functionality for the Bitbucket repo provider, and also added it to the drop-down list of the repo providers.
It is working perfectly fine as shown in the screenshot.

Although I have made changes in the index.js file, to modify the text and tag_text for the Bitbucket Repo provider, but that change is not visible in the UI after selecting Bitbucket from the dropdown.


perf: Ionic 2 Beta - Horrible performance on x86 CPUs

Type: perf
Ionic Version: 2.x
Platform: android 5.0 webview
Hi,
hopefully this could be of some use for you guys:
I noticed that any app (even the simplest) that I build for my Zenfone 2 device runs with awful performances.
After trying it out on several devices I came to the conclusion that this issue might be caused by the Intel x86 CPU the Zenfone phones have on them.
I tried with other ARM devices and noticed that the performances were pretty good, it's just the Intel CPU that represents a problem for Ionic v2.
I understand Ionic 2 is still in beta and that most of the mobile devices mount an ARM CPU but I thought I'd let you know of this issue.
Keep up the good work,
Federico Gorla

I think there is nothing we can do to improve performance for a particular CPU architecture. We already try to write good JS that can be optimized easily by engines (like v8).
Engines like v8 implement Just In Time Compilation for targeted architectures, so you should try to debug if under your configuration something is preventing Chrome from generating machine code at runtime:

A bad configuration
A bug in chrome
An outdated webview
Some kind of W^X policy
Your CPU is just so slow

I will close this issue, but feel free to reopen it if you provide new information demonstrating it is an ionic issue.
Thanks for your time!

@Lagor31 give a try: crosswalk x86

Hi, thanks for your reply.
I forgot to mention that I tried to deploy apps built with both ionic v2 and ionic v1 on my terminal (x86 ZenFone2) and the ones built using ionic v1 are as smooth as they can be, the problems arises only when using v2.

I have tried Crosswalk with no succes.
I don't know how things are on your end but since v1 works, I thought that maybe there could be a fix to improve performance that doesn't involve rewriting massive parts of code.
Again, I'm not an Ionic developer so I don't have the full picture but I thought I'd share the problems I'm facing.

I am a Zenfone 2 User and an Ionic Developer using v1 and v2.
Never have had any performance problems using v2 like you mentioned.
Its hard to picture what you mean without more information.
Try to update your ionic cli to the latest beta, start a new sidemenu app and run it.


add psych engine script autocompleter to vscode section

The autocompleter is very helpful for me when scripting.


Docker required

To push to ECR docker must be on the sagemaker instance, which it is not by default and must be installed else error docker: command not found is returned. Please can the install instructions be included

I cannot reproduce this error as Docker is by default installed in SageMaker notebook instances. In which region are you?

Sorry this is sagemaker studio in eu-west-2

The environments that I tested were:

EC2
SageMaker notebook instances

Both in eu-west-1. Do you need to work in SageMaker studio?

NP I can use one of those, cheers


Separate the computation of generational states from the returning of the requested generational data

Computing the generational states over time is part of the GetPopulationCount(int generations) method.

Extract the computation into its own method
GetPopulationCount(int generations) should return the total population of the last state computed
Add a method to return the snapshot of the population state for the last state computed
Triggering any of the Get_____(int generations) methods should recomputed whatever was asked for

e734049006393889edc5980d01793d3f5a3efc13


Remove Conduits

Conduit use to be an old term for are what are now called "Base Dice Mods". They should be scrubbed, unless as a suggestion in Magic about making your magic system need a certain conduit.

Should actually be Base Dice Tiers


Added support for using the internal pull-up resistor.

Choose the input mode of the pin from INPUT and INPUT_PULLUP to permit the use of the internal pull-up resistor for for bare DHT modules.

👍

I refine some codes at https://github.com/winlinvip/SimpleDHT/commit/e94b1d5a2518860974cd943c0324ffb0cb41927c


Feat/show more refinements

Objective
What: Add the functionality to show more facets.
Why: Feature useful and expected by SEs
How: With config and conditional in refinements
Usage:
https://share.getcloudapp.com/OAuj0X7d
Type

[x] New Feature

Tested
✅
Documented

[x] Have you documented in changed file using comments

Great work, @VirAlex! Only feedback is on design: the padding on the left could be the same as the refinement values, and perhaps we could add something like a down arrow on the right where the number is for the others. The font style could also blend more with the refinement values style. What do you think? Thinking of how to make it consistent.

Do you see other things? To improve?


Conflict? math log() and debuging log()

Just wondering if these would conflict if used within a single script.

You should have them both as members of their parent objects.  Thus Math.log() and Debugger.log() or something like that.

BTW awesome contributions!

good point @z3dev ! and also spot on @bhouston :)
I really dislike that OpenJSCAD puts everything at a global level, in an implicit manner (explicit might be more verbose but it is so much better overall).
I think something like the following would indeed be preferable
const {Math, Debugger} = require('scad-api') //if not require, then something similar
const partSize = Math.log() * 42

but that would be a major breaking change (which I support, it would solve quite a few issues)

ThreeJS also has a problem with a module named Math -- it caused problems when ThreeJS moved towards requires like in your example as opposed to always acccessing it like THREE.Math.  What happened is that it was renamed _Math.  I would have prefered MathUtils instead myself.

@bhouston yeah , just underscoring it , is not very explicit, almost makes it seem like a 'private variable' :)
To our specific problem with Log : I just realised the 'log' that does ...loggging  is actually 'namespaced' to openjscad anyway, so no conflict: (ie you have to call openjscad.log).
I would argue that it means it should not be part of this repo but the main one, but for now it is not the end of the world.

@kaosat-dev Sort of off topic, but are you finding CSG.js robust?  We did integrate it into Clara.io years ago but it was not robust in the least except for the simplest of problems.  Thus we never moved it out of "beta".  I guess with your investments in this tool set you believe it is now robust with your changes?
Have you tested it beyond just simple test cases?

@bhouston  I think I actually remember your posts about those experiments for Clara.io (always used to look out for your great new features/eye candy and wish it was in 'mainline' three.js already :)
Do you mean geometric robustness or general usability as a lib?
We have not changed the CSG.js 'core' at all so far, so geometric robustness is still the same (though there have been lots of improvements over the years from what I have seen).
However , all this huge cleanup and reorganization , adding tests etc, was done because the next step (at least for me) is to tackle a in depth cleanup & upgrade (towards simplicity AND robustness) of CSG.js itself .
Good , manifold meshed are a must for 3d printing use (my main & only use tbh).

Closing as this issue does not exist with V2 modeling.


Inaccurate documentation: Math section's modulo and floor division description

Until now the documentation states that % is the remainder operator and // truncates the float to an integer (integer division). While this is true for positive numbers it is not for negative numbers: In Python % stands for the modulo operator and // is a floor division (rounding the result off instead of truncating the float to an integer).
Some explanation on floor / integer division (example: -23 / 22 = 1.04545....):

Integer division means truncating the float remainder (i.e. removing the decimal places): int(-23 / 22) = -1
Floor division rounds the result off to the greatest integer smaller than or equal to the float result: floor(-23 / 22) = -2

Some explanation on modulo/remainder operator:

-23 rem 22 is expected to be -1 as int(-23 / 22) = -1 => -23 - (-1*22) = -1 (you could say 22 fits -1 times into -23 and therefore -1 is still missing/remaining)
-23 mod 22 on the other hand is expected to be 21 as floor(-23 / 22) = -2 => -23 - (-2*22) = 21 (basically the remainder wrapped to positive numbers, you can think of it as a remainder function which uses floor division instead of integer division)

These docs are meant to be simple explanations for how the operators would be commonly used by non-math/programmer users in templates. I'm fine with the current plain description rather than the more accurate but jargon-y ones.

Well, Jinja is used by developers and they should know the difference. I don't think many people without programming knowledge are actually using Jinja. I mean, those things are conceptionally different things and IMHO the docs should be accurate. The thing is that by mixing it up someone with less experience might find it a tiny bit less readable but it might lead to bugs due to misunderstandings for more advanced users.

Yep, I understood the tradeoff when I responded the first time explaining why I was making the tradeoff.


kernel: Bump kernel for NVIDIA Platforms

This commit bumps the kernel version for NVIDIA Platforms. The new kernel (EVE's custom kernel) is based on the Jetson Linux 3.5.50, from Jetpack 5.1.3. The following devices are supported by this version:

Jetson Xavier NX
Jetson AGX Orin
Jetson AGX Orin Industrial
Jetson Orin NX / Orin Nano
Jetson AGX Xavier
Jetson AGX Xavier Industrial

Kernel version bumps from 5.10.104 to 5.10.192.
For more information see:

https://github.com/lf-edge/eve-kernel
https://developer.nvidia.com/embedded/jetson-linux-r3550

Are these kernel versions aready available in the eve-kernel repo and dockerhub?

By the way, @rene,  the branch here has conflicts with the master branch now; could you please resolve it?

Updates in this PR:

Rebase onto master


LSPS2: Clarify minor payment_size_msat things

Fixes #87

We drop an erroneous plus opening_fee suffix from the channel size calculation
And refer to the payment size as htlc_value_msat in no-MPP+var-invoice mode rather than payment_size_msat since the latter is only defined in MPP+fixed-invoice mode.

Ack

Merged as decided in todays spec meeting.


local, docker, and kubernetes builds

Enable all three build and runtime types:

local (this is just running it in your shell)
docker (with volume mounts and port forwarding)
kuberentes

Fixed in v1.0.0


Allow Tracer to be processed using a BeanPostProcessor

Currently when using java-spring-cloud dependency instead of java-spring-web, I get the following:
Bean 'getTracer' of type [....] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
This results in the Tracer bean not being processed by any BeanPostProcessors, which means extensions like java-metrics are not able to add a wrapper around the tracer.
The problem is caused by other BeanPostProcessor implementations autowiring in the Tracer, which means it is no longer available to be post processed itself.
This PR makes some changes to return a wrapper around the Tracer that only actually retrieves the Tracer bean on first use. It solves the problem, but not sure if there is a better way?

@geoand Thanks for the suggestion - appears to have worked 😄

@objectiser Awesome, good to hear!

@pavolloffay ok to release?

:+1:


Events

small tune up ... merge for like , not if not :+1:

I like the idea, this was some old style I was following :+1:
Although, I would like to wait a bit before merging this since it will break existing programs. I will mark this for the next minor-release, thanks!

Released in 2.7.0


Installing > 0.20.4 with kubectl

Describe the bug
When attempting to install >0.20.4 with kubectl, the crd is too large to apply.
To Reproduce

kubectl apply -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.22.0/actions-runner-controller.yaml

Environment (please complete the following information):

Controller Version [0.22.0]
Deployment Method [kubectl]

Additional context
This seems related to many folks errors installing with Helm, however this isn't using the Helm path.
...
to:
Resource: "apiextensions.k8s.io/v1, Resource=customresourcedefinitions", GroupVersionKind: "apiextensions.k8s.io/v1, Kind=CustomResourceDefinition"
Name: "runners.actions.summerwind.dev", Namespace: ""
for: "https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.22.0/actions-runner-controller.yaml": CustomResourceDefinition.apiextensions.k8s.io "runners.actions.summerwind.dev" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

Similar to:

https://github.com/actions-runner-controller/actions-runner-controller/issues/1157

Resolved with:
❯ kubectl replace  -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.22.0/actions-runner-controller.yaml


Support float ping value

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
Other
🔖 Feature description
In #3343 and #3320 , I said that I'm using the ping field to record the latency to the gateway. Obviously a float type data is very necessary in this case because all the latency data is between 1ms and 2ms. This feature may have been implemented by mistake since in version 1.21 and earlier, it could record ping values with float type and the graph below can also display the float type graph very well.
✔ Solution
Supporting float ping value for push type and even for other type (for Response field).
❓ Alternatives
No response
📝 Additional Context
No response

Why is the difference between 1..2ms important to you?
At such latency, are other metrics (99p/...) not more import for you?

The value for the ping is an integer globally ⇒ changing this in one corner would change this for every monitor => Nelsons assessment is correct, this is a duplicate
Why do you need to differentiate between 10.3 and 10ms?

I monitor sites on the same server as UK is running on, so it's not 10ms but 1-2ms. This is not useful to differentiate and creates a very jagged graph.

This is not fixed, I'm using 1.23.7 and HTTP is still rounded to int.

Thank you to all of you who are still following this issue.
It can be confirmed that in 1.23.7 push type can store float value again. Since my original request is to support float ping value for push type, I think this issue could close as completed. You can open another issue to ask for float values for other types like HTTP.


to set the bubble container's top = bubble top label's bottom + ___

when i set " the bubble container's top = bubble top label's bottom + 10 " , unexpectedly, found that the text in the messageBubbleContainerView is no longer be vertically center. So , please give me help to correctly set the space between bubble container's top and bubble top label's bottom.

The message bubbles use constraints.    Did you directly set the properties for the frames, or did you change the constraint?

On Jun 19, 2017 at 8:09 AM,  <wustzhy (mailto:notifications@github.com)>  wrote:
when i set " the bubble container's top = bubble top label's bottom + 10 " , unexpectedly, found that the text in the messageBubbleContainerView is no longer be vertically center. So , please give me help to correctly set the space between bubble container's top and bubble top label's bottom.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly,   view it on GitHub (https://github.com/jessesquires/JSQMessagesViewController/issues/2133), or   mute the thread (https://github.com/notifications/unsubscribe-auth/AOaU60BREki0PXBuO6FV8Uikre0BDH6Lks5sFo8ngaJpZM4N-XtW).

I set the constraint in xib .Did I do wrongly?  Or I need to do sth else to not make effect upon the bubble container's content. Thanks for your reply!

@VincentSit @jessesquires  please help me above, thank you very much. Have you try that way above? Did you face the same issue?

@wustzhy Sorry, I'm afraid I could not help you, I have two years no attention to this project.

I would assume this is due to the fact that these can vary in height from one message to the next. I'll take a look and see if there is a good place to change this.

Hello everyone!
I'm sorry to inform the community that I'm officially deprecating this project. 😢 Please read my blog post for details:
http://www.jessesquires.com/blog/officially-deprecating-jsqmessagesviewcontroller/
Thus, I'm closing all issues and pull requests and making the necessary updates to formally deprecate the library. I'm sorry if this is unexpected or disappointing. Please know that this was an extremely difficult decision to make. I'd like to thank everyone here for contributing and making this project so great. It was a fun 4 years. 😊
Thanks for understanding,
— jsq


Add P3 Initial Profile, Tendency

This PR aims to add compatibility in KiD to test the 1D framework described in case 1 of Cholette et al 2019 using P3.
Only P3 terminal velocity is included with this PR.

@sajjadazimi I've just tagged you for review on this PR—I haven't added tests for P3 and have not squashed/rebased yet, but I'm hoping to get your feedback on the code as I prepare to merge this. Thanks!!

Could we also add this case to our buildkite jobs: https://github.com/CliMA/KinematicDriver.jl/blob/main/.buildkite/pipeline.yml


Keypoints and bounding boxes change with zoom in-out

Describe the bug
Last keypoint jumps once you zoom out, even if you update/submit.
This behavior happens most of the times, but maybe not all the times. The KP jumps to the bottom-right first and once you zoom out again (after correcting it) it then jumps to the top-left. The 3rd time it works.
Similar thing also happens to bounding boxes. So if you zoom in to fine-tune bounding box edge sometimes the other edges will be fitted to the current zoomed in part.
To Reproduce
Steps to reproduce the behavior:

Do multiple keypoints.
Zoom in and pin the last keypoint.
Zoom out and you see how the last KP will jump diagonally to the bottom right.
Correct the KP and zoom out for the second time, the KP jumps to the top-left.
Correct it and zoom out for the 3rd time and it works.

Expected behavior
A consistent position of KPs and BBs regardless of zoom level.
Screenshots
Please see below screenshots.

Environment:

Ubuntu 20.04.2
Label Studio Version 1.3

@HoseinHashemi We've tried to reproduce this issue, but without success. Could you please record a video?

Attached is a sample when the bounding box gets changes according to the zoom level.
https://user-images.githubusercontent.com/33822932/141944646-9b9ca590-4505-4615-8e85-459eeeab06a8.mov

https://github.com/heartexlabs/label-studio-frontend/pull/351

Relative: https://github.com/heartexlabs/label-studio/issues/1672

This problem was fixed in the latest master and heartexlabs/label-studio-frontend#351.

Im using label studio 1.6.0 and im having the same problem.


Support partial HTML markup

A feature for discussion:
I propose the loader should have an option not to require a full HTML document, within  tags.
I'd like to use the html loader to load an HTML snippet (representing a template) as text into a variable.
The snippet would look like this:

#{number} {customer}

{title}

    {status}

{time}

And I would include it like this:
var listTemplate = require('html!templates/listItem.html');

Currently I'm doing that using the raw loader, but I'd like to be able to keep including templates but to have other HTML-specific options (specially minification).

+1


default config location

Instruction says:

Typically hbs2-peer config is located at
$HOME/.local/hbs2-peer/config

but hbs2-run uses $HOME/.configl/hbs2-peer/config as default path

fixed

Done?


Move LoadReportingServiceServerBuilderOption from ::grpc_impl to ::grpc

Reverts: https://github.com/grpc/grpc/pull/18419/files

Interop Cloud-to-Cloud Tests (internal CI): https://github.com/grpc/grpc/issues/23511
Interop Cloud-to-Prod Tests (internal CI):  https://github.com/grpc/grpc/issues/23511


[Security] Introducing securitySolutions CLI

Description
[Security] Add securitySolutions commands
Add securitySolutions commands, helps you control which applications can run on your Azure and non-Azure machines (Windows and Linux)
Testing Guide
The commands have been tested by running this test function "test_security_securitySolutions"

This checklist is used to make sure that common guidelines for a pull request are followed.

[*] The PR title and description has followed the guideline in Submitting Pull Requests.

[*] I adhere to the Command Guidelines.

Security

Will appreciate your attention to this PR.


HOPS-76

[HOPS-76] Fix bug with double parentheses in the process name
https://hopshadoop.atlassian.net/browse/HOPS-76

Can one of the admins verify this patch?


Toxicity Filter

Added a filter to select a subset of sentences based on toxicity.

Thank you! Yeah, that makes sense. I'll update the code to enable multiple conditions.

@Nickeilf I was wondering if I should implement multiple conditions the way they have been implemented for the token-amount filter or should I create another class that composes multiple filters just like torchvision's API, which allows users to compose multiple augmentations?

@Nickeilf I was wondering if I should implement multiple conditions the way they have been implemented for the token-amount filter or should I create another class that composes multiple filters just like torchvision's API, which allows users to compose multiple augmentations?

The idea of torchvision Compose is brilliant! I think it's definitely a good choice to apply multiple filters/transformations for the end-users! I guess the only restriction is that the sequences of filters should be the same class (e.g. all SentenceOperation) to make sure the input/output are the same.

Great! I'll write one for both transformations and filters. Which place would be more appropriate to put the files corresponding to the class?

Great! I'll write one for both transformations and filters. Which place would be more appropriate to put the files corresponding to the class?

I think we can have a separate file to have the torchvision Transform style implementation, and then we can import it in dataset.py when we want to apply multiple transformations/filters at the same time.
@kaustubhdhole here.

It would be a great idea to have such a mechanism. Will help evaluate examples which feature multiple properties together.

@Nickeilf


Added migrationstate management command

Hi,
This new management command can simplify migrating existing data to a new database greatly.
Your thoughts on including it in django-extensions are welcome. Tests will follow when you find it useful and think it can be included.
Best regards
Robert

Coverage decreased (-0.7%) to 70.082% when pulling 8f30e0045046538a6d875826631fe45033602599 on efficiosoft:migrationstate into 30ed44d5e8ed2d17d4148891ee14c21e3e2e45d5 on django-extensions:master.

Sounds useful :-)
Would be happy to include it.
I could imaging some additional features like a plain text format option and add an (optional) -f flag instead of in/output redirection.
These are all minor though...
What I would like to have are some tests for the command. This helps greatly with the maintainability of a command.

Sounds useful :-)
Would be happy to include it.

Great!

I could imaging some additional features like a plain text format option and add an (optional) -f flag instead of in/output redirection.

Hmm, I don't think a plain text output is really needed since you can specify --indent=4 to have it printed nicely, and there's still the native showmigrations command which - albeit serves a slightly different purpose - can output the same information pretty-printed.
Input/output file options are something I don't like very much in general for such simple commands... We have great shells these days and it would just add code to maintain. In addition, everybody, even if not familiar with the command, understands what < and > are going to do without having to consult the docs or call --help. So I'd rather prefer not to add I/O file options, if that's okay to you.

These are all minor though...

Glad to hear :)

What I would like to have are some tests for the command. This helps greatly with the maintainability of a command.

Sure, just wanted to wait whether it's going to be accepted.

No problem, thanks for the work on this !
When the tests land (and passes) I will merge this PR.

Just want to give a short feedback on this. I'm quite busy with other things at the moment. Please keep the PR open, I'll get back to it in a few weeks.
Best regards
Robert

Hi @trbs
It turns out to be difficult to write tests for this command, because the tests have to roll migrations back and forth themselves, which isn't possible with current Django versions due to SQLite not supporting nested transactions.
What do you think, how should we proceed with this PR?
Best regards
Robert

Would this be possible with PostgreSQL backend and if we only ran the tests on PG ?

Hmm, yes, that should work. But I wanted to avoid the overhead of setting up a local testenv just for that purpose... I'll see what I can do.

Thank you !
I want to merge this PR but I feel tests would make it so much better :-)
Think the test for the dump are quite easy.
Maybe we can use the --database option to add another empty sqllite3 database to settings ? such that we can use that one to restore and test the various functions.


[7zip] Add export header file

Fixes https://github.com/microsoft/vcpkg/issues/38761
Add the installation of header files CPP\Windows and CPP\7zip\Common.

[X] Changes comply with the maintainer guide.
[ ] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is added to each modified port's versions file.

Usage test pass with following triplets:
x64-windows

To be able to actually use most of these files they should be exported from the DLL but they are not.

I agree, this seems incorrect.


Better Unicode Support

We need a way to count stream input as unicode glyphs rather than chars.
Until we have this sorted automatic line breaks and error messages will have unexpected output
for lines that contain some unicode glyphs.
Ideally I want to avoid bringing in a large Unicode library, but this is probably a non-trivial challenge.
["expect_errorʤ"]
["expect_errorʤ"]

Gives the following incorrect output:
Attepted to reopen table: "expect_errorʤ", but this table has already been defined.
3>["expect_errorʤ"]
   ^~~~~~~~~~~~~~~^

Instead of:
Attepted to reopen table: "expect_errorʤ", but this table has already been defined.
3>["expect_errorʤ"]
   ^~~~~~~~~~~~~~^

Another issue is Unicode string equality.
We're using encoded byte equality, but some glyphs can be represented using multiple code point combinations, and so basic byte equality isn't sufficient.

I incorporated uni-algo to provide this capability.


To pandas

issue #201 to_pandas for dataframe

Codecov Report

Merging #269 (91984c9) into master (6e9aa6c) will increase coverage by 0.08%.
The diff coverage is 98.21%.

@@            Coverage Diff             @@
##           master     #269      +/-   ##
==========================================
+ Coverage   76.01%   76.10%   +0.08%
==========================================
  Files          44       44
  Lines       14001    14055      +54
==========================================
+ Hits        10643    10696      +53
- Misses       3358     3359       +1

Impacted Files
Coverage Δ

exetera/core/dataframe.py
80.48% <92.30%> (+0.21%)
:arrow_up:

tests/test_dataframe.py
99.00% <100.00%> (+0.04%)
:arrow_up:

Continue to review full report at Codecov.

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


compareValidator javascript validator only works with attributes in rules

since commit link the javascript for compareValidator does not work anymore, because the targetAttribute is only found when it's in the rules section.
What steps will reproduce the problem?
public function rules()
    {
        return [
            ['password', 'compare'],
        ];
    }

What is the expected result?
password validates correctly to the password_repeat attribute.
What do you get instead?
It always does not validate and gives an error while both values are the same, because the password_repeat attribute was not found in the client validation method.
Suggestion
Adding password_repeat as safe attribute was also not working. Adding another validator linke StringValidator for password_repeat fixed the validation. Like:
public function rules()
    {
        return [
            ['password', 'compare'],
            [['password_repeat'], 'string', 'length' => [6, 40]],
        ];
    }

My suggestion is to add a warning or notice to the validator, that the target attribute must be an attribute in the rules section.
Additional info

Q
A

Yii version
<IP_ADDRESS>

PHP version
7.2.3

Operating system
Linux

@mikk150 could you check this issue, please?

What I would do is register all fields that are rendered using ActiveForm::field($model, 'attribute') to yiiActiveForm.attributes just without validators

I'm not sure how safe is it (in terms of backward compatibility).
Maybe, we can fallback to ID search in case attribute was not find in attributes?

Also found this bug.
My rules are:
public function rules()
	{
		return [
			['password', 'safe'],
			['passwordRepeat', 'compare', 'compareAttribute' => 'password'],
			...
		];
	}

I suggest to fill yiiActiveForm.attributes with all safe attributes, (because they are actually the one, which should be validated and input is allowed)

And this is pretty critical for already live projects, which started using new json field support and they can't revert, so would be great to fix this in neartime.

@aprokopenko this issue is not in priority for the nearest future, so if you have time, would you like to help up to fix this issue by submitting a pull request? We have contributors guide that is a good starting point. If you need any tip – let us know.


oronasal membrane terms

Add:
abnormal oronasal membrane morphology
DEF: any structural anomaly of the thin, transient epithelial sheet which separates the primordial nasal cavity from the stomatodeum; in mammals, bucconasal membranes demarcate the locations of the paired primitive choanae; after lip fusion, degradation of the nasal fin and bucconasal membrane is necessary for reestablishing contact between the neonatal oral and nasal cavities through an open choana and for enabling nasal breathing in neonates
SYN: abnormal oro-nasal membrane morphology
SYN: abnormal bucconasal membrane morphology
SYN: abnormal nasobuccal membrane of Hochstetter morphology
SYN: abnormal bucconasal membrane of Hochstetter morphology
SOURCES:
http://medical-dictionary.thefreedictionary.com/bucconasal+membrane
PMID:26293818
persistent oronasal membrane
DEF: failure of the oronasal membrane to rupture during development leading to choanal obstruction
SYN: persistent oro-nasal membrane
SYN: persistent bucconasal membrane
SYN: persistent nasobuccal membrane of Hochstetter
SYN: persistent bucconasal membrane of Hochstetter
J:153100 (PMID:19648291)
Anna

abnormal oronasal membrane morphology MP:0030182
persistent oronasal membrane MP:0030183


Refactor: extract some methods of the 2D renderers from the Engine

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Extract some methods of the 2D renderers from the Engine. The code of Engine should be clean!
Just like this._textDefaultFont is implemented through Font.createFromOS, it would be more reasonable for _spriteDefaultMaterial to be implemented through the static method of its renderer class.

Summary by CodeRabbit

New Features

Introduced new methods for creating materials specific to sprite masking, sprite rendering, and text rendering.
Enhanced rendering capabilities with optimized material configurations for better performance.

Refactor

Centralized material creation logic from the Engine class to respective renderer classes, improving maintainability and reducing complexity.

Bug Fixes

Removed outdated material creation methods from the Engine class to streamline functionality.

see: https://github.com/singlecoder/engine/pull/14


tests: Add the possibility to add testing tables to the clusterState

Codecov Report

Merging #6651 into master will increase coverage by 0.11%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #6651      +/-   ##
============================================
+ Coverage     83.12%   83.24%   +0.11%
- Complexity    13392    13415      +23
============================================
  Files          1525     1525
  Lines         49638    49638
  Branches       5922     5922
============================================
+ Hits          41264    41322      +58
+ Misses         5561     5519      -42
+ Partials       2813     2797      -16

Impacted Files
Coverage Δ
Complexity Δ

...io/crate/protocols/postgres/types/VarCharType.java
91.66% <0%> (-8.34%)
10% <0%> (-1%)

...in/java/io/crate/breaker/RamAccountingContext.java
81.66% <0%> (-3.34%)
20% <0%> (-2%)

...ration/collect/collectors/LuceneBatchIterator.java
86.81% <0%> (-3.3%)
36% <0%> (-1%)

...rc/main/java/io/crate/blob/BlobTransferTarget.java
81.09% <0%> (-3.05%)
25% <0%> (-1%)

sql/src/main/java/io/crate/action/sql/Session.java
86.2% <0%> (-1.38%)
30% <0%> (-1%)

...o/crate/executor/transport/ShardUpsertRequest.java
89.75% <0%> (ø)
32% <0%> (ø)
:arrow_down:

...er/src/main/java/io/crate/sql/tree/AstVisitor.java
27% <0%> (ø)
37% <0%> (ø)
:arrow_down:

...executor/transport/TransportShardUpsertAction.java
86.09% <0%> (+0.66%)
77% <0%> (+1%)
:arrow_up:

blob/src/main/java/io/crate/blob/DigestBlob.java
77.44% <0%> (+0.75%)
31% <0%> (+1%)
:arrow_up:

.../executor/transport/task/LegacyUpsertByIdTask.java
87.78% <0%> (+0.76%)
35% <0%> (+1%)
:arrow_up:

... and 28 more

Continue to review full report at Codecov.

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


fix: consent en and sv translations

Description
Translations updated
Issues
Closes
DEV-XXX:
Related
Testing
Automated tests
Manual testing
Screenshots
Additional notes

Codecov Report

Merging #83 (95b65ef) into main (fd25d47) will decrease coverage by 0.31%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #83      +/-   ##
==========================================
- Coverage   67.40%   67.08%   -0.32%
==========================================
  Files         306      102     -204
  Lines        7409     2446    -4963
  Branches     1700      564    -1136
==========================================
- Hits         4994     1641    -3353
+ Misses       2191      731    -1460
+ Partials      224       74     -150

Impacted Files
Coverage Δ

...rts-helsinki/src/pages/courses/[eventId]/index.tsx

...s-helsinki/src/domain/search/eventSearch/utils.tsx

...in/search/eventSearch/filterSummary/TextFilter.tsx

...s-helsinki/src/domain/search/eventSearch/utils.tsx

apps/sports-helsinki/src/lib/i18n/index.ts

apps/sports-helsinki/src/assets/icons/IconRead.tsx

.../hobbies-helsinki/src/assets/icons/IconTheatre.tsx

...ki/src/domain/event/eventInfo/OrganizationInfo.tsx

apps/hobbies-helsinki/src/pages/search/index.tsx

...c/domain/article/articleDetails/ArticleDetails.tsx

... and 194 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Keep poli versions updated for the user (?)

One way to do this is to auto-update poli for the user (optionally).


Data not passed to the component on change

Hi, I'm trying to use mobx with react-komposer. So far I managed to pass data from the mobx store and fire actions to change that data. The initial data comes to the container. Also when I change that data, the changed data come to the container. But the container does not pass the new data to the component. Any idea why this is happening?
My container :
import {useDeps, composeAll} from 'mantra-core';
import composeWithMobx from '../libs/with_mobx';
import MainLayout from '../components/main_layout.jsx';

const onPropsChange = ({ context }, onData) => {
  let { loginModal } = context().Store.core.users;

  onData(null, {
    loginModal,
  });
};

export const depsMapper = (context, actions) => ({
  context: () => context
});

export default composeAll(
  composeWithMobx(onPropsChange),
  useDeps(depsMapper)
)(MainLayout);

Just found the issue. I was setting the new value in componentDidMount. In other instances, it worked but when I change the value inside componentDidMount the container won't pass the value to the component. I fixed it by adding the value changing function inside a setTimeout. Any idea why this is happening?


Error Login

Help me get this message:
Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: POST https://fortnite-public-service-prod11.ol.epicgames.com/fortnite/api/game/v2/profile/848a9343e9124aed8b188677ddc40278/client/QueryProfile?profileId=athena&rvn=-1 resulted in a 403 Forbidden response: {"errorCode":"errors.com.epicgames.common.missing_action","errorMessage":"Login is banned or does not posses the action (truncated...) in .....

Hello, you have to login once, just LAUNCH Fortnite and close game when you are on lobby, you will be able so.

I had the same problem. Play at least 3-5 matches and everything will work ok.


Set job to "unstable" if skipping entire (non-empty) queue

https://github.com/docker-library/meta-scripts/pull/91#issuecomment-2489694031 :+1:

https://doi-janky.infosiftr.net/job/meta/job/arm32v5/job/trigger/10417/ success (unstable)


Ability to link Generic OAuth provider to account

Is your feature request related to a problem? Please describe.
I'd like the ability to link a generic oauth provider to an already existing account.
Describe the solution you'd like
Using the generic oauth plugin, i'd like the ability to do:
genericOAuth({
      config: [
        {
          providerId: "roblox",
          clientId: env.ROBLOX_CLIENT_ID,
          clientSecret:
            env.ROBLOX_CLIENT_SECRET,
          discoveryUrl:
            "https://apis.roblox.com/oauth/.well-known/openid-configuration",
        },
      ],
    }),

to then do after, when the user already has an account (they'll already be signed in at this point, and I just want the ability to link the roblox account to their account)
await authClient.linkSocial({
	provider: "roblox",
	callbackURL: "/dashboard?redirect=true",
});

Describe alternatives you've considered
I've tried adding it to the trusted providers
account: {
    accountLinking: {
      enabled: true,
      trustedProviders: ["roblox"],
    },
  },

however this still produces a type error when trying to pass "roblox" as a provider param to linkSocial, and a 400 error on the server.
maybe an officially supported roblox social provider too?

Same, just found this issue in the Discord and figured I'd give it a bump here too. I want to use BA specifically for the ability to link social accounts so it would be great to have custom Oauth support for the social linking feature.

For whoever ends up working on this. Please take into account that certain OAuth providers, like Roblox, do not return an email address. I created a fork to experiment with Roblox integration and ran into this issue. Because BA is hard-coded to expect an email address this threw some errors and because of length checking and/or trimming submitting an empty string does not work either.
All in all this means that for Roblox, or other providers that do not return email addresses to work, there should probably be a way to make the link process ignore the email address existence check as well as the code that checks if the returned email is the same as the email that the user is registered under.

Also @mandrillxx my current fork has the Roblox provider built-in and is currently on version 1.1.4.
You can install it using npm install 'https://gitpkg.vercel.app/D3visionNL/better-auth/packages/better-auth?main'
I had to use gitpkg cause else you get the main package which is kinda useless.
Please do keep in mind that I am fully intending for this to be temporary so don't expect me to keep it up to date.
For anyone who looks at this, yes I know you're not supposed to push the dist into the actual repo but this is the only easy way for me to have the option to pull in changes from the official repo😂